Ventajas y desventajas de usar una lógica de vencimiento coherente o diferente en las capas de caché de service worker y caché HTTP.
Si bien los service workers y las PWA 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. En este artículo, se aborda el panorama general del almacenamiento en caché del navegador, incluido 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 del almacenamiento en caché de service worker en comparación con las estrategias de almacenamiento en caché HTTP normales
Descripción general del flujo de almacenamiento en caché
En un nivel superior, un navegador sigue el siguiente orden de almacenamiento en caché cuando solicita un recurso:
- Caché de service worker: El service worker verifica si el recurso está en su caché y decide si mostrar el recurso en función de 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 interceptar las solicitudes de red para que se publiquen desde la caché del service worker en lugar de la red.
- Caché HTTP (también conocida como caché del navegador): Si el recurso se encuentra en la caché HTTP y aún no venció, el navegador lo usa automáticamente.
- Servidor: Si no se encuentra nada en la caché de service worker ni en la caché HTTP, el navegador va a la red para solicitar el recurso. Si el recurso no está almacenado en caché en una CDN, la solicitud debe volver al servidor de origen.
Capas de almacenamiento en caché
Almacenamiento en caché de service worker
Un service worker 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é de service worker y la caché HTTP tienen el mismo propósito general, pero la caché de 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 el almacenamiento en caché.
Control de la caché de service worker
Un service worker intercepta las solicitudes HTTP con objetos de escucha de
eventos (por lo general, el evento fetch). En este fragmento de código, se muestra la lógica de una estrategia de almacenamiento en caché de
Cache-First.
Se recomienda usar Workbox para evitar reinventar la rueda. Por ejemplo, puedes registrar rutas de URL de recursos con una sola línea de código de expresión regular.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Estrategias y casos de uso del almacenamiento en caché de service worker
En la siguiente tabla, se describen las estrategias comunes de almacenamiento en caché de service worker y cuándo es útil cada estrategia.
| Estrategias | Fundamento de la actualidad | Casos de uso |
|---|---|---|
| Solo red | El contenido debe estar actualizado en todo momento. |
|
| Red que recurre a la caché | Es preferible publicar el contenido nuevo. Sin embargo, si la red falla o es inestable, es aceptable publicar contenido un poco antiguo. |
|
| Obsoleto mientras se vuelve a validar | Está bien publicar contenido almacenado en caché de inmediato, pero se debe usar contenido almacenado en caché actualizado en el futuro. |
|
| Caché primero, recurre a la red | El contenido no es fundamental y se puede publicar desde la caché para mejorar el rendimiento, pero el service worker debe verificar las actualizaciones de vez en cuando. |
|
| Solo caché | El contenido rara vez cambia. |
|
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é de service worker también proporciona lo siguiente:
- Más memoria y espacio de almacenamiento para tu origen: El navegador asigna recursos de caché HTTP pororigen. 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 service worker, es mucho más probable que el 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: el recurso está almacenado en caché o no. Con el almacenamiento en caché de service worker, puedes mitigar pequeños "problemas" con mucha más facilidad (con la estrategia "obsoleto mientras se vuelve a validar"), ofrecer una experiencia sin conexión completa (con la estrategia "Solo caché") o incluso algo intermedio, como UIs personalizadas con partes de la página que provienen de la caché de service worker y algunas partes excluidas (con la estrategia "Establecer controlador de captura") cuando corresponda.
Almacenamiento en caché HTTP
La primera vez que un navegador carga una página web y los recursos relacionados, almacena estos recursos en su caché HTTP. Por lo general, los navegadores habilitan automáticamente la caché HTTP, a menos que el usuario final la haya inhabilitado de forma explícita.
Usar el almacenamiento en caché HTTP significa 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 navegador para un recurso, el servidor usa encabezados de respuesta HTTP para indicarle a un navegador cuánto tiempo debe almacenar en caché el recurso. Consulta Encabezados de respuesta: configura tu servidor web para obtener más información.
Estrategias y casos de uso del almacenamiento en caché HTTP
El almacenamiento en caché HTTP es mucho más simple que el almacenamiento en caché de service worker, ya que solo se ocupa de la lógica de vencimiento de recursos basada en el tiempo (TTL). Consulta ¿Qué valores de encabezado de respuesta debes usar? y Evita solicitudes de red innecesarias con la caché HTTP (resumen) para obtener más información sobre las estrategias de almacenamiento en caché HTTP.
Diseña tu lógica de vencimiento de caché
En esta sección, se explican las ventajas y desventajas de usar una lógica de vencimiento coherente en las capas de caché de service worker y caché HTTP, así como las ventajas y desventajas de la lógica de vencimiento separada en estas capas.
Lógica de vencimiento coherente para todas las capas de caché
Para demostrar las ventajas y desventajas, analizaremos 3 situaciones: a largo, mediano y corto plazo.
| Scenarios | Almacenamiento en caché a largo plazo | Almacenamiento en caché a mediano plazo | Almacenamiento en caché a corto plazo |
|---|---|---|---|
| Estrategia de almacenamiento en caché de service worker | Caché, recurre a la red | Obsoleto mientras se vuelve a validar | Red que recurre a la caché |
| TTL de la caché de service worker | 30 días | 1 día | 10 min |
| Max-age de la caché HTTP | 30 días | 1 día | 10 min |
Situación: Almacenamiento en caché a largo plazo (Caché, recurre a la red)
- Cuando un recurso almacenado en caché es válido (<= 30 días), el service worker muestra el recurso almacenado en caché de inmediato sin ir a la red.
- Cuando un recurso almacenado en caché vence (> 30 días), el service worker va a la red para recuperar el recurso. El navegador no tiene una copia del recurso en su caché HTTP, por lo que va al servidor para obtener el recurso.
Desventaja: En esta situación, el almacenamiento en 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 (Obsoleto mientras se vuelve a validar)
- 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 la muestra al service worker.
- Cuando un recurso almacenado en caché vence (> 1 día), 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 obtener el recurso.
Desventaja: El service worker requiere una invalidación de caché adicional para anular la caché HTTP y aprovechar al máximo el paso de "volver a validar".
Situación: Almacenamiento en caché a corto plazo (Red que recurre a la caché)
- Cuando un recurso almacenado en caché es válido (<= 10 min), el service worker va a la red para recuperar el recurso. El navegador tiene una copia del recurso en su caché HTTP, por lo que la muestra al service worker sin ir al 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 obtener el recurso.
Desventaja: Al igual que en la situación de almacenamiento en caché a mediano plazo, el service worker requiere una lógica de invalidación de caché adicional para anular la caché HTTP y recuperar el recurso más reciente del servidor.
Service worker en todas las situaciones
En todas las situaciones, la caché de 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 está inactiva.
Lógica de vencimiento de caché diferente en la caché de service worker y las capas HTTP
Para demostrar las ventajas y desventajas, volveremos a analizar situaciones a largo, mediano y corto plazo.
| Scenarios | Almacenamiento en caché a largo plazo | Almacenamiento en caché a mediano plazo | Almacenamiento en caché a corto plazo |
|---|---|---|---|
| Estrategia de almacenamiento en caché de service worker | Caché, recurre a la red | Obsoleto mientras se vuelve a validar | Red que recurre a la caché |
| TTL de la caché de service worker | 90 días | 30 días | 1 día |
| Max-age de la caché HTTP | 30 días | 1 día | 10 min |
Situación: Almacenamiento en caché a largo plazo (Caché, recurre 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é de service worker (> 90 días), el service worker va a la red para recuperar el recurso. El navegador no tiene una copia del recurso en su caché HTTP, por lo que va 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 tiene un control más detallado de cuándo usar su caché y cuándo solicitar versiones nuevas de los recursos.
- Desventaja: Se requiere una estrategia de almacenamiento en caché de service worker bien definida.
Situación: Almacenamiento en caché a mediano plazo (Obsoleto mientras se vuelve a validar)
- Cuando un recurso almacenado en caché es válido en la caché de service worker (<= 30 días), el service worker muestra el recurso almacenado en caché de inmediato.
- Cuando un recurso almacenado en caché vence en la caché de 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 va 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 garantizar que la próxima solicitud de una URL determinada use 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é de service worker bien definida.
Situación: Almacenamiento en caché a corto plazo (Red que recurre a la caché)
- Cuando un recurso almacenado en caché es válido en la caché de 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 está inactiva, el service worker muestra el recurso de la caché de service worker.
- Cuando un recurso almacenado en caché vence en la caché de service worker (> 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 venció.
Ventajas y desventajas:
- Ventaja: Cuando la red es inestable o está inactiva, el service worker muestra los recursos almacenados en caché de inmediato.
- Desventaja: El service worker requiere una invalidación de caché adicional para anular la caché HTTP y realizar solicitudes "Network first".
Conclusión
Dada la complejidad de la combinación de situaciones de almacenamiento en caché, no es posible diseñar una regla que abarque todos los casos. Sin embargo, según los resultados 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é de service worker no necesita 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 service worker para otorgarle más control.
- El almacenamiento en caché HTTP sigue desempeñando un papel importante, pero no es confiable cuando la red es inestable o está inactiva.
- Vuelve a revisar tus estrategias de almacenamiento en caché para cada recurso para asegurarte de que tu estrategia de almacenamiento en caché de service worker proporcione su valor sin entrar en conflicto con la caché HTTP.