Almacenamiento en caché de HTTP y de service worker

Las ventajas y desventajas de usar una lógica de vencimiento coherente o diferente en la caché del service worker y las capas de 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 volvió más complejo que nunca. Este artículo abarca el panorama general del almacenamiento en caché del navegador, como:

  • 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 distintas estrategias de vencimiento del almacenamiento en caché de los service workers en comparación con las habituales estrategias de almacenamiento en caché HTTP.

Descripción general del flujo de almacenamiento en caché

En un nivel alto, un navegador sigue el orden de almacenamiento en caché que se muestra a continuación cuando solicita un recurso:

  1. Caché del service worker: El service worker verifica si el recurso está en su caché. decide si devolver el recurso en sí según sus estrategias de almacenamiento en caché programadas. Nota para que esto no suceda automáticamente. Debes crear un controlador de eventos de recuperación en tu service worker e interceptar solicitudes de red para que las solicitudes se entreguen desde el servicio en la caché del trabajador, en lugar de la red.
  2. Caché de HTTP (también conocida como caché del navegador): si el recurso se encuentra en la carpeta HTTP en caché y aún no ha caducado, el navegador usa automáticamente el recurso de la caché HTTP.
  3. Del lado del servidor: si no se encuentra nada en la caché del service worker ni en la caché HTTP, navegador va a la red para solicitar el recurso. Si el recurso no se almacena en caché en una CDN, el debe volver al servidor de origen.

Flujo de almacenamiento en caché

Capas de almacenamiento en caché

Almacenamiento en caché de service worker

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

Controla la caché del service worker

Un service worker intercepta las solicitudes HTTP con el evento event objetos de escucha (por lo general, el evento fetch). Esta fragmento de código demuestra la lógica de un Caché primero estrategia de almacenamiento en caché.

Un diagrama que muestra cómo los service workers interceptan las solicitudes HTTP

Es muy recomendable usar Workbox para evitar reinventar la rueda. Por ejemplo, puedes Registra las rutas de URL de los 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é de los service workers y cuándo es útil cada una de ellas.

Estrategias Fundamentos de la actualización Casos de uso
Red solo El contenido debe estar actualizado en todo momento.
  • Pagos y confirmaciones de compras
  • Resúmenes de saldo
Red recurrir a la caché Es preferible publicar el contenido nuevo. Sin embargo, si la red falla o es inestable, aceptable para publicar contenido un poco antiguo.
  • Datos oportunos
  • Precios y tarifas (requiere una renuncia de responsabilidad)
  • Estados de los pedidos
Inactivo durante la revalidación Se puede entregar contenido almacenado en caché de inmediato, pero el contenido almacenado en caché actualizado se debe usar en la 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 puede entregarse desde la caché para mejorar el rendimiento, pero la el service worker ocasionalmente debe comprobar si hay actualizaciones.
  • Shells de aplicaciones
  • 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 el origen: El navegador asigna caché HTTP. recursos por origen. En otro palabras, si tienes varios subdominios, todos comparten la misma caché HTTP. No hay garantizar que el contenido de su origen o dominio permanezca en la caché HTTP durante mucho tiempo. Para Por ejemplo, un usuario puede borrar definitivamente la caché mediante una limpieza manual desde la IU de configuración de un navegador. que activan una recarga forzada de una página. Con una caché de service worker, tienes una capacidad la probabilidad de que tu contenido almacenado en caché permanezca almacenado en caché. Consulta Persistente Storage para obtener más información.
  • Mayor flexibilidad con redes inestables o experiencias sin conexión: Con la caché HTTP, puedes solo pueden tener una opción binaria: si el recurso se almacena en caché o no. Con almacenamiento en caché de service worker puedes mitigar pequeños “trampas” sea mucho más fácil (con la estrategia "inactivo durante la revalidación"), ofrecer una experiencia sin conexión completa (con la estrategia "Solo caché") o incluso algo en en el medio, como IUs personalizadas con partes de la página que provienen de la caché del service worker y Se excluyen algunas partes (con la estrategia "Configurar controlador de captura") cuando corresponda.

Almacenamiento en caché de HTTP

La primera vez que un navegador carga una página web y recursos relacionados, almacena estos recursos en su Caché HTTP La caché HTTP generalmente se habilita automáticamente en los navegadores, a menos que se haya inhabilitado explícitamente por el usuario final.

Usar el almacenamiento en caché de HTTP significa confiar en el servidor para determinar cuándo almacenar en caché un recurso y cómo por mucho tiempo.

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

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

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

