Cuando vuelves a una web que ya habías visitado y carga casi de forma instantánea, aunque tu conexión no sea especialmente buena, hay una posibilidad real de que haya un service worker trabajando entre bastidores. No es magia del navegador: es un pequeño programa que se interpone, con tu permiso, entre tu navegador y la red, y decide qué hacer con cada petición antes de que llegue al servidor.
Qué hace exactamente
Un service worker es un script que el navegador ejecuta en un hilo separado, al margen de la página, con la particularidad de que puede seguir activo incluso cuando has cerrado la pestaña. Su ciclo de vida tiene tres momentos clave: se instala una vez (y ahí suele guardar en caché los archivos esenciales del sitio), se activa tomando el control de las páginas que gestiona, y a partir de ahí intercepta cada petición de red que el navegador hace — una imagen, una hoja de estilos, una llamada a una API — y decide si la sirve desde la caché local, la pide a la red, o alguna combinación de ambas.
Por motivos de seguridad evidentes —estamos hablando de un script con capacidad de interceptar todo el tráfico de una web—, solo funciona sobre HTTPS. No hay forma de usarlo en un sitio sin certificado SSL.
Las estrategias de caché, explicadas sin jerga
No hay una sola forma de decidir qué hacer con cada petición; hay varias estrategias, y elegir la correcta para cada tipo de recurso es donde está el criterio real.
Cache-first (la caché primero). Si el recurso ya está guardado localmente, se sirve desde ahí sin ni siquiera preguntar a la red. Es la estrategia más rápida posible, y tiene sentido para recursos que casi nunca cambian: el logo, las tipografías, los iconos.
Network-first (la red primero). Se intenta pedir el recurso actualizado a la red, y solo si falla —sin conexión, servidor caído— se recurre a la versión en caché como respaldo. Tiene sentido para contenido que necesita estar siempre al día, como precios o disponibilidad.
Stale-while-revalidate (lo de siempre, mientras se actualiza). Sirve inmediatamente la versión en caché —aunque pueda estar algo desactualizada— y, en paralelo, pide la versión nueva a la red para tenerla lista la próxima vez. Es un término medio que prioriza la velocidad percibida sin renunciar del todo a la actualización.
Lo que gana tu web con uno bien configurado
El beneficio más evidente es la velocidad en visitas repetidas: si los archivos ya están en caché, no hay que volver a descargarlos, y la carga se siente instantánea. El segundo beneficio, menos evidente pero igual de valioso, es la resiliencia: una web con service worker puede seguir mostrando contenido —aunque sea una versión algo antigua— cuando la conexión del usuario falla, o incluso cuando tu propio servidor tiene un problema puntual.
Para audiencias con conectividad poco fiable, o para proyectos donde el usuario vuelve con frecuencia a consultar la misma información, esto no es un lujo técnico: es una mejora de experiencia directamente medible.
Lo que no es gratis
Un service worker añade una capa de complejidad que hay que mantener y depurar, y los errores en esta capa son de los más confusos de diagnosticar: una caché mal invalidada puede hacer que un usuario siga viendo una versión vieja de tu web días después de haberla actualizado, sin que recargar la página normal lo solucione. El versionado de caché —asegurarse de que cada actualización invalida lo que hay que invalidar y conserva lo que no— es la parte que separa una implementación que ayuda de una que genera quejas de soporte.
También hay que recordar que, al ejecutarse en segundo plano, un service worker mal diseñado puede consumir batería y datos sin que el usuario lo note, descargando en segundo plano contenido que quizá no necesite.
¿Lo necesita una web corporativa pequeña?
Aquí está la respuesta honesta: probablemente no, y está bien que así sea. Un sitio Jamstack bien construido ya se beneficia de cabeceras de caché HTTP estándar —mucho más simples de configurar y de razonar— que cubren buena parte de lo que un service worker aportaría para un catálogo de páginas que cambia poco. Añadir la complejidad de un service worker tiene sentido cuando hay un motivo concreto que lo justifique: una aplicación con uso recurrente y frecuente, una audiencia con conectividad realmente poco fiable, o la necesidad explícita de que la web siga funcionando sin conexión.
Para la web de un despacho, una clínica o un comercio local, ese escenario rara vez se da. La velocidad que de verdad importa en esos casos —la primera visita, la que decide si alguien se queda o se va— depende mucho más de un HTML ligero, imágenes bien optimizadas y una arquitectura sin capas innecesarias que de una capa de caché avanzada que resuelve un problema que esa web no tiene.
Un service worker es una herramienta potente para el problema correcto, no un adorno técnico que toda web moderna deba llevar por sistema. Antes de añadir uno, vale la pena preguntarse qué problema concreto va a resolver — y si la respuesta no es clara, probablemente la web ya está bien sin él.
