Almacenamiento en caché de HTTP y de service worker

Las ventajas y desventajas de usar una lógica de vencimiento coherente o diferente en las capas de caché del trabajador del servicio y de la caché HTTP

Jonathan Chen
Jonathan Chen

Si bien los service workers y las AWP se están convirtiendo en estándares de las aplicaciones web modernas, el almacenamiento en caché de recursos se ha vuelto más complejo que nunca. En este artículo, se describe el panorama general del almacenamiento en caché del navegador, que incluye lo siguiente:

  • Los casos de uso y las diferencias entre el almacenamiento en caché de service worker y el almacenamiento en caché HTTP
  • Las ventajas y desventajas de las diferentes estrategias de vencimiento de la caché del trabajador de servicio en comparación con las estrategias normales de almacenamiento en caché de HTTP

Descripción general del flujo de almacenamiento en caché

En términos generales, un navegador sigue el siguiente orden de almacenamiento en caché cuando solicita un recurso:

  1. Caché del servicio de trabajo: El servicio de trabajo verifica si el recurso está en su caché y decide si mostrarlo según sus estrategias de almacenamiento en caché programadas. Ten en cuenta que esto no sucede automáticamente. Debes crear un controlador de eventos de recuperación en tu service worker y, luego, interceptar las solicitudes de red para que se entreguen desde la caché del service worker y no desde la red.
  2. Caché de HTTP (también conocida como caché del navegador): Si el recurso se encuentra en la caché de HTTP y aún no venció, el navegador usa automáticamente el recurso de la caché de HTTP.
  3. Del servidor: Si no se encuentra nada en la caché del service worker ni en la caché HTTP, el navegador se dirige a la red para solicitar el recurso. Si el recurso no está almacenado en caché en una CDN, la solicitud debe regresar al servidor de origen.

Flujo de almacenamiento en caché

Capas de almacenamiento en caché

Almacenamiento en caché de service workers

Un trabajador de servicio intercepta las solicitudes HTTP de tipo de red y usa una estrategia de almacenamiento en caché para determinar qué recursos se deben mostrar al navegador. La caché del service worker y la caché de HTTP tienen el mismo propósito general, pero la caché del service worker ofrece más capacidades de almacenamiento en caché, como un control detallado sobre qué se almacena en caché y cómo se realiza.

Controla la caché del service worker

Un trabajador de servicio intercepta las solicitudes HTTP con objetos de escucha de eventos (por lo general, el evento fetch). En este fragmento de código, se demuestra la lógica de una estrategia de almacenamiento en caché Cache-First.

Un diagrama que muestra cómo los trabajadores del servicio interceptan las solicitudes HTTP

Te recomendamos que uses Workbox para evitar reinventar la rueda. Por ejemplo, puedes registrar las rutas de URL de recursos con una sola línea de código de regex.

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

Estrategias y casos de uso de almacenamiento en caché de service workers

En la siguiente tabla, se describen las estrategias comunes de almacenamiento en caché del trabajador de servicio y cuándo es útil cada una.

Estrategias Rationale de actualización Casos de uso
Solo de red El contenido debe estar actualizado en todo momento.
  • Pagos y confirmaciones de la compra
  • Estados de cuenta
Red y recurrir a la caché Es preferible publicar el contenido actualizado. Sin embargo, si la red falla o es inestable, es aceptable entregar contenido un poco más antiguo.
  • Datos oportunos
  • Precios y tarifas (requiere renuncias de responsabilidad)
  • Estados de los pedidos
Inactivo durante la revalidación Está bien publicar contenido almacenado en caché de inmediato, pero se debe usar contenido actualizado en el futuro.
  • Feeds de noticias
  • Páginas de fichas de productos
  • Mensajes
Caché primero y recurre a la red El contenido no es crítico y se puede entregar desde la caché para mejorar el rendimiento, pero el service worker ocasionalmente debe comprobar si hay actualizaciones.
  • Shells de apps
  • Recursos comunes
Solo caché El contenido rara vez cambia.
  • Contenido estático

Beneficios adicionales del almacenamiento en caché de service worker

Además del control detallado de la lógica de almacenamiento en caché, el almacenamiento en caché del service worker también proporciona lo siguiente:

  • Más memoria y espacio de almacenamiento para tu origen: El navegador asigna recursos de caché HTTP por origen. En otras palabras, si tienes varios subdominios, todos comparten la misma caché HTTP. No hay garantía de que el contenido de tu origen o dominio permanezca en la caché HTTP durante mucho tiempo. Por ejemplo, un usuario puede purgar la caché limpiando manualmente la IU de configuración de un navegador o activando una recarga forzada en una página. Con una caché de trabajador de servicio, es mucho más probable que tu contenido almacenado en caché permanezca en caché. Consulta Almacenamiento persistente para obtener más información.
  • Mayor flexibilidad con redes inestables o experiencias sin conexión: Con la caché HTTP, solo tienes una opción binaria: si el recurso se almacena en caché o no. Con el almacenamiento en caché del trabajador del servicio, puedes mitigar los pequeños "problemas" con mayor facilidad (con la estrategia "stale-while-revalidate"), ofrecer una experiencia sin conexión completa (con la estrategia "Cache only") o incluso algo intermedio, como IUs personalizadas con partes de la página que provienen de la caché del trabajador del servicio y algunas partes excluidas (con la estrategia "Set catch handler") cuando corresponda.

Almacenamiento en caché de HTTP

La primera vez que un navegador carga una página web y los recursos relacionados, los almacena en su caché HTTP. Por lo general, los navegadores habilitan automáticamente la caché HTTP, a menos que el usuario final la inhabilite de forma explícita.

El uso del almacenamiento en caché HTTP implica depender del servidor para determinar cuándo almacenar en caché un recurso y durante cuánto tiempo.

Controla el vencimiento de la caché HTTP con encabezados de respuesta HTTP

Cuando un servidor responde a una solicitud de un recurso del navegador, usa encabezados de respuesta HTTP para indicarle al navegador durante cuánto tiempo debe almacenar el recurso en caché. Consulta Encabezados de respuesta: configura tu servidor web para obtener más información.

Estrategias y casos de uso de almacenamiento en caché de HTTP

La caché de HTTP es mucho más simple que la caché de service worker, ya que solo se ocupa de la lógica de vencimiento de recursos basados en el tiempo (TTL). Consulta ¿Qué valores de encabezado de respuesta deberías usar? y Resumen para obtener más información sobre las estrategias de almacenamiento en caché de HTTP.

Cómo diseñar tu lógica de vencimiento de la caché

En esta sección, se explican las ventajas y desventajas de usar una lógica de vencimiento coherente en las capas de caché del trabajador del servicio y de la caché HTTP, así como las ventajas y desventajas de usar una lógica de vencimiento independiente en estas capas.

En el siguiente Glitch, se muestra cómo funcionan la caché de service worker y la caché HTTP en diferentes situaciones:

Lógica de vencimiento coherente para todas las capas de caché

Para demostrar las ventajas y desventajas, analizaremos 3 situaciones: a largo plazo, mediano plazo y a corto plazo.

Situaciones Almacenamiento en caché a largo plazo Almacenamiento en caché a mediano plazo Almacenamiento en caché a corto plazo
Estrategia de almacenamiento en caché del service worker Caché y recurrir a la red Stale-while-revalidate Red y recurrir a la caché
TTL en caché del service worker 30 días 1 día 10 min
HTTP cache max-age 30 días 1 día 10 min

Situación: Almacenamiento en caché a largo plazo (caché y recurrir a la red)

  • Cuando un recurso almacenado en caché es válido (<= 30 días): El trabajador de servicio muestra el recurso almacenado en caché de inmediato sin ir a la red.
  • Cuando un recurso almacenado en caché vence (> 30 días): El trabajador de servicio se dirige a la red para recuperar el recurso. El navegador no tiene una copia del recurso en su caché HTTP, por lo que se dirige al servidor para obtenerlo.

Con: En esta situación, la caché HTTP proporciona menos valor porque el navegador siempre pasará la solicitud al servidor cuando venza la caché en el service worker.

Situación: Almacenamiento en caché a mediano plazo (Stale-while-revalidate)

  • Cuando un recurso almacenado en caché es válido (<= 1 día): El service worker muestra el recurso almacenado en caché de inmediato y va a la red para recuperarlo. El navegador tiene una copia del recurso en su caché HTTP, por lo que muestra esa copia al trabajador del servicio.
  • Cuando un recurso almacenado en caché vence (> 1 día): El trabajador de servicio muestra el recurso almacenado en caché de inmediato y va a la red para recuperarlo. El navegador no tiene una copia del recurso en su caché HTTP, por lo que va al servidor para recuperarlo.

Contras: El trabajador del servicio requiere un bloqueo adicional de la caché para anular la caché HTTP con el fin de aprovechar al máximo el paso "volver a validar".

Situación: Almacenamiento en caché a corto plazo (red y recurrir a la caché)

  • Cuando un recurso almacenado en caché es válido (<= 10 min): El trabajador de servicio va a la red para recuperar el recurso. El navegador tiene una copia del recurso en su caché HTTP, por lo que se la muestra al service worker sin pasar del lado del servidor.
  • Cuando un recurso almacenado en caché vence (> 10 min): El service worker muestra el recurso almacenado en caché de inmediato y va a la red para recuperarlo. El navegador no tiene una copia del recurso en su caché HTTP, por lo que va al servidor para recuperarlo.

