Service workers y la API de Cache Storage

Jeff Posnick

Estás en una lucha por la confiabilidad de la red. La caché HTTP del navegador es tu primera línea de defensa, pero, como aprendiste, solo es eficaz cuando se cargan URLs con versiones que visitaste anteriormente. Por sí sola, la caché HTTP no es suficiente.

Por suerte, hay dos herramientas más nuevas disponibles para ayudarte a cambiar la situación a tu favor: los service workers y la API de Cache Storage. Como se suelen usar juntos, vale la pena aprender sobre ambos al mismo tiempo.

Service workers

Un service worker está integrado en el navegador y se controla con un poco de código de JavaScript adicional que tú debes crear. Implementas este archivo junto con los demás archivos que conforman tu aplicación web real.

Un service worker tiene algunos poderes especiales. Entre otras tareas, espera con paciencia a que tu app web realice una solicitud saliente y, luego, entra en acción interceptándola. Lo que el service worker hace con esta solicitud interceptada depende de ti.

En algunas solicitudes, la mejor opción puede ser permitir que la solicitud continúe en la red, tal 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 devolver una respuesta rápida y confiable sin tener que preocuparte por la red. Esto implica usar la otra pieza del rompecabezas: la API de Cache Storage.

La API de Cache Storage

Browser Support

  • Chrome: 43.
  • Edge: 16.
  • Firefox: 41.
  • Safari: 11.1.

Source

La API de Cache Storage abre una nueva gama de posibilidades, ya que les brinda a los desarrolladores un control total sobre el contenido de la caché. En lugar de depender de una combinación de encabezados HTTP y la heurística integrada del navegador, la API de Storage de caché expone un enfoque de almacenamiento en caché basado en código. La API de Cache Storage es particularmente útil cuando se llama desde el código JavaScript de tu service worker.

Espera… ¿ahora hay otra caché en la que pensar?

Es probable que te preguntes: "¿Aún necesito configurar mis encabezados HTTP?" y "¿Qué puedo hacer con esta nueva caché que no era posible con la caché HTTP?". No te preocupes, son reacciones naturales.

Aún se recomienda que configures los encabezados Cache-Control en tu servidor web, incluso cuando sepas que estás usando la API de Cache Storage. Por lo general, puedes establecer Cache-Control: no-cache para las URLs sin versión y/o Cache-Control: max-age=31536000 para las URLs que contienen información de control de versiones, como hashes.

Cuando se propaga la caché de la API de Storage de caché, el navegador verifica de forma predeterminada si hay entradas existentes en la caché de HTTP y las usa si las encuentra. Si agregas URLs con versiones a la caché de la API de Cache Storage, el navegador evita una solicitud de red adicional. La otra cara de la moneda es que, si usas encabezados Cache-Control mal configurados, como especificar una vida útil de caché de larga duración para una URL sin versión, puedes terminar empeorando las cosas si agregas ese contenido inactivo a la API de Cache Storage. Ordenar el comportamiento de tu caché HTTP es un requisito previo 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. Algunos usos comunes que serían difíciles o imposibles de realizar solo con la caché de HTTP incluyen los siguientes:

  • Usa un enfoque de "actualización en segundo plano" para el contenido almacenado en caché, conocido como stale-while-revalidate.
  • Impón un límite en la cantidad máxima de recursos que se almacenarán 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 nuevas y las almacenadas en caché anteriormente para ver si algo cambió y permitir que el usuario actualice el contenido (con un botón, por ejemplo) cuando los datos se hayan actualizado.

Consulta La API de Cache: Una guía rápida para obtener más información.

Aspectos básicos de las APIs

Hay algunos aspectos que debes tener en cuenta sobre el diseño de la API:

  • Los objetos Request se usan como claves únicas cuando se lee y escribe en estas cachés. Para mayor comodidad, puedes pasar una cadena de URL como 'https://example.com/index.html' como la clave en lugar de un objeto Request real, y la API lo controlará automáticamente por ti.
  • Los objetos Response se usan como los valores en estas cachés.
  • El encabezado Cache-Control en un Response determinado se ignora de forma efectiva cuando se almacenan datos en caché. No hay verificaciones automáticas integradas de vencimiento o actualización, y, una vez que almacenas un elemento en la caché, este persistirá hasta que tu código lo quite de forma explícita. (Existen bibliotecas para simplificar el mantenimiento de la caché en tu nombre. 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 breve desvío: 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 tal como están, tanto los service workers como la API de Cache Storage son, en realidad, 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 producción. En la siguiente guía, se explica una de estas herramientas: Workbox.