Los Service Workers se han convertido en una de las herramientas más potentes para acelerar un sitio web y ofrecer un verdadero modo sin conexión. Este script que se ejecuta en segundo plano, independiente de la página, intercepta las peticiones de red y permite almacenar en caché de forma inteligente los recursos que tus visitantes necesitan.
En esta guía veremos cómo implementar los Service Workers paso a paso, qué estrategias de caché elegir según el tipo de contenido, y cómo evitar los errores que convierten un buen plan en una caché obsoleta o en fallos difíciles de diagnosticar.
Qué es un Service Worker y por qué cambia las reglas del juego
Un Service Worker es un archivo JavaScript que se ejecuta en un hilo separado del navegador, sin acceso directo al DOM. Funciona como un proxy programable entre tu aplicación y la red: cada petición puede interceptarse, servirse desde una caché, modificarse o redirigirse a la red según la lógica que definas.
Esta capacidad hace posible algo que ninguna técnica de caché HTTP tradicional permitía antes: seguir mostrando un sitio (o parte de su contenido) incluso sin conexión a internet, manteniendo a la vez un control preciso sobre la frescura de los datos mostrados.
El ciclo de vida de un Service Worker: instalación, activación, control
Un Service Worker atraviesa tres grandes fases: la instalación (donde se precachean los recursos esenciales mediante la API Cache Storage), la activación (donde se limpian las cachés antiguas ya obsoletas) y, finalmente, la toma de control de las páginas abiertas. Entender este ciclo es imprescindible antes de escribir la más mínima línea de lógica de caché.
Un detalle que suele pasarse por alto: un Service Worker actualizado no toma el control de inmediato, salvo que invoques explícitamente self.skipWaiting() y clients.claim(). Sin esto, tus usuarios pueden seguir navegando en varias pestañas con una versión antigua durante un buen rato.
Estrategia Cache First: priorizar la velocidad sin conexión
La estrategia Cache First consiste en servir un recurso desde la caché si está presente, y solo contactar la red cuando falta. Es la elección ideal para los recursos estáticos que cambian poco: fuentes, iconos, hojas de estilo versionadas o imágenes del tema.
La ventaja es inmediata: una carga casi instantánea, incluso en una conexión móvil deficiente. La contrapartida es que un recurso actualizado en el servidor no será visible hasta que la caché se invalide explícitamente, de ahí el interés de versionar los nombres de archivo de tus recursos.
Estrategia Network First: garantizar datos siempre actualizados
Por el contrario, la estrategia Network First intenta primero obtener el recurso desde la red, y solo recurre a la caché si falla (pérdida de conexión, timeout, error de servidor). Encaja perfectamente con contenidos que deben mantenerse al día: páginas de artículos, datos de precios, resultados de API dinámicos.
El compromiso es un tiempo de respuesta ligeramente mayor en condiciones normales, ya que la red siempre se consulta primero. Muchos equipos combinan este enfoque con un timeout corto (2-3 segundos) tras el cual la caché toma el relevo automáticamente.
Stale-While-Revalidate: lo mejor de ambos mundos
Esta estrategia híbrida sirve de inmediato la versión en caché (aunque esté potencialmente desactualizada) mientras lanza en paralelo una petición de red para refrescar la caché de cara a la próxima visita. El usuario obtiene una respuesta instantánea sin esperar nunca a la red.
Suele ser el mejor compromiso para un blog o una tienda online: el visitante ve la página rápidamente, y la versión más reciente estará disponible en su próxima visita. Librerías como Workbox de Google implementan esta lógica con apenas unas líneas de configuración.
Cómo construir una experiencia sin conexión convincente
Más allá del rendimiento, los Service Workers permiten diseñar una verdadera página de respaldo sin conexión en lugar de la pantalla de error genérica del navegador. Precachea una página “offline.html” ligera con tu identidad visual y un mensaje claro que explique la situación al usuario.
Para aplicaciones más avanzadas, la API Background Sync permite poner en cola acciones realizadas sin conexión (envío de formularios, añadir al carrito) y reproducirlas automáticamente en cuanto vuelve la conexión, sin que el usuario tenga que preocuparse por ello.
Errores comunes a evitar con los Service Workers
El error más frecuente es almacenar en caché respuestas HTML sin una estrategia de purga clara, lo que congela versiones antiguas del sitio para los visitantes recurrentes durante mucho tiempo. Nombra y versiona siempre tus cachés (ej: site-cache-v3) para poder invalidarlas de forma limpia en cada despliegue.
Otro error clásico: olvidar probar el comportamiento en HTTPS local o verificar el scope del Service Worker, que solo puede controlar las URLs situadas en su mismo nivel o por debajo en la jerarquía. Utiliza siempre la pestaña Application de Chrome DevTools para inspeccionar el estado de registro y las cachés activas.
Bien implementados, los Service Workers transforman la relación entre tu sitio y la red: cargas casi instantáneas, resiliencia ante cortes de conexión, y una experiencia de usuario que se acerca a la de una aplicación nativa. La clave del éxito está en elegir la estrategia de caché adecuada para cada tipo de recurso, en lugar de aplicar una única regla a todo el sitio.
Para profundizar en la implementación técnica y las buenas prácticas recomendadas por Google, consulta la guía oficial web.dev sobre Service Workers. Y si ya estás trabajando en una aplicación web progresiva, nuestro artículo sobre rendimiento PWA complementa perfectamente este enfoque abordando el conjunto de optimizaciones relacionadas con las aplicaciones web progresivas.