Configuración de Service Workers para experiencias offline robustas

Configuración de Service Workers para experiencias offline robustas

Los service workers son la columna vertebral de cualquier Progressive Web App (PWA) que quiera ofrecer una experiencia offline confiable. En esta guía, desde la perspectiva de un profesional en hosting, servidores e infraestructura, explico la arquitectura, estrategias de cache, ejemplos prácticos de implementación y prácticas de hosting necesarias para que tus usuarios tengan acceso a tu sitio incluso sin conexión.

¿Qué es un Service Worker y por qué importa?

Un service worker es un script que el navegador ejecuta en segundo plano, independiente de la página web. Intercepta peticiones de red, permite cachear recursos y gestionar notificaciones o sincronización en segundo plano. Para implementarlo correctamente necesitas HTTPS y control sobre la configuración del servidor.

Para una referencia técnica completa, consulta la documentación de MDN Web Docs sobre Service Worker.

Arquitectura y ciclo de vida esencial

Eventos principales

  • install: ideal para precacheo de assets críticos.
  • activate: limpieza de caches antiguos y migraciones.
  • fetch: intercepción de peticiones para aplicar estrategias de cache.
  • message: comunicación entre página y worker (por ejemplo, skipWaiting).

Comprender estos eventos permite diseñar flujos seguros al desplegar nuevas versiones y minimizar roturas en producción.

Estrategias de cache y cuándo aplicarlas

La selección de una estrategia define la percepción de velocidad y la consistencia de datos. Las más útiles son:

  • Cache-first: ideal para assets estáticos (CSS, JS, imágenes); reduce latencia y consumo de red.
  • Network-first: recomendable para datos dinámicos o APIs donde la frescura es prioritaria.
  • Stale-while-revalidate: mezcla rendimiento y frescura: sirve versión cacheada y actualiza en segundo plano.
  • Cache-only / Network-only: casos específicos como PDFs internos o endpoints que no deben guardarse.

Ejemplo de elección práctica: usar cache-first para el bundle y network-first para /api/user y /api/content.

Implementación paso a paso

1. Registro del service worker

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js')
      .then(reg => console.log('SW registrado:', reg.scope))
      .catch(err => console.error('Fallo registro SW:', err));
  });
}

2. Estructura básica de service-worker.js

Ejemplo que implementa precache y una estrategia mixta:

const CACHE_NAME = 'site-cache-v1';
const PRECACHE_ASSETS = [
  '/',
  '/index.html',
  '/styles/main.css',
  '/scripts/main.js',
  '/fallback.html'
];

self.addEventListener('install', event => {
  self.skipWaiting();
  event.waitUntil(
    caches.open(CACHE_NAME).then(cache => cache.addAll(PRECACHE_ASSETS))
  );
});

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(keys => Promise.all(
      keys.map(key => {
        if (key !== CACHE_NAME) return caches.delete(key);
      })
    ))
  );
  self.clients.claim();
});

self.addEventListener('fetch', event => {
  const request = event.request;

  // API: network-first
  if (request.url.includes('/api/')) {
    event.respondWith(
      fetch(request)
        .then(response => {
          const clone = response.clone();
          caches.open(CACHE_NAME).then(cache => cache.put(request, clone));
          return response;
        })
        .catch(() => caches.match(request))
    );
    return;
  }

  // Assets: cache-first with fallback
  event.respondWith(
    caches.match(request).then(cached => cached || fetch(request).catch(() => caches.match('/fallback.html')))
  );
});

3. Fallbacks y manejo de errores

  • Incluye una /fallback.html para páginas HTML cuando no hay conexión.
  • Cachee respuestas JSON críticas y controla su tamaño para evitar saturar almacenamiento.

Buenas prácticas de hosting e infraestructura

Los service workers requieren una capa de hosting y seguridad que soporte su funcionamiento:

  • HTTPS obligatorio: los service workers solo funcionan sobre HTTPS (excepto localhost). Emite certificados gratuitos con Let’s Encrypt.
  • Headers correctos: sirve el service-worker.js con Cache-Control apropiado y, si necesitas alcance especial, configura Service-Worker-Allowed.
  • CDN y cache: configura el CDN para no cachear dinámicamente el service-worker.js o usa versionado en el nombre.
  • Size limits: muchos navegadores limitan el espacio disponible para cache; industrializa la estrategia de expiración.

Para pautas avanzadas de rendimiento y PWA revisa la guía de Google Developers sobre Service Workers.

Pruebas, depuración y métricas

  • Usa las DevTools del navegador para inspeccionar caches, service workers registrados y simular condiciones offline.
  • Ejecuta Lighthouse para medir PWA, rendimiento y accesibilidad.
  • Monitorea errores en producción con herramientas de logging (Sentry, LogRocket) y registra eventos claves en tu backend para detectar fallos de sincronización.

Consideraciones SEO y accesibilidad

Los service workers no deben sustituir el contenido renderizado en el servidor. Para SEO y accesibilidad:

  • Mantén renderizado server-side o prerender cuando el contenido es indexable.
  • Evita técnicas que impidan al crawler obtener HTML válido offline; los motores de búsqueda necesitan acceder a contenido real para indexar.
  • Progresive enhancement: implementa el service worker como una mejora, no como requisito para ver el sitio.

Errores comunes y cómo evitarlos

  • No versionar el cache: provoca servir assets obsoletos. Usa nombres con versión y limpia en activate.
  • Precaching de demasiados recursos: incrementa el tiempo de instalación y espacio de almacenamiento.
  • Confiar en cache sin expiración para APIs: puede mostrar datos obsoletos; aplica network-first o stale-while-revalidate con TTL.

Checklist rápido antes de poner en producción

  • Servicio servido por HTTPS y certificados válidos.
  • Registro y scope correctos para cubrir todas las rutas necesarias.
  • Nombre de cache con versión y limpieza en activate.
  • Mecanismos de fallback y páginas offline útiles.
  • Pruebas con DevTools, Lighthouse y tests reales en dispositivos móviles.

Conclusión

Configurar service workers correctamente transforma la experiencia de usuario: reduce latencia, permite uso offline y mejora la percepción de fiabilidad. La clave está en elegir la estrategia de cache correcta por tipo de recurso, asegurar una infraestructura HTTPS robusta, versionar caches y monitorizar en producción. Implementa las prácticas descritas, prueba con herramientas como Lighthouse y MDN y prioriza la progresive enhancement para mantener la indexabilidad y accesibilidad de tu sitio.

Si ya gestionas un servidor o un entorno WordPress, empieza por un registro simple y un archivo service-worker.js con precache limitado: observarás mejoras inmediatas en rendimiento y resiliencia ante interrupciones de conectividad.

Referencias: documentación técnica en MDN y guías prácticas en Google Developers. Para HTTPS y certificados automáticos revisa Let’s Encrypt.

Tags: