Estás limitado a una lucha por la confiabilidad de la red. La caché HTTP del navegador es tu primera línea de defensa, pero como ya sabes, solo es muy eficaz cuando se cargan las URLs con versiones que ya visitaste. Por sí sola, la caché HTTP no es suficiente.
Afortunadamente, hay dos herramientas más nuevas disponibles que te ayudarán a cambiar el curso a tu favor: los service Workers y la API de Cache Storage. Como se usan con mucha frecuencia, vale la pena conocerlas al mismo tiempo.
Trabajadores de servicio
Un service worker está integrado en el navegador y se controla con un poco de código JavaScript adicional que eres responsable de crear. Se implementa junto con los otros archivos que conforman la aplicación web real.
Un service worker tiene poderes especiales. Entre otras tareas, espera pacientemente a que la app web realice una solicitud saliente y, luego, entra en acción mediante su intercepción. Tú decides qué hacer con esta solicitud interceptada.
Para algunas solicitudes, la mejor medida podría ser permitir que la solicitud continúe en la red, como sucedería si no hubiera ningún service worker.
Sin embargo, para otras solicitudes, puedes aprovechar algo más flexible que la caché HTTP del navegador y mostrar una respuesta rápida y confiable sin tener que preocuparte por la red. Eso implica usar la otra pieza del rompecabezas: la API de Cache Storage.
La API de Cache Storage
La API de Cache Storage abre un nuevo rango de posibilidades, ya que brinda a los desarrolladores control total sobre el contenido de la caché. En lugar de depender de una combinación de encabezados HTTP y la heuristics integrada del navegador, la API de Cache Storage expone un enfoque de almacenamiento en caché basado en código. La API de almacenamiento en caché es particularmente útil cuando se la llama desde el JavaScript de tu service worker.
Espera... ¿Hay otra caché en la que pensar ahora?
Probablemente te estés haciendo preguntas como “¿Todavía necesito configurar mis encabezados HTTP?” y “¿Qué puedo hacer con esta nueva caché que no era posible con la caché HTTP?”. No te preocupes, esas son reacciones naturales.
Te recomendamos que configures los encabezados Cache-Control en tu servidor web, incluso si sabes que estás usando la API de Cache Storage. Por lo general, puedes configurar Cache-Control: no-cache para las URLs sin versiones o Cache-Control: max-age=31536000 para las URLs que contienen información sobre el control de versiones, como hashes.
Cuando se propaga la caché de la API de Cache Storage, el navegador
de forma predeterminada busca entradas existentes
en la caché HTTP y las usa si las encuentra. Si agregas URLs con versión a la caché de la API de Cache Storage, el navegador evitará una solicitud de red adicional. El otro lado es que, si usas encabezados Cache-Control mal configurados, como especificar una vida útil de caché de larga duración para una URL sin versiones, puedes empeorar la situación si agregas ese contenido inactivo a la API de Cache Storage. Ordenar el comportamiento de la caché HTTP
es un requisito para usar la API de Cache Storage de manera eficaz.
En cuanto a lo que ahora es posible con esta nueva API, la respuesta es: mucho. Entre algunos de los usos comunes que serían difíciles o imposibles solo con la caché HTTP, se incluyen los siguientes:
- Usa un enfoque de “actualización en segundo plano” para el contenido almacenado en caché, lo que se conoce como inactividad durante la revalidación.
- Limita la cantidad máxima de elementos que se deben almacenar en caché y, luego, implementa una política de vencimiento personalizada para quitar elementos una vez que se alcance ese límite.
- Compara las respuestas de red actualizadas y previamente almacenadas en caché para ver si cambió algo y permite que el usuario actualice el contenido (por ejemplo, con un botón) cuando los datos realmente se hayan actualizado.
Consulta Una guía rápida de la API de Cache para obtener más información.
Aspectos básicos de la API
Hay algunos aspectos que debes tener en cuenta acerca del diseño de la API:
- Los objetos
Requestse usan como claves únicas cuando se leen y escriben en estas cachés. Para tu comodidad, puedes pasar una cadena de URL como'https://example.com/index.html'como clave, en lugar de un objetoRequestreal, y la API lo controlará automáticamente. - Los objetos
Responsese usan como valores en estas cachés. - El encabezado
Cache-Controlen unResponsedeterminado se ignora de manera efectiva cuando se almacenan datos en caché. No hay verificaciones de vencimiento o actualización integradas y automáticas, y una vez que almacenes un elemento en la caché, se mantendrá hasta que tu código lo quite de forma explícita. (Hay bibliotecas para simplificar el mantenimiento de la caché por ti. Se abordarán más adelante en esta serie). - A diferencia de las APIs síncronas más antiguas, como
LocalStorage, todas las operaciones de la API de Cache Storage son asíncronas.
Un desvío rápido: promesas y async/await
Los service workers y la API de Cache Storage usan conceptos de programación asíncrona.
En particular, dependen en gran medida de las promesas para representar el resultado futuro de las operaciones asíncronas. Antes de comenzar, debes familiarizarte con las promesas y la sintaxis relacionada async/await.
No implementes ese código... todavía
Si bien proporcionan una base importante y se pueden usar sin modificaciones, los service worker y la API de Cache Storage son, en la práctica, componentes básicos de nivel inferior, con una serie de casos extremos y trampas. Existen algunas herramientas de nivel superior que pueden ayudar a suavizar las partes difíciles de esas APIs y proporcionar todo lo que necesitas para compilar un service worker listo para la producción. En la siguiente guía, se aborda una de esas herramientas: Workbox.