Evita solicitudes de red innecesarias con la caché HTTP

Recuperar recursos a través de la red es lento y costoso:

• Las respuestas grandes requieren muchos viajes de ida y vuelta entre el navegador y el servidor.
• Tu página no se cargará hasta que se hayan descargado por completo todos sus recursos críticos.
• Si una persona accede a tu sitio con un plan de datos móviles limitado, cada solicitud de red innecesaria es un desperdicio de su dinero.

¿Cómo puedes evitar las solicitudes de red innecesarias? La caché HTTP del navegador es tu primera línea de defensa. No es necesariamente el enfoque más potente o flexible, y tienes un control limitado sobre la vida útil de las respuestas almacenadas en caché, pero es eficaz, es compatible con todos los navegadores y no requiere mucho trabajo.

En esta guía, se muestran los conceptos básicos de una implementación eficaz del almacenamiento en caché de HTTP.

Compatibilidad del navegador

En realidad, no hay una sola API llamada caché HTTP. Es el nombre general de una colección de APIs de la plataforma web. Esas APIs son compatibles con todos los navegadores:

Cache-Control

ETag

Last-Modified

Cómo funciona la caché HTTP

Todas las solicitudes HTTP que realiza el navegador se enrutan primero a la caché del navegador para verificar si hay una respuesta almacenada en caché válida que se pueda usar para completar la solicitud. Si hay una coincidencia, la respuesta se lee desde la caché, lo que elimina la latencia de la red y los costos de datos que genera la transferencia.

El comportamiento de la caché HTTP se controla mediante una combinación de encabezados de la solicitud y encabezados de respuesta. En un escenario ideal, tendrás control sobre el código de tu aplicación web (que determinará los encabezados de la solicitud) y la configuración de tu servidor web (que determinará los encabezados de respuesta).

Consulta el artículo Almacenamiento en caché de HTTP de MDN para obtener una descripción general conceptual más detallada.

Encabezados de la solicitud: Se recomienda usar los valores predeterminados (por lo general)

Hay una serie de encabezados importantes que se deben incluir en las solicitudes salientes de tu app web, pero el navegador casi siempre se encarga de configurarlos en tu nombre cuando realiza solicitudes. Los encabezados de la solicitud que afectan la verificación de la actualización, como If-None-Match y If-Modified-Since, aparecen según la comprensión del navegador de los valores actuales en la caché HTTP.

Esto es una buena noticia, ya que significa que puedes seguir incluyendo etiquetas como <img src="my-image.png"> en tu HTML, y el navegador se encargará automáticamente del almacenamiento en caché HTTP por ti, sin esfuerzo adicional.

Encabezados de respuesta: Configura tu servidor web

La parte más importante de la configuración del almacenamiento en caché de HTTP son los encabezados que tu servidor web agrega a cada respuesta saliente. Los siguientes encabezados influyen en el comportamiento eficaz del almacenamiento en caché:

• Cache-Control: El servidor puede devolver una directiva Cache-Control para especificar cómo y durante cuánto tiempo el navegador y otras cachés intermedias deben almacenar en caché la respuesta individual.
• ETag: Cuando el navegador encuentra una respuesta almacenada en caché que venció, puede enviar un token pequeño (por lo general, un hash del contenido del archivo) al servidor para verificar si el archivo cambió. Si el servidor devuelve el mismo token, significa que el archivo es el mismo y no es necesario volver a descargarlo.
• Last-Modified: Este encabezado tiene el mismo propósito que ETag, pero usa una estrategia basada en el tiempo para determinar si un recurso cambió, en lugar de la estrategia basada en el contenido de ETag.

Algunos servidores web tienen compatibilidad integrada para configurar esos encabezados de forma predeterminada, mientras que otros los omiten por completo, a menos que los configures de forma explícita. Los detalles específicos de cómo configurar los encabezados varían mucho según el servidor web que uses. Consulta la documentación de tu servidor para obtener los detalles más precisos.

Para ahorrarte la búsqueda, aquí tienes instrucciones para configurar algunos servidores web populares:

• Express
• Apache
• nginx
• Firebase Hosting
• Netlify

Omitir el encabezado de respuesta Cache-Control no inhabilita el almacenamiento en caché de HTTP. En cambio, los navegadores adivinan de forma eficaz qué tipo de comportamiento de almacenamiento en caché tiene más sentido para un tipo de contenido determinado. Es probable que quieras tener más control del que ofrece, así que tómate el tiempo para configurar tus encabezados de respuesta.

¿Qué valores de encabezado de respuesta deberías usar?

Existen dos situaciones importantes que debes tener en cuenta cuando configures los encabezados de respuesta de tu servidor web.

Almacenamiento en caché de larga duración para URLs con versiones

Cuando respondas a solicitudes de URLs que contengan "huella digital" o información de versiones, y cuyo contenido nunca deba cambiar, agrega Cache-Control: max-age=31536000 a tus respuestas.

