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 previo en caché permite entregar archivos almacenados en caché al navegador sin tener que ir a la red. Usa el almacenamiento previo en caché para los elementos críticos que tu sitio necesita incluso cuando no tiene conexión: página principal, estilos, imagen de resguardo y secuencias de comandos esenciales.
¿Por qué deberías usar Workbox?
El uso de Workbox para el almacenamiento previo en caché es opcional. Puedes escribir tu propio código para almacenar previamente en caché los recursos fundamentales cuando el service worker se está instalando. El principal beneficio de usar Workbox es su control de versiones listo para usar. Te encontrarás con muchos menos problemas para actualizar los recursos previamente 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 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 manifiesto de almacenamiento previo en caché. El manifiesto es la "fuente de información" para el estado de todo lo que se debe incluir en la caché previa de una versión determinada de una app web. Un manifiesto de almacenamiento previo en caché, 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 service worker, se crean tres entradas de caché en el almacenamiento en caché para cada una de las tres URLs de la lista. El primer recurso tiene información sobre el control de versiones ya incluida en su URL (app es el nombre real del archivo y .abcd1234 contiene la información del control de versiones, justo antes de la extensión del 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 sobre el 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.
Entrega recursos previamente almacenados en caché
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. Esto requiere un
objeto de escucha de eventos fetch en tu service worker que pueda verificar qué URLs
se almacenaron previamente en caché y mostrar esas respuestas almacenadas en caché de manera 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 previo en caché proporciona una representación exacta del estado de caché esperado. Si cambia una combinación de URL/revisión en el manifiesto, un service worker sabe que la entrada almacenada en caché anterior ya no es válida y debe actualizarla. Solo se necesita una única solicitud de red, que el navegador realiza automáticamente como parte de la verificación de actualización del service worker, para determinar qué URLs almacenadas en caché deben actualizarse.
Actualizaciones de recursos previamente almacenados en caché
A medida que lanzas versiones nuevas de tu app web con el tiempo, debes mantener actualizadas las URLs que se almacenaron en caché previamente, almacenar previamente en caché los elementos nuevos y borrar las entradas desactualizadas. Siempre y cuando sigas generando un manifiesto completo de almacenamiento previo en caché cada vez que vuelvas a compilar tu sitio, este servirá como la "fuente de confianza" para el estado de tu almacenamiento previo en caché en cualquier momento.
Si hay una URL existente con un campo de revisión nuevo, o si se agregaron o quitaron del manifiesto, esto es una señal para tu service worker de que se deben realizar las 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 previamente en caché ('offline.svg' y 'index.html')
y almacenar en caché las URLs nuevas ('app.ffaa4455.js'), además de eliminaciones para limpiar las URLs
que ya no se usan ('app.abcd1234.js').
Experiencia de instalación real en la "tienda de aplicaciones"
Otro beneficio del almacenamiento previo en caché es que puedes brindar a los usuarios una experiencia que, de otro modo, sería difícil de lograr fuera de una instalación de "tienda de aplicaciones". Cuando un usuario visita cualquier página de tu app web por primera vez, puedes prealmacenar en caché todas las URLs necesarias para mostrar cualquiera de las vistas de tu app web con anticipación, sin tener que esperar hasta que visiten cada vista individual.
Cuando un usuario instala una app, espera que todas las partes se muestren rápidamente, no solo las vistas a las que consiguió en el pasado. El almacenamiento previo en caché brinda esa misma experiencia a las aplicaciones web.
¿Cuál de tus elementos se debe almacenar en caché previamente?
Consulta la guía Cómo identificar lo que se carga para obtener un buen panorama de las URLs con más sentido almacenar en caché. La regla general es almacenar previamente en caché cualquier código HTML, JavaScript o CSS que se cargue con anticipación y es fundamental para mostrar la estructura básica de una página determinada.
Se recomienda evitar el almacenamiento previo en caché del contenido multimedia o de otros elementos que se carguen más tarde (a menos que sea fundamental para la funcionalidad de la 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.
Siempre ten en cuenta que el almacenamiento previo en caché implica usar ancho de banda de red y almacenamiento 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 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 en caché previo 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.