El almacenamiento en caché en tiempo de ejecución se refiere a agregar respuestas de forma gradual a una caché “sobre la marcha”. Si bien el almacenamiento en caché del entorno de ejecución no ayuda con la confiabilidad de la solicitud actual, puede ayudar a que las solicitudes futuras para la misma URL sean más confiables.
La caché HTTP del navegador es un ejemplo de almacenamiento en caché en tiempo de ejecución; solo se completa después de una solicitud para una URL determinada. Sin embargo, los service workers te permiten implementar almacenamiento en caché en el entorno de ejecución que va más allá de lo que la caché HTTP por sí sola puede ofrecer.
Ser estratégico
A diferencia del almacenamiento previo en caché (que siempre intenta entregar un conjunto de archivos predefinidos desde una caché), el almacenamiento en caché en el entorno de ejecución puede combinar el acceso a la red y a la caché de varias maneras. Cada combinación se conoce generalmente como una estrategia de almacenamiento en caché. Entre las estrategias de almacenamiento en caché de claves, se incluyen las siguientes:
- Prioridad de la red
- Priorizar la caché
- Revalidación inactiva
Prioridad de la red
En este enfoque, el service worker primero intenta recuperar una respuesta de la red. Si la solicitud de red se realiza correctamente, ¡genial! La respuesta se devuelve a la app web, y se almacena una copia de la respuesta con la API de Cache Storage, ya sea creando una entrada nueva o actualizando una entrada anterior para la misma URL.
Si la solicitud de red falla por completo o tarda demasiado en mostrar una respuesta, se mostrará la respuesta más reciente de la caché.
Priorizar la caché
En efecto, una estrategia que prioriza la caché es lo opuesto a priorizar la red. En este enfoque, cuando el service worker intercepta una solicitud, primero usa la API de Cache Storage para ver si hay disponible una respuesta almacenada en caché. Si la hay, esa respuesta se devuelve a la app web.
Sin embargo, si hay un error de caché, el service worker irá a la red y tratará de recuperar una respuesta allí. Si se asume que la solicitud de red se realiza correctamente, se muestra en la app web y se guarda una copia en la caché. Esta copia almacenada en caché se usará para omitir la red la próxima vez que se realice una solicitud para las mismas URLs.
Revalidación inactiva
La revalidación temporal es algo híbrido. Cuando la uses, el service worker buscará de inmediato una respuesta almacenada en caché y, si la encuentra, la pasará a la app web.
Mientras tanto, independientemente de si hubo una coincidencia de caché, tu service worker también envía una solicitud de red para obtener una respuesta “nueva”. Esta respuesta se usa para actualizar cualquier respuesta almacenada en caché con anterioridad. Si la verificación de caché inicial fue un error, también se enviará una copia de la respuesta de red a tu app web.
¿Por qué deberías usar Workbox?
Estas estrategias de almacenamiento en caché representan recetas que normalmente deberías volver a escribir en tu propio service worker una y otra vez. En lugar de recurrir a eso, Workbox las ofrece empaquetadas como parte de su biblioteca de estrategias, listas para que las uses en tu service worker.
Workbox también es compatible con el control de versiones, lo que te permite expirar automáticamente las entradas almacenadas en caché o notificar a tu app web cuando se produzcan actualizaciones en una entrada almacenada en caché.
¿Cuáles de tus elementos se deberían almacenar en caché? ¿Con qué estrategias?
El almacenamiento en caché del entorno de ejecución se puede considerar como un complemento del almacenamiento en caché previo. Si todos tus elementos ya se almacenaron en caché previamente, no necesitas hacer nada más durante el tiempo de ejecución. Sin embargo, lo más probable es que, para cualquier app web relativamente compleja, no tengas que almacenar previamente en caché todo.
Los archivos multimedia más grandes, los elementos que se entregan desde un host de terceros, como una CDN, o las respuestas de la API, son solo algunos ejemplos de los tipos de elementos que no se pueden almacenar previamente en caché de manera efectiva. Usa el panel Network de Herramientas para desarrolladores a fin de identificar las solicitudes que corresponden a esta categoría y, para cada una de ellas, piensa en qué compensación de actualización frente a confiabilidad es adecuada.
Usa la función de inactividad durante la revalidación para priorizar la confiabilidad sobre la actualización
Dado que una estrategia de inactividad durante la revalidación muestra una respuesta almacenada en caché casi de inmediato, después de que la caché se propague mediante la primera solicitud, verás un rendimiento confiablemente rápido cuando uses esta estrategia. Esto implica la compensación de obtener datos de respuesta que podrían estar inactivos en comparación con los que se habrían recuperado de la red. El uso de esta estrategia funciona mejor con recursos como las imágenes de perfil del usuario o las respuestas iniciales de la API que se usan para propagar una vista, cuando sabes que mostrar algo de inmediato es clave, incluso si es un valor anterior.
Usa la prioridad en la red para priorizar la actualización sobre la confiabilidad
En algún sentido, usar una estrategia centrada en la red implica admitir la derrota de tu batalla contra la red. Se le da prioridad, pero eso trae consigo incertidumbre sobre la confiabilidad. Para ciertos tipos de elementos, es preferible ver una respuesta nueva en lugar de recuperar la información obsoleta. Es posible que prefieras la actualización cuando realices una solicitud a la API para el texto de un artículo que se actualiza con frecuencia, por ejemplo.
Si usas una estrategia centrada en la red dentro de un service worker, en lugar de ir directamente a la red, tienes el beneficio de poder recurrir a algo, incluso si es una respuesta potencialmente inactiva. No podrás ser rápido, pero al menos serás confiable sin conexión.
Usa el almacenamiento en caché para las URLs con versiones
En una estrategia en la que se prioriza la caché, una vez que una entrada se almacena en caché, esta nunca se actualiza. Por ese motivo, asegúrate de usarlo solo con elementos que sepas que es poco probable que cambien. En particular, funciona mejor para las URLs que contienen información sobre el control de versiones, el mismo tipo de URL que también debe entregarse con un encabezado de respuesta Cache-Control: max-age=31536000.