Contras: Al igual que en el caso de la caché a mediano plazo, el trabajador de servicio requiere una lógica adicional para anular la caché HTTP y recuperar el recurso más reciente del servidor.

Trabajador de servicio en todas las situaciones

En todas las situaciones, la caché del service worker aún puede mostrar recursos almacenados en caché cuando la red es inestable. Por otro lado, la caché HTTP no es confiable cuando la red es inestable o inactiva.

Diferente lógica de vencimiento de la caché en la caché del trabajador del servicio y las capas HTTP

Para demostrar los pros y los contras, volveremos a analizar las situaciones a largo, mediano y corto plazo.

Situaciones Almacenamiento en caché a largo plazo Almacenamiento en caché a mediano plazo Almacenamiento en caché a corto plazo
Estrategia de almacenamiento en caché del service worker Caché y recurrir a la red Stale-while-revalidate Red y recurrir a la caché
TTL del almacenamiento en caché del servicio de trabajo 90 días 30 días 1 día
Antigüedad máxima de la caché HTTP 30 días 1 día 10 min

Situación: Almacenamiento en caché a largo plazo (caché y recurrir a la red)

  • Cuando un recurso almacenado en caché es válido en la caché de service worker (<= 90 días), el service worker muestra el recurso almacenado en caché de inmediato.
  • Cuando un recurso almacenado en caché vence en la caché del service worker (> 90 días), este se dirige a la red para recuperar el recurso. El navegador no tiene una copia del recurso en su caché HTTP, por lo que se envía al servidor.

Ventajas y desventajas:

  • Ventaja: Los usuarios experimentan una respuesta instantánea, ya que el trabajador del servicio muestra los recursos almacenados en caché de inmediato.
  • Ventaja: El trabajador de servicio tiene un control más detallado de cuándo usar su caché y cuándo solicitar versiones nuevas de los recursos.
  • Contras: Se requiere una estrategia de almacenamiento en caché de trabajadores del servicio bien definida.

Situación: Almacenamiento en caché a medio plazo (inactivo durante la revalidación)

  • Cuando un recurso almacenado en caché es válido en la caché del trabajador de servicio (<= 30 días): El trabajador de servicio muestra el recurso almacenado en caché de inmediato.
  • Cuando un recurso almacenado en caché vence en la caché del service worker (> 30 días): El service worker va a la red para obtener el recurso. El navegador no tiene una copia del recurso en su caché HTTP, por lo que se envía al servidor.

Ventajas y desventajas:

  • Ventaja: Los usuarios experimentan una respuesta instantánea, ya que el service worker muestra los recursos almacenados en caché de inmediato.
  • Ventaja: El service worker puede asegurarse de que la solicitud next de una URL determinada use una respuesta nueva de la red, gracias a la revalidación que ocurre "en segundo plano".
  • Contras: Se requiere una estrategia de almacenamiento en caché de trabajadores del servicio bien definida.

Situación: Almacenamiento en caché de corta duración (red que recurre a la caché)

  • Cuando un recurso almacenado en caché es válido en la caché del service worker (<= 1 día): El service worker va a la red para obtener el recurso. El navegador muestra el recurso de la caché HTTP si está allí. Si la red no está disponible, el service worker muestra el recurso de la caché del service worker.
  • Cuando un recurso almacenado en caché vence en la caché del service worker (más de 1 día), el service worker va a la red para recuperar el recurso. El navegador recupera los recursos a través de la red, ya que la versión almacenada en caché en su caché HTTP caducó.

Ventajas y desventajas:

  • Ventaja: Cuando la red es inestable o no funciona, el trabajador de servicio muestra los recursos almacenados en caché de inmediato.
  • Desventajas: El trabajador de servicio requiere un bloqueo adicional de la caché para anular la caché HTTP y realizar solicitudes de "prioridad de red".

Conclusión

Dada la complejidad de la combinación de situaciones de almacenamiento en caché, no es posible diseñar una sola regla que cubra todos los casos. Sin embargo, en función de los hallazgos de las secciones anteriores, hay algunas sugerencias que debes tener en cuenta cuando diseñes tus estrategias de caché:

  • La lógica de almacenamiento en caché del trabajador de servicio no tiene que ser coherente con la lógica de vencimiento del almacenamiento en caché HTTP. Si es posible, usa una lógica de vencimiento más larga en el trabajador de servicio para otorgarle más control.
  • El almacenamiento en caché HTTP aún desempeña una función importante, pero no es confiable cuando la red es inestable o inactiva.
  • Revisa tus estrategias de almacenamiento en caché para cada recurso y asegúrate de que la estrategia de almacenamiento en caché del trabajador de servicio proporcione su valor sin entrar en conflicto con la caché HTTP.

Más información