Una característica de los service worker 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 en caché para los recursos esenciales que tu sitio necesita, incluso cuando está sin 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 elementos críticos cuando se instala el service worker. El principal beneficio de usar Workbox es su control de versiones listo para usar. Tendrás muchos menos problemas para actualizar los elementos 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é
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 precaché. El manifiesto es la "fuente de información" para el estado de todo lo que debe estar en la caché previa de una versión determinada de una app web. Un manifiesto de precaché, en el formato que usa Workbox, tiene el siguiente aspecto:
[{
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 enumeradas. El primer recurso tiene información de control de versiones ya incluida en su URL (app es el nombre real del archivo y .abcd1234 contiene la información sobre el 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 elementos 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 almacenados en caché previamente
Agregar elementos a la caché es solo una parte del proceso de almacenamiento previo en caché: una vez que los recursos 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 en caché previamente y mostrar esas respuestas almacenadas en caché de manera confiable, sin pasar por la red en el proceso. Dado que el service worker busca respuestas en la caché
(y las usa antes que 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 esperado de la caché. Si cambia una combinación de URL y revisión en el manifiesto, un service worker sabe que la entrada almacenada en caché anterior ya no es válida y se debe actualizar. 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 previamente en caché deben actualizarse.
Actualizaciones de recursos almacenados en caché previamente
A medida que lanzas versiones nuevas de tu app web a lo largo del tiempo, deberás mantener actualizadas las URLs que se almacenaron previamente en caché, almacenar previamente los elementos nuevos en caché y borrar las entradas desactualizadas. Siempre y cuando sigas generando un manifiesto de precaché completo cada vez que vuelvas a compilar tu sitio, ese manifiesto servirá como "fuente de confianza" para el estado de precaché en cualquier momento.
Si hay una URL existente con un campo de revisión nuevo, o si se agregó o quitó alguna URL del manifiesto, eso es una señal para tu service worker de que las actualizaciones deben realizarse, como parte de los controladores de eventos install y activate. Por ejemplo, si modificaste el sitio y lo volviste a compilar, es posible que el manifiesto de precaché más reciente 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 previamente almacenadas en caché ('offline.svg' y 'index.html') y almacenar en caché las URL nuevas ('app.ffaa4455.js'), además de realizar eliminaciones para limpiar las URLs que ya no se usan ('app.abcd1234.js').
Una verdadera experiencia de instalación de "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 almacenar 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 visite cada vista individual.
Cuando un usuario instala una app, espera que se muestren todas las partes con rapidez, no solo las vistas a las que visitó en el pasado. El almacenamiento en caché brinda esa misma experiencia a las apps web.
¿Cuál de tus recursos se debería almacenar previamente en caché?
Consulta la guía Cómo identificar lo que se está cargando para tener una buena idea de qué URLs tienen más sentido almacenar en caché. La regla general es almacenar previamente en caché cualquier código HTML, JavaScript o CSS que se cargue al principio y es fundamental para mostrar la estructura básica de una página determinada.
Es preferible evitar el almacenamiento previo en caché de contenido multimedia o cualquier otro elemento que se cargue más tarde (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 los recursos se almacenen en caché sobre la marcha.
Siempre ten en cuenta que el almacenamiento previo en caché implica el uso del ancho de banda y el almacenamiento de la red en el dispositivo de un usuario (al igual que la instalación de una app de una tienda de aplicaciones). Como desarrollador, depende de ti almacenar en caché previamente con cuidado y evitar un manifiesto de precaché ampliado.
Las herramientas de compilación de Workbox te ayudan a indicar la cantidad de elementos en el manifiesto de precaché y el tamaño total de la carga útil de precaché.
Los visitantes recurrentes de tu app web se benefician a largo plazo del costo inicial del almacenamiento previo, ya que la capacidad que ofrece para evitar la red se paga rápidamente en ancho de banda ahorrado con el tiempo.