Las aplicaciones web progresivas han cambiado la forma en que interactuamos con la web, y detrás de su rendimiento y capacidad offline existe un componente fundamental que lo hace posible. Esa pieza clave son los service workers, una propuesta impulsada principalmente por el equipo de Google Chrome que habilita funcionalidades avanzadas directamente en el navegador.
¿Qué es un service worker y por qué es tan importante?
Un service worker es una secuencia de comandos que se ejecuta en segundo plano dentro del navegador [00:18]. Esto significa que no necesitas tener la aplicación web abierta con todas las instrucciones activas para que ciertas tareas se realicen. Funcionalidades como push notifications, almacenamiento en caché y deep links dependen directamente de este mecanismo.
Lo más relevante es que actúa como un intermediario entre tu navegador y el servidor. Cada vez que haces una petición, ya sea de HTML, CSS o JavaScript, el service worker la intercepta antes de que llegue o regrese del servidor [00:50].
¿Cómo funciona el caché de recursos con service workers?
El flujo básico es sencillo pero poderoso. Cuando visitas un sitio web por primera vez, el navegador descarga todos los recursos necesarios: HTML, CSS y JavaScript. El service worker intercepta esas peticiones y almacena los archivos en un caché local [01:10].
- La primera visita descarga los recursos desde el servidor (network).
- El service worker guarda esos recursos en caché automáticamente.
- En visitas posteriores, los archivos se sirven desde el caché sin ir al servidor.
- El tiempo de latencia se reduce drásticamente.
Esto hace que la aplicación sea muchísimo más rápida a partir de la segunda visita, porque el usuario ya no necesita volver a descargar lo que ya obtuvo previamente [01:25].
¿Qué sucede cuando el caché no está actualizado?
Existe un flujo más complejo para manejar situaciones donde el contenido cacheado ya no es la versión más reciente [01:45]. En ese caso, el service worker toma una decisión programada: si detecta que el recurso no está actualizado, va directamente al network y solicita la versión nueva. Todo esto se controla mediante código que define las estrategias de caché.
¿Qué pasa si no hay conexión a Internet?
Aquí es donde los service workers brillan con mayor fuerza. Si la conexión es lenta o simplemente no existe, el service worker sirve todo el contenido directamente desde el caché [02:05]. El usuario puede seguir navegando por toda la aplicación sin estar conectado a Internet, porque los recursos ya están almacenados localmente.
¿Qué estrategias de caché se pueden implementar en Angular?
Las estrategias de caché determinan cómo se prioriza el origen de los datos, y se pueden configurar directamente al trabajar con service workers dentro de Angular [02:30].
- Prioridad al network: la aplicación intenta obtener datos de Internet primero y solo recurre al caché si la conexión falla o es lenta.
- Prioridad al caché: la aplicación sirve contenido desde el caché por defecto y solo consulta el network cuando no encuentra el recurso almacenado.
Estas dos aproximaciones permiten adaptar el comportamiento de la aplicación según las necesidades del proyecto y la experiencia que se quiera ofrecer al usuario.
El concepto de intercepción de peticiones es la base de todo este sistema. Sin esa capacidad del service worker para situarse entre el navegador y el servidor, ninguna de estas funcionalidades sería posible. Comprender este flujo completo, desde la primera carga hasta el manejo de errores de red, es fundamental para construir aplicaciones web progresivas robustas y eficientes.
Si ya trabajas con Angular o estás por comenzar, ¿qué estrategia de caché crees que sería más útil para tu próximo proyecto? Comparte tu experiencia en los comentarios.
