Una función de los service workers es la capacidad de guardar archivos en la caché cuando se instala el service worker. Esto se conoce como "almacenamiento previo en caché". El almacenamiento en caché previo permite entregar archivos almacenados en caché al navegador sin ir a la red. Usa el almacenamiento en caché previo para los recursos esenciales que tu sitio necesita incluso cuando no tiene conexión: la página principal, los diseños, la imagen de resguardo y las secuencias de comandos esenciales.
¿Por qué deberías usar Workbox?
El uso de Workbox para el almacenamiento en caché previo es opcional. Puedes escribir tu propio código para almacén en caché los recursos críticos cuando se instala el servicio trabajador. El principal beneficio de usar Workbox es su control de versiones listo para usar. Tendrás muchos menos problemas para actualizar los recursos almacenados en caché con Workbox que si tuvieras que administrar el control de versiones y la actualización de estos archivos por tu cuenta.
Manifiestos de almacenamiento en caché previo
El almacenamiento previo en caché se controla mediante una lista de URLs y la información de control de versiones asociada a cada URL. En conjunto, esta información se conoce como un manifiesto de almacenamiento en caché previo. El manifiesto es la “fuente de información” del estado de todo lo que se supone que está en la caché previa de una versión determinada de una app web. Un manifiesto de caché previa, en el formato que usa Workbox, se ve de la siguiente manera:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Cuando se instala el trabajador del servicio, se crean tres entradas de caché en el almacenamiento de caché para cada una de las tres URLs enumeradas. El primer recurso tiene información de control de versiones ya incluida en su URL (app es el nombre de archivo real y .abcd1234 contiene la información de control de versiones, justo antes de la extensión de archivo .js). Las herramientas de compilación de Workbox pueden detectar esto y excluir un campo de revisión. Los otros dos recursos no incluyen información de control de versiones en sus URLs, por lo que las herramientas de compilación de Workbox crean un campo revision independiente, que contiene un hash del contenido del archivo local.
Publicación de recursos almacenados en caché previamente
Agregar elementos a la caché es solo una parte del almacenamiento previo en caché: una vez que los elementos se almacenan en caché, deben responder a las solicitudes salientes. Eso requiere un
objeto de escucha de eventos fetch en tu servicio trabajador que pueda verificar qué URLs se almacenaron previamente en caché y mostrar esas respuestas almacenadas en caché de forma confiable, sin pasar por la
red en el proceso. Dado que el service worker verifica la caché en busca de respuestas (y las usa antes de la red), esto se denomina estrategia que prioriza la caché.
Actualizaciones eficientes
Un manifiesto de almacenamiento en caché previo proporciona una representación exacta del estado de la caché esperado. Si cambia una combinación de URL o revisión en el manifiesto, un trabajador de servicio sabe que la entrada almacenada en caché anterior ya no es válida y debe actualizarse. Solo se necesita una sola solicitud de red, que el navegador realiza automáticamente como parte de la verificación de actualización del trabajador del servicio, para determinar qué URLs almacenadas en caché deben actualizarse.
Actualizaciones de los recursos almacenados en caché
A medida que lanzas versiones nuevas de tu app web con el tiempo, debes mantener actualizadas las URLs almacenadas en caché previamente, almacenar en caché activos nuevos y borrar las entradas anticuadas. Siempre que sigas generando un manifiesto de almacenamiento en caché completo cada vez que reconstruyas tu sitio, ese manifiesto servirá como "fuente de información" para el estado de almacenamiento en caché en cualquier momento.
Si hay una URL existente con un nuevo campo de revisión o si se agregaron o quitaron URLs del manifiesto, es una señal para tu servicio trabajador de que se deben realizar actualizaciones, como parte de los controladores de eventos install y activate. Por ejemplo, si realizaste algunos cambios en tu sitio y
lo volviste a compilar, es posible que el último manifiesto de almacenamiento previo en caché haya sufrido los
siguientes cambios:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Cada uno de estos cambios le indica al service worker que se deben realizar solicitudes nuevas para actualizar las entradas almacenadas en caché anteriormente ('offline.svg' y 'index.html') y almacenar en caché URLs nuevas ('app.ffaa4455.js'), así como eliminaciones para limpiar las URLs que ya no se usan ('app.abcd1234.js').
Experiencia real de instalación en la "tienda de aplicaciones"
Otro beneficio del almacenamiento en caché previo es que puedes ofrecer a los usuarios una experiencia que, de otro modo, sería difícil lograr fuera de una instalación de "tienda de aplicaciones". Una vez que un usuario visita cualquier página de tu app web por primera vez, puedes almacenar en caché previamente todas las URLs necesarias para mostrar cualquiera de las vistas de tu app web con anticipación, sin tener que esperar hasta que visite cada vista individual.
Cuando un usuario instala una app, espera que todas sus partes se muestren rápidamente, no solo las vistas que visitó en el pasado. El almacenamiento previo en caché brinda esa misma experiencia a las aplicaciones web.
¿Cuáles de tus recursos deben almacenarse en caché de antemano?
Consulta la guía Cómo identificar lo que se carga para obtener una buena idea de qué URLs es más conveniente almacenar en caché de forma previa. La regla general es almacenar en caché previamente cualquier elemento HTML, JavaScript o CSS que se cargue al principio y que sea fundamental para mostrar la estructura básica de una página determinada.
Es preferible evitar el almacenamiento en caché previo de contenido multimedia o de otros recursos que se carguen más adelante (a menos que sea fundamental para la funcionalidad de tu app web). En su lugar, usa una estrategia de almacenamiento en caché en el entorno de ejecución para asegurarte de que estos elementos se almacenen en caché mientras se usan.
Ten siempre en cuenta que la precaché implica usar el ancho de banda y el almacenamiento de la red en el dispositivo de un usuario (al igual que lo hace la instalación de una app desde una tienda de aplicaciones). Depende de ti, como desarrollador, almacenar en caché previamente con buen criterio y evitar un manifiesto de almacenamiento previo en caché sobrecargado.
Las herramientas de compilación de la caché previa te indican la cantidad de elementos en el manifiesto de almacenamiento previo en caché y el tamaño total de su carga útil.
Los visitantes recurrentes de tu app web se benefician a largo plazo del costo inicial del almacenamiento en caché previo, ya que la capacidad que ofrece para evitar la red se paga rápidamente en ancho de banda ahorrado con el tiempo.