Establecer este valor le indica al navegador que, cuando necesite cargar la misma URL en cualquier momento durante el próximo año (31,536,000 segundos, el valor máximo admitido), puede usar de inmediato el valor en la caché HTTP, sin tener que realizar una solicitud de red a tu servidor web. ¡Eso es genial! Obtuviste de inmediato la confiabilidad y la velocidad que se obtienen al evitar la red.

Las herramientas de compilación, como webpack, pueden automatizar el proceso de asignación de huellas digitales de hash a las URLs de tus recursos.

Revalidación del servidor para URLs sin versión

Lamentablemente, no todas las URLs que cargas tienen versiones. Tal vez no puedas incluir un paso de compilación antes de implementar tu app web, por lo que no puedes agregar hashes a las URLs de tus recursos. Además, todas las aplicaciones web necesitan archivos HTML, que (casi) nunca incluirán información de control de versiones, ya que nadie se molestará en usar tu app web si necesita recordar que la URL que debe visitar es https://example.com/index.34def12.html. ¿Qué puedes hacer con esas URLs?

Esta es una situación en la que debes admitir la derrota. El almacenamiento en caché de HTTP por sí solo no es lo suficientemente potente como para evitar la red por completo. (No te preocupes, pronto aprenderás sobre los service workers, que proporcionarán la asistencia que necesitamos para que la batalla vuelva a estar a tu favor). Sin embargo, puedes seguir algunos pasos para asegurarte de que las solicitudes de red sean lo más rápidas y eficientes posible.

Los siguientes valores de Cache-Control pueden ayudarte a ajustar dónde y cómo se almacenan en caché las URLs sin versión:

• no-cache. Esto le indica al navegador que debe volver a validar con el servidor cada vez antes de usar una versión almacenada en caché de la URL.
• no-store: Indica al navegador y a otras cachés intermedias (como las CDN) que nunca almacenen ninguna versión del archivo.
• private: Los navegadores pueden almacenar en caché el archivo, pero las cachés intermedias no.
• public: Cualquier caché puede almacenar la respuesta.

Consulta el Apéndice: Diagrama de flujo de Cache-Control para visualizar el proceso de decisión de qué valores de Cache-Control usar. Cache-Control también puede aceptar una lista de directivas separadas por comas. Consulta el Apéndice: Ejemplos de Cache-Control.

Configurar ETag o Last-Modified también puede ayudar. Como se mencionó en Encabezados de respuesta, ETag y Last-Modified tienen el mismo propósito: determinar si el navegador necesita volver a descargar un archivo almacenado en caché que venció. Te recomendamos que uses ETag porque es más preciso.

Configurar ETag o Last-Modified hace que la solicitud de revalidación sea mucho más eficiente, ya que permite que se activen los encabezados de la solicitud If-Modified-Since o If-None-Match que se mencionan en Encabezados de la solicitud.

Cuando un servidor web configurado correctamente ve esos encabezados de solicitud entrantes, puede confirmar si la versión del recurso que el navegador ya tiene en su caché HTTP coincide con la versión más reciente en el servidor web. Si hay una coincidencia, el servidor puede responder con una respuesta HTTP 304 Not Modified, que equivale a "Oye, sigue usando lo que ya tienes". Hay muy pocos datos para transferir cuando se envía este tipo de respuesta, por lo que suele ser mucho más rápido que tener que enviar una copia del recurso real que se solicita.

Resumen

La caché HTTP es una forma eficaz de mejorar el rendimiento de carga, ya que reduce las solicitudes de red innecesarias. Es compatible con todos los navegadores y no requiere mucho trabajo para configurarlo.

Las siguientes opciones de configuración de Cache-Control son un buen punto de partida:

• Cache-Control: no-cache para los recursos que se deben volver a validar con el servidor antes de cada uso.
• Cache-Control: no-store para los recursos que nunca se deben almacenar en caché
• Cache-Control: max-age=31536000 para los recursos con versión.

Además, el encabezado ETag o Last-Modified puede ayudarte a volver a validar los recursos de caché vencidos de manera más eficiente.

Más información

Si quieres ir más allá de los conceptos básicos del uso del encabezado Cache-Control, consulta la guía de Jake Archibald sobre las prácticas recomendadas para el almacenamiento en caché y los problemas de max-age.

Consulta Love your cache para obtener orientación sobre cómo optimizar el uso de la caché para los visitantes recurrentes.

Apéndice: Más sugerencias

Si tienes más tiempo, aquí tienes más formas de optimizar el uso de la caché HTTP:

• Usa URLs coherentes. Si publicas el mismo contenido en diferentes URLs, ese contenido se recuperará y almacenará varias veces.
• Minimizar la deserción Si una parte de un recurso (como un archivo CSS) se actualiza con frecuencia, mientras que el resto del archivo no (como el código de la biblioteca), considera dividir el código que se actualiza con frecuencia en un archivo separado y usar una estrategia de almacenamiento en caché de corta duración para el código que se actualiza con frecuencia y una estrategia de almacenamiento en caché de larga duración para el código que no cambia con frecuencia.
• Consulta la nueva directiva stale-while-revalidate si se acepta cierto grado de obsolescencia en tu política de Cache-Control.

Apéndice: Diagrama de flujo de Cache-Control

Apéndice: Ejemplos de Cache-Control