¿Qué es un Service Worker?

¿Qué es un service worker?

Un service worker es un archivo JavaScript que corre en segundo plano de una página web, separado del hilo principal del navegador. Su poder central es interceptar y modificar peticiones de red hechas por la página. Esta única capacidad desbloquea soporte offline, push notifications, background sync y rendimiento dramáticamente más rápido en cargas repetidas — features que antes requerían apps nativas.

Los service workers fueron estandarizados en 2015 y enviados en Chrome 40, Firefox 44, Safari 11.1 (con retrasos) y Edge desde el inicio. Son la base de las Progressive Web Apps (PWAs): apps web que se instalan en la pantalla de inicio, funcionan offline y se sienten nativas. Incluso sitios que no apuntan a ser PWAs usan service workers para rendimiento — cachear respuestas caras, pre-cargar assets críticos, deduplicar llamadas API.

Qué pueden hacer los service workers (y qué no)

Los service workers corren en un contexto especial con capacidades y limitaciones estrictas:

Pueden:

• Interceptar peticiones de red. El evento fetch se dispara por cada petición que la página hace — HTML, CSS, JS, imágenes, llamadas API. El worker decide: servir desde caché, modificar la petición, ir a red o fallback si offline.
• Cachear respuestas programáticamente. Los service workers tienen acceso a la Cache API — un almacén de caché separado del caché HTTP del navegador, con control programático explícito.
• Push notifications. Recibir mensajes push desde un servidor incluso cuando la página está cerrada, luego mostrar notificaciones al usuario.
• Background sync. Diferir trabajo hasta que el usuario tenga conectividad. Encolar llamadas API offline, enviar cuando la red vuelva.
• Background fetch. Descargas de larga duración que continúan incluso después de cerrar la página.

No pueden:

• Acceder al DOM directamente. Los service workers corren en un contexto separado. Se comunican con páginas solo vía postMessage.
• Usar APIs síncronas (XHR sync, localStorage). Entorno solo async. Usa fetch e IndexedDB en su lugar.
• Persistir estado a través de reinicios arbitrariamente. El navegador puede terminar el worker en cualquier momento que esté idle. Usa IndexedDB o Cache para estado, no variables de módulo.
• Correr en orígenes inseguros. Los service workers requieren HTTPS (excepto localhost para desarrollo).

El ciclo de vida del service worker (5 etapas)

1. Register. La página llama navigator.serviceWorker.register('/sw.js'). El navegador descarga el archivo del worker.
2. Install. El navegador dispara el evento install. El worker típicamente pre-cachea assets críticos aquí.
3. Activate. El navegador dispara el evento activate. El worker toma control de las páginas en la siguiente navegación (usa clients.claim() para tomar control inmediatamente).
4. Run / manejar eventos. El worker maneja fetch, push, sync, etc. cuando se disparan. El navegador puede terminar el worker entre eventos para ahorrar memoria.
5. Update. Cuando el usuario revisita, el navegador comprueba si sw.js cambió (byte por byte). Si sí, la nueva versión instala pero espera a que todas las páginas de la versión vieja se cierren antes de activar. Force-update con skipWaiting().

Patrones comunes de service worker

Cache-first para assets estáticos

Para CSS, JS, fonts, imágenes que cambian poco: servir desde caché, fallback a red, actualizar caché en segundo plano. La página carga instantáneamente en visitas repetidas.

Network-first con fallback a caché para HTML

Para páginas HTML dinámicas que deben estar frescas: intentar red primero (con timeout corto), fallback a caché si offline o lento. El usuario ve contenido fresco cuando está online, contenido cacheado cuando no.

Stale-while-revalidate para llamadas API

Servir respuesta API cacheada inmediatamente, luego buscar fresca en segundo plano y actualizar caché. El usuario ve datos instantáneos con consistencia eventual.

Network-only para mutaciones

Las peticiones POST/PUT/DELETE saltan el caché por completo — deben golpear la red o encolar para background sync.

Offline-first con shell + contenido dinámico

Pre-cachear el shell de la app (HTML, CSS, bundle JS) en install. Buscar contenido dinámico de la red con fallback a caché. El sitio funciona completamente offline para contenido cacheado, degrada graceful para contenido nuevo.

Service workers y Core Web Vitals

Los service workers pueden mejorar dramáticamente Core Web Vitals en visitas repetidas — pero en la primera visita, añaden pequeño overhead (registrar el worker, cargar sw.js). Implicaciones:

• LCP mejora dramáticamente en visitas repetidas. Imágenes hero pre-cacheadas y CSS crítico cargan instantáneamente.
• FCP mejora en visitas repetidas. El shell HTML pre-cacheado renderiza antes del roundtrip de red.
• El coste de la primera visita es real. Registrar e instalar el worker, pre-cachear assets, parsear JavaScript adicional — todo añade coste en la primera sesión. No sobre-ingenieres.
• CLS no afectado. Los service workers no impactan estabilidad de layout en ningún sentido.
• INP puede mejorar. Respuestas interactivas pre-cacheadas (ej. sugerencias de búsqueda cacheadas) reducen latencia de roundtrip de servidor en interacciones de usuario.

Service workers vs otras capas de caché

Las apps web modernas tienen múltiples capas de caché. Los service workers se sientan en un sitio específico:

• Caché HTTP del navegador: Implícito, controlado por headers Cache-Control. El navegador decide qué cachear y cuándo. Sin control JavaScript.
• Cache API del Service Worker: Explícito, controlado por JS. Sobrevive a recargas de página. Control programático sobre qué cachear y servir.
• Caché CDN: Servidores edge. Rápido pero compartido entre todos los usuarios. Updates vía invalidación de caché.
• HTTP/2 push (deprecado): El servidor empuja recursos. Eliminado de Chrome en 2022 porque no superaba a los service workers.

FAQ: Service Workers

¿Necesito un service worker para mi sitio?

Si tu sitio es content-heavy y los usuarios vuelven a menudo, sí — las ganancias de rendimiento en visita repetida son grandes. Si los usuarios visitan una vez y nunca vuelven, el overhead de primera visita puede no compensar. Sitios puramente de marketing con bajas tasas de retorno no necesariamente se benefician.

¿Cuál es la diferencia entre un service worker y un web worker?

Ambos corren en hilos en segundo plano. Los web workers manejan trabajo CPU-bound en paralelo al hilo principal (procesamiento de imágenes, computación). Los service workers específicamente interceptan peticiones de red y persisten a través de cargas de página. APIs distintas, ciclos de vida distintos.

¿Por qué los updates de service worker tardan tanto en desplegar?

Por defecto, una nueva versión de worker instala pero espera a que TODAS las páginas corriendo la versión vieja se cierren antes de activar. Para usuarios con el sitio abierto en una pestaña para siempre, esto puede ser días. Force-update con skipWaiting() en el handler install — pero ten cuidado, puede causar mismatch de assets y código a mitad de sesión.

¿Cómo debuggeo un service worker?

Chrome DevTools → Application → Service Workers muestra workers registrados, estado actual, errores. La pestaña Network muestra qué peticiones se sirvieron desde el caché del SW (busca el icono pequeño de engranaje). Las auditorías Lighthouse incluyen comprobaciones PWA / service worker.

¿Funcionan los service workers en Safari?

Sí, desde iOS 11.3 / Safari 11.1. La implementación ha sido más débil históricamente (background sync retrasado, push notifications limitadas hasta iOS 16.4). Siempre testea features PWA en Safari real, no solo Chrome.

¿Puede un service worker romper mi sitio?

Sí, fácilmente. Un worker buggy que siempre devuelve respuestas cacheadas (incluso obsoletas) crea una UX permanentemente rota de la que es difícil recuperarse — los usuarios no verán arreglos hasta que el worker se auto-actualice. Siempre incluye un kill switch: una comprobación que deshabilita el worker en un flag que tu servidor controla.

Cómo LoadFocus mide el impacto del service worker

LoadFocus ejecuta tests de velocidad de página basados en Lighthouse desde instancias Chrome reales en más de 25 regiones, capturando métricas de primera visita y visita repetida por separado. La efectividad del service worker se muestra como una gran brecha entre el LCP de carga fría y carga caliente. Programa auditorías para validar que el worker está realmente funcionando en producción — registros de service worker rotos son un asesino silencioso que no aparece en runs Lighthouse de página única.