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 en caché previo". 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
La caché previa se basa en una lista de URLs y la información de control de versiones asociada para 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 recursos a la caché es solo una parte de la historia del almacenamiento en caché previo. Una vez que los recursos 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 trabajador de servicio verifica la caché en busca de respuestas (y las usa antes que la red), esto se denomina estrategia de prioridad de 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 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 hiciste algunos cambios en tu sitio y
lo volviste a compilar, es posible que el manifiesto de almacenamiento en caché más reciente haya sometido a 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 las eliminaciones para limpiar las URLs que ya no se usan ('app.abcd1234.js').
Experiencia de instalación de "tienda de aplicaciones" real
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 en caché previo brinda esa misma experiencia a las apps 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é previamente. 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é del tiempo de ejecución para asegurarte de que estos recursos se almacenen en caché sobre la marcha.
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). Como desarrollador, depende de ti usar la caché previa con prudencia y evitar un manifiesto de caché previa demasiado grande.
Las herramientas de compilación de Workbox te ayudan a indicar la cantidad de elementos en el manifiesto de almacenamiento en caché anticipado, así como el tamaño total de la carga útil de almacenamiento en caché anticipado.
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.