En esta documentación, se abordó el almacenamiento previo en caché anteriormente, pero no lo suficiente para comprenderlo correctamente. 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 tu carga útil de almacenamiento previo en caché afecta la experiencia del usuario.
Al leer este documento, ten en cuenta que se trata de lineamientos generales. Es posible que la arquitectura y los requisitos de la aplicación requieran que realices acciones diferentes a las que se sugieren aquí, pero estos lineamientos sirven como buenos 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 activos estáticos críticos, pero lo que se considera "crítico" activo? Desde la perspectiva del desarrollador, puede ser tentador pensar en una aplicación completa como "crítica", pero la perspectiva del usuario es lo que más importa. Piensa en los recursos críticos como aquellos totalmente necesarios para proporcionar una experiencia del usuario:
- Hojas de estilo globales
- Archivos JavaScript que proporcionan una funcionalidad global.
- HTML del shell de la aplicación, si se aplica a tu arquitectura.
Recuerda que estos son lineamientos generales, no recomendaciones difíciles. Cuando almacenas previamente los recursos en caché, es mejor pecar menos que más.
Qué hacer: Almacena en caché con anticipación 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 dependas de una estrategia de almacenamiento en caché priorizada en la red o solo en la red para abordar las solicitudes de navegación.
En esos casos, debes asegurarte de que tu service worker almacene previamente en 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 hacer esto en Workbox podría ser usar una estrategia solo de red con un resguardo sin conexión y aprovechar también 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 su caché, al menos obtendrá contenido sin conexión.
Quizás sí: Considera el almacenamiento previo en caché especulativo
Ese es un gran "tal vez" pero existe un beneficio posible en el almacenamiento previo en caché de los recursos que solo se usan en determinadas situaciones. Piénsalo de esta manera: los usuarios incurrirán en descargas de datos adicionales por adelantado, con el beneficio especulativo de acelerar las solicitudes futuras de esos recursos.
Una gran salvedad: ten mucho cuidado si decides 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é de manera especulativa los recursos que cambian con frecuencia, ya que el usuario utilizará datos adicionales cada vez que el código de almacenamiento previo en caché detecte una nueva revisión. Observa los flujos de usuarios en tus estadísticas para ver hacia dónde tienden los usuarios. Si tienes dudas sobre el almacenamiento previo en caché especulativa de los recursos, es probable que sea una buena señal que no lo hagas.
Quizás no lo hagas: almacena en caché previamente el código HTML estático.
Este lineamiento se aplica más a los sitios estáticos en los que un generador de sitios estáticos genera archivos HTML discretos o los genera manualmente, en lugar de que los genere de forma dinámica o el backend de una aplicación. Si esto describe tu arquitectura, probablemente sea mejor si no almacenas en caché previamente todos los archivos HTML de tu sitio web.
Un problema de almacenar previamente en caché los archivos HTML de un sitio completo es que el lenguaje de marcado que se prealmacena en la memoria caché ahora siempre se entregará desde la caché más tarde 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 código HTML de tu sitio web cambia con frecuencia.
Sin embargo, esta regla tiene algunas excepciones. Si implementas un sitio web pequeño con algunos archivos HTML estáticos, probablemente sea correcto almacenar previamente en caché todas esas páginas para que estén disponibles sin conexión. Si tienes un sitio web muy grande, considera almacenar previamente en caché especulativamente algunas páginas de alto valor y un resguardo sin conexión, y confía en el almacenamiento en caché del tiempo de ejecución para almacenar en caché otras páginas por ti.
No se debe prealmacenar en caché las imágenes responsivas o los íconos de página
No se trata de una pauta general, sino más bien 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 varía en tamaño de pantalla y densidad de píxeles, y admite formatos alternativos. Si almacenas previamente en caché todo un conjunto de imágenes responsivas, es probable que estés almacenando previamente varias imágenes en caché cuando es posible que el usuario solo termine descargando una de ellas.
Los favicons 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, por lo que el almacenamiento previo en caché de un conjunto de íconos de página completo también genera un desperdicio.
Hazles un favor a tus usuarios y no almacenes en caché con anticipación los conjuntos de imágenes y íconos de página responsivos. En su lugar, confía en el almacenamiento en caché del entorno de ejecución. Si debes almacenar previamente en caché las imágenes, prealmacena en caché las imágenes más usadas que no formen parte de un conjunto de imágenes responsivas o íconos de página. Los SVG son menos riesgosos en cuanto al uso de datos; un solo SVG se renderiza de manera óptima independientemente de la densidad de píxeles de una pantalla determinada.
No debes almacenar polyfills en caché previamente
La variedad de la compatibilidad de los navegadores con las APIs es un desafío continuo para los desarrolladores web, y el polyfilling es una de las formas en que se supera ese desafío. Una forma de minimizar el costo de rendimiento de polyfills es verificar las funciones y cargar polyfills solo para los navegadores que los necesiten.
Debido a que la carga condicional de polyfills se produce durante el tiempo de ejecución con respecto al entorno actual, almacenar polyfills en caché previo es una apuesta. Algunos usuarios se beneficiarán con ella, mientras que otros acabarán desperdiciando ancho de banda en polyfills innecesarios.
No almacenes polyfills en caché con anticipación. Confía en el almacenamiento en caché del entorno de ejecución para asegurarte de que se almacenen en caché solo en navegadores que los requieran para evitar desperdiciar datos.
Conclusión
El almacenamiento previo en caché requiere pensar de antemano qué recursos realmente necesitan los usuarios, pero definitivamente puedes hacerlo bien de una manera que priorice el rendimiento y la confiabilidad futuros.
Si no sabes si ciertos recursos deben almacenarse previamente en caché, la mejor opción podría ser indicarle a Workbox que excluya esos recursos y cree una ruta de almacenamiento en caché en el entorno de ejecución para manejarlos. De cualquier manera, el almacenamiento previo en caché se explica 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.