El almacenamiento en caché de HTTP es mucho más simple que el de service worker, ya que solo lidia con lógica de vencimiento de recursos basada 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é HTTP.

Diseña la 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 el service worker de almacenamiento en caché y HTTP, así como los pros y los contras de la lógica de vencimiento separada capas.

El Glitch que aparece a continuación demuestra cómo funcionan el almacenamiento en caché de service worker y 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, a 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 Inactiva durante la revalidación Red recurre a la caché
TTL en caché del service worker 30 días 1 día 10 min
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 (<= 30 días): el service worker muestra el recurso de inmediato sin ir a la red.
  • Cuando un recurso almacenado en caché caduca (más de 30 días): El service worker 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 el recurso.

Desventaja: En este caso, el almacenamiento en caché HTTP proporciona menos valor porque el navegador siempre pasar la solicitud al servidor cuando la caché caduque en el service worker.

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

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

Desventaja: El service worker requiere almacenamiento en caché adicional para anular la caché HTTP en para aprovechar al máximo el paso "revalidar" paso.

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 service worker se dirige a la red para recuperar el recurso. El navegador tiene una copia del recurso en su caché HTTP, por lo que devuelve al service worker, sin pasarlo al servidor.
  • Cuando un recurso almacenado en caché caduca (más de 10 minutos): El service worker muestra el el recurso inmediatamente y va a la red para recuperarlo. El navegador no tiene un del recurso en su caché HTTP, de modo que se vaya del servidor para recuperarlo.

Desventaja: Al igual que en el caso de almacenamiento en caché a mediano plazo, el service worker requiere de invalidación de caché para anular la caché HTTP a fin de recuperar el último recurso del del servidor.

Service worker en todas las situaciones

En todas las situaciones, la caché del service worker aún puede devolver recursos almacenados en caché cuando la red sean inestables. 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 las capas HTTP y la caché del service worker

Para demostrar las ventajas y desventajas, volveremos a analizar a largo plazo, mediano y corto plazo. reales.

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 Inactiva durante la revalidación Red recurre a la caché
TTL en caché del service worker 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 memoria caché del service worker (<= 90 días), el servicio Worker muestra el recurso almacenado en caché de inmediato.
  • Cuando un recurso almacenado en caché vence en la caché del service worker (más de 90 días), el servicio trabajador va a la red para recuperar el recurso. El navegador no posee una copia del en su caché HTTP, por lo que se pone del lado del servidor.

Ventajas y desventajas:

  • Ventaja: Los usuarios experimentan una respuesta instantánea a medida que el service worker muestra recursos almacenados en caché. de inmediato.
  • Ventaja: El service worker tiene un control más preciso sobre cuándo usar su caché y cuándo. solicitar nuevas versiones de los recursos.
  • Desventaja: Se requiere una estrategia de almacenamiento en caché del service worker 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é de service worker (<= 30 días), el servicio Worker muestra el recurso almacenado en caché de inmediato.
  • Cuando un recurso almacenado en caché vence en la caché del service worker (más de 30 días), el servicio trabajador va a la red para obtener el recurso. El navegador no tiene una copia del recurso en a su caché HTTP, por lo que se pone del lado del servidor.

Ventajas y desventajas:

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

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

  • Cuando un recurso almacenado en caché es válido en la memoria caché del service worker (<= 1 día), el servicio trabajador va a la red para obtener el recurso. El navegador muestra el recurso de la interfaz HTTP de la caché si es que está allí. Si la red no funciona, el service worker muestra el recurso desde 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 servicio trabajador va a la red para recuperar el recurso. El navegador recupera los recursos del porque la versión almacenada en caché en su caché HTTP venció.

Ventajas y desventajas:

  • Ventaja: Cuando la red es inestable o está inactiva, el service worker muestra el almacenamiento en caché los recursos de inmediato.
  • Desventaja: El service worker requiere protección contra la memoria caché adicional para anular la caché HTTP y Marca la opción "Primero la red" solicitudes.

Conclusión

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

  • La lógica de almacenamiento en caché del service worker no necesita ser coherente con el vencimiento del almacenamiento en caché HTTP. lógica. Si es posible, usa una lógica de vencimiento más larga en el service worker para otorgarle más control.
  • El almacenamiento en caché HTTP sigue desempeñando un rol importante, pero no es confiable cuando la red se sea inestable o baja.
  • Revisa las estrategias de almacenamiento en caché para cada recurso a fin de asegurarte de que el almacenamiento en caché de tu service worker proporciona su valor, sin entrar en conflicto con la caché HTTP.

Más información