Un service worker es un proxy entre la página y la red, así que puede servir respuestas cacheadas, funcionar sin conexión, precachear un armazón y gestionar sincronización en segundo plano o push. La precaución es el ciclo de vida: solo controla páginas después de activarse, un worker antiguo sigue sirviendo assets antiguos hasta que se reemplaza, y una regla de caché mala puede dejar a los usuarios clavados en una build rota. Versiona siempre tus cachés y entrega una ruta de actualización clara.
Por qué lo preguntan los entrevistadores
Los service workers son potentes y genuinamente peligrosos, así que la pregunta va en realidad sobre conciencia del riesgo. El entrevistador quiere oír hablar de install, waiting y activate, de versionado de cachés y del incidente clásico de entregar un arreglo que los usuarios nunca reciben. Mencionar que la caché HTTP más una CDN cubre la mayoría de necesidades demuestra criterio sobre cuándo se justifica de verdad la complejidad añadida.
Cómo estructurar tu respuesta
- Descríbelo como un proxy de red con un ciclo de vida.
- Nombra los casos de uso que de verdad lo necesitan.
- Explica el modelo de actualización y el versionado de cachés.
- Di cuándo no te molestarías.
Ejemplo de respuesta
Se sitúa entre la página y la red como un worker aparte, así que puede interceptar fetches y decidir si responde desde una caché. Eso me da soporte sin conexión, un armazón instantáneo en visitas repetidas, sincronización en segundo plano para acciones en cola y notificaciones push. Con lo que tengo cuidado es con el ciclo de vida, porque de ahí vienen los incidentes. Un worker nuevo se instala y luego espera a que desaparezca cada pestaña controlada antes de activarse, así que los usuarios pueden quedarse con código antiguo mucho más tiempo del que esperas. Y si cacheo el HTML con una regla de caché primero y luego entrego un worker roto, he dejado inservibles a los usuarios que vuelven, ya que nunca llegan a pedir el arreglo. Así que versiono los nombres de caché y borro los antiguos al activar, mantengo el HTML como red primero y solo caché primero para assets con hash, y siempre conservo una ruta de emergencia que desregistra y limpia las cachés. Si el requisito es solo velocidad en visitas repetidas y no uso real sin conexión, prefiero conseguirlo con cabeceras de caché y una CDN y saltarme toda esta clase de problemas.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Cómo empujarías un arreglo urgente a usuarios atascados en un service worker antiguo?
- ¿Qué estrategia de caché usas para el HTML frente a los assets con hash?
- ¿Qué hace skipWaiting y cuándo es peligroso?
Más preguntas para Desarrollador frontend
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas