Service Worker

Qué es un Service Worker

Service Worker es un script JavaScript que se ejecuta en segundo plano en el navegador, separado de tu página web. Actúa como un proxy entre tu web y la red, permitiendo:

• Caché personalizada de recursos
• Funcionamiento offline de tu web
• Background sync: enviar datos cuando vuelva la conexión
• Push notifications: notificaciones tipo app móvil
• Performance: respuestas instantáneas desde caché

Es la base de las Progressive Web Apps (PWA).

Cómo funciona

1. El navegador registra el Service Worker la primera vez que el usuario visita tu web
2. El SW se instala en segundo plano
3. A partir de entonces, intercepta todas las peticiones de red de tu web
4. Decide: responder desde caché, hacer fetch, mezclar ambos
5. Sigue activo aunque el usuario cierre la pestaña

Estrategias de caché típicas

Cache First (offline-first)

1. Buscar en caché
2. Si existe → servir desde caché (rápido)
3. Si no → fetch a la red

Ideal para: assets estáticos (CSS, JS, imágenes que no cambian).

Network First (online-first)

1. Hacer fetch a la red
2. Si responde → servir y actualizar caché
3. Si falla → servir desde caché (fallback)

Ideal para: contenido dinámico (artículos del blog, productos).

Stale While Revalidate

1. Servir desde caché inmediatamente
2. En paralelo, hacer fetch para actualizar caché
3. Próxima visita: contenido fresco

Ideal para: contenido que cambia ocasionalmente.

Ejemplo básico

// service-worker.js
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('v1').then((cache) => {
      return cache.addAll([
        '/',
        '/styles.css',
        '/script.js',
        '/offline.html'
      ]);
    })
  );
});

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((response) => {
      return response || fetch(event.request);
    })
  );
});

Y en tu HTML:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js');
}

Limitaciones

Solo HTTPS

Service Workers requieren HTTPS (excepción: localhost para desarrollo). Sin HTTPS, no funcionan.

Scope limitado

Un Service Worker solo controla las páginas dentro de su scope (carpeta donde está). /service-worker.js controla todo el dominio; /blog/service-worker.js solo controla /blog/.

No acceso al DOM

No puede tocar el HTML directamente. Solo intercepta peticiones de red. Para comunicación con la página: postMessage API.

Actualización delicada

Una vez registrado, el SW se cachea. Actualizarlo requiere versionado correcto. Bug típico: usuarios sirviendo versión vieja durante días.

Cuándo usar Service Workers

✓ Buenos casos

• Webs con tráfico recurrente (los usuarios vuelven)
• Contenido que se beneficia de offline (blogs, docs, ecommerce con catálogo)
• Apps web tipo SaaS
• News apps / readers

✗ Casos donde NO son necesarios

• Web corporativa estática simple
• Landing page único uso
• Sitios con tráfico muy bajo

Cuidados

• Versionado: cada deploy, cambiar versión de caché o usuarios verán contenido viejo
• Debugging: Chrome DevTools → Application → Service Workers
• Eliminar SW: opción “Unregister” en DevTools si bloquea desarrollo

En Astro / Next.js

Astro: usar plugins como @vite-pwa/astro. Next.js: next-pwa o @serwist/next.

Ambos automatizan la configuración del Service Worker para producción.