En esta documentación, se aborda el almacenamiento en caché previamente, pero no lo suficiente sobre cómo hacer que funcione bien. Esto es importante, ya que, independientemente de si usas Workbox, es fácil almacenar en caché demasiado y posiblemente desperdiciar datos y ancho de banda. Debes tener cuidado con la manera en que la carga útil de almacenamiento previo en caché afecta la experiencia del usuario.
A medida que leas este documento, ten en cuenta que estos son lineamientos generales. La arquitectura y los requisitos de tu aplicación pueden requerir que realices acciones diferentes a las que se sugieren aquí, pero estos lineamientos sirven como valores predeterminados.
Qué hacer: almacena previamente en caché los recursos estáticos críticos
Los mejores candidatos para el almacenamiento previo en caché son los recursos estáticos críticos, pero ¿cuáles se consideran recursos "críticos"? Desde la perspectiva del desarrollador, puede resultar tentador pensar en una aplicación completa como "crítica", pero lo más importante es la perspectiva del usuario. Piensa en los recursos críticos como aquellos absolutamente necesarios para proporcionar una experiencia del usuario:
- Hojas de estilo globales.
- Archivos JavaScript que brindan funcionalidad global.
- HTML de la shell de la aplicación, si se aplica a tu arquitectura.
Recordatorio: Estos son lineamientos generales, no recomendaciones estrictas. Cuando se almacenan previamente los activos en caché, es mejor preferir almacenar previamente los recursos en caché menos que más.
Qué hacer: Almacenamiento previo en caché de un resguardo sin conexión para sitios web de varias páginas
En el caso de los sitios web típicos de varias páginas, es posible que uses una estrategia de almacenamiento en caché centrado en la red o solo en la red para manejar las solicitudes de navegación.
En esos casos, te recomendamos que te asegures de que el service worker almacene previamente la caché y responda con una página de resguardo sin conexión cuando el usuario realice una solicitud de navegación sin conexión. Una forma de hacerlo en Workbox podría ser usar una estrategia solo de red con un resguardo sin conexión, y también aprovechar la precarga de navegación:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
Esto garantiza que, si un usuario se desconecta y navega a una página que no está en la caché, al menos recibirá contenido sin conexión.
Quizá puedes hacerlo: Considera el almacenamiento en caché especulativo
Es un gran "tal vez" hasta aquí, pero existe un posible beneficio en almacenar previamente en caché los recursos que solo se usan en determinadas situaciones. Piénsalo de esta manera: los usuarios se incurrirán en algunas descargas de datos adicionales por adelantado, con el beneficio especulativo de acelerar las solicitudes futuras de esos recursos.
Ahora la gran salvedad: tenga mucho cuidado si decide hacerlo. Es fácil desperdiciar datos haciendo esto y debería ser una decisión basada en datos. Además, evita almacenar previamente en caché recursos que cambian con frecuencia, ya que el usuario incurrirá en el uso de datos adicional cada vez que el código de almacenamiento previo en caché detecta una nueva revisión. Observa los flujos de usuarios en tus estadísticas para ver hacia dónde tienden a ir los usuarios. Si tienes dudas sobre el almacenamiento previo en caché de los recursos especulativamente, es probable que no lo hagas.
Posiblemente no lo hagas: prealmacenar HTML estático en caché
Este lineamiento se aplica más a los sitios estáticos en los que los archivos HTML discretos se generan mediante un generador de sitios estáticos o se crean manualmente, en lugar de generarse de forma dinámica o los proporciona un backend de la aplicación. Si tu arquitectura describe así, la mejor opción sería que no almacenes previamente en caché todos los archivos HTML de tu sitio web.
Un problema con el almacenamiento previo en caché de los archivos HTML de un sitio completo es que el lenguaje de marcado que se almacena en caché previamente siempre se entrega desde la caché más adelante hasta que se actualice el service worker. Esto es excelente para el rendimiento, pero puede provocar una pérdida significativa de la caché si el HTML de tu sitio web cambia con frecuencia.
Sin embargo, existen algunas excepciones a esta regla. Si implementas un sitio web pequeño con algunos archivos HTML estáticos, es probable que sea correcto almacenar previamente en caché todas esas páginas para que estén disponibles sin conexión. Si tienes un sitio web especialmente grande, considera almacenar en caché previamente especulativamente algunas páginas de alto valor y un resguardo sin conexión, y confía en el almacenamiento en caché del entorno de ejecución para almacenar en caché otras páginas.
No almacenar en caché imágenes responsivas ni íconos de página
Esto no es tanto una pauta general como más una regla. Las imágenes responsivas son una solución compleja para un problema complejo: tienes muchos usuarios en muchos dispositivos, cada uno de los cuales puede variar en tamaño de pantalla, densidad de píxeles y compatibilidad con formatos alternativos. Si almacenas previamente en caché un conjunto completo de imágenes responsivas, probablemente estés almacenando previamente varias imágenes en caché cuando el usuario solo termine descargando una de ellas.
Los íconos de página presentan una situación similar, ya que los sitios web suelen implementar un conjunto completo de íconos de página para diferentes situaciones. En la mayoría de los casos, solo se solicita un ícono de página, lo que hace que el almacenamiento previo en caché de un conjunto completo de marcadores de página sea un desperdicio similar.
Haz un favor a tus usuarios y no almacenes previamente en caché de imágenes responsivas ni conjuntos de íconos de página. En su lugar, utiliza el almacenamiento en caché del entorno de ejecución. Si debes almacenar previamente las imágenes en caché, usa el almacenamiento previo en caché de las imágenes que se usan con mucha frecuencia y que no forman parte de un conjunto de imágenes responsivas o íconos de página. Los SVG son menos riesgosos en términos de uso de datos, ya que un solo SVG se renderiza de manera óptima, independientemente de la densidad de píxeles de una pantalla.
Lo que no debes hacer: prealmacenar polyfills en caché
La compatibilidad variada de los navegadores con las APIs es un desafío persistente para los desarrolladores web, y el polyfilling es una de las formas en las que enfrentamos este desafío. Una forma de minimizar el costo de rendimiento de los polyfills es verificar las funciones y cargar solo los polyfills para los navegadores que los necesitan.
Debido a que la carga condicional de polyfills ocurre durante el tiempo de ejecución con respecto al entorno actual, el almacenamiento previo en caché de polyfills es una apuesta. Algunos usuarios se beneficiarán, mientras que otros terminarán desperdiciando ancho de banda para polyfills innecesarios.
No almacenes previamente los polyfills en caché. Confía en el almacenamiento en caché del entorno de ejecución para garantizar que se almacenen en caché solo en navegadores que lo requieran para evitar desperdiciar datos.
Conclusión
El almacenamiento previo en caché requiere un poco de previsión sobre los recursos que tus usuarios realmente necesitan con anticipación, pero sin duda puedes hacerlo bien de una manera que priorice el rendimiento y la confiabilidad futuros.
Si no sabes con certeza si ciertos recursos se deben almacenar en caché previamente, la mejor opción es indicarle a Workbox que excluya esos recursos y que cree una ruta de almacenamiento en caché en el entorno de ejecución para manejarlos. De cualquier manera, el almacenamiento previo en caché se tratará en detalle más adelante en esta documentación, por lo que podrás aplicar estos principios a tu lógica de almacenamiento previo en caché en el futuro.