Caché HTTP y TTL: funcionamiento, estrategias e impacto en el SEO

La caché HTTP y el TTL (Time To Live) son dos conceptos fundamentales del rendimiento web. La caché permite almacenar temporalmente recursos (imágenes, CSS, JavaScript) cerca del usuario para evitar tener que volver a descargarlos en cada visita. El TTL define cuánto tiempo puede permanecer un recurso en esa caché antes de considerarse obsoleto. Bien configurados, estos mecanismos reducen considerablemente los tiempos de carga, alivian el servidor de origen y mejoran los Core Web Vitals, con un impacto directo en el SEO.

¿Qué es la caché HTTP?

La caché HTTP es un mecanismo que permite a distintos componentes de la cadena de entrega de una página web conservar una copia local de los recursos descargados. Cuando un navegador carga una página por primera vez, descarga cada recurso desde el servidor. Si esos recursos van acompañados de cabeceras HTTP que indican que pueden almacenarse en caché, el navegador (y/o la CDN) guarda una copia. En visitas posteriores, el recurso se sirve desde esa caché local en lugar de volver a descargarse del servidor, lo que es significativamente más rápido.

Existen varios niveles de caché en la cadena de entrega de un recurso web. La caché del navegador almacena los recursos directamente en el dispositivo del usuario, en su disco duro o en memoria. La caché CDN (también llamada caché de borde o edge cache) almacena los recursos en servidores de la red de distribución geográficamente cercanos a los usuarios. La caché de servidor (caché de proxy inverso, como Varnish o Nginx) almacena los recursos en el nivel de alojamiento, antes incluso de que lleguen a la red.

Las cabeceras Cache-Control: cómo definir el comportamiento de la caché

La cabecera HTTP Cache-Control es el principal mecanismo mediante el cual un servidor comunica sus instrucciones de almacenamiento en caché. Se envía con cada respuesta HTTP y puede contener varias directivas combinadas. Estas son las más importantes:

• max-age=N: el recurso puede almacenarse en caché durante N segundos. Ejemplo: max-age=31536000 = 1 año. La directiva más utilizada para recursos estáticos.
• s-maxage=N: igual que max-age, pero se aplica únicamente a cachés compartidas (CDN, proxies inversos), no a la caché del navegador. Permite políticas distintas para CDN y navegador.
• no-cache: el recurso puede almacenarse en caché, pero la caché debe verificar siempre con el servidor si sigue siendo válido antes de servirlo (mediante ETag o Last-Modified).
• no-store: el recurso nunca debe almacenarse en caché, en ningún lugar. Usar únicamente para contenido muy sensible (datos personales, transacciones).
• public: el recurso puede ser almacenado en caché por cualquier caché, incluidas las cachés compartidas de CDN.
• private: el recurso solo puede ser almacenado en caché por el navegador del usuario, no por cachés intermedias.
• immutable: indica que el recurso no cambiará nunca durante su tiempo de vida (max-age). El navegador no enviará una solicitud de validación aunque el TTL haya expirado.

Para las imágenes estáticas de una tienda de comercio electrónico, la directiva óptima suele ser: Cache-Control: public, max-age=31536000, immutable. Esta combinación indica que la imagen puede almacenarse en caché públicamente durante un año y que no cambiará. Si la imagen cambia (nueva foto de producto), la URL debe cambiar para saltarse la caché: una técnica conocida como "cache busting" mediante versionado de URL.

TTL (Time To Live): ¿cuánto tiempo conservar un recurso en caché?

El TTL (Time To Live) es la duración durante la que un recurso en caché se considera fresco (fresh) y puede servirse directamente sin consultar al servidor de origen. Se expresa en segundos en la cabecera max-age. Pasado este tiempo, el recurso se considera obsoleto (stale): puede seguir sirviéndose en ciertos casos, pero la caché debería idealmente revalidarlo.

La elección del TTL es un equilibrio entre dos objetivos contrapuestos: maximizar el uso de la caché (TTL largo = menos solicitudes al servidor) y garantizar que los usuarios reciban contenido actualizado (TTL corto = los cambios se propagan rápido). Para recursos que cambian poco, como las imágenes de producto, un TTL largo (1 año) es óptimo. Para recursos que cambian frecuentemente, como precios o existencias, es necesario un TTL corto o nulo.

• 1 año (31.536.000 segundos): imágenes de producto, CSS/JS versionados, fuentes web — recursos estables con versionado de URL
• 1 mes (2.592.000 segundos): imágenes de marca o de categoría que se actualizan ocasionalmente
• 1 hora a 1 día: contenido semidinámico, páginas de categoría, listados de productos
• 0 o no-store: páginas de carrito, páginas de pago, datos de usuario conectado — nunca almacenar en caché

Invalidación de caché: cómo gestionar los cambios de contenido

El almacenamiento en caché a largo plazo plantea una pregunta obvia: ¿qué ocurre cuando el contenido cambia? Si una imagen está en caché durante 1 año pero la actualizas tras 2 meses, los visitantes seguirán viendo la versión antigua durante 10 meses. Aquí es donde entran en juego las estrategias de invalidación de caché.

La estrategia más fiable es el versionado de URL (URL versioning o cache busting). El principio: la URL del recurso incluye un identificador único que cambia cada vez que el recurso cambia. Por ejemplo, /images/producto-zapato-v2.webp en lugar de /images/producto-zapato.webp. O bien mediante un parámetro: /images/producto.jpg?v=1705234567. Cuando la imagen cambia, la URL cambia, y la caché trata esa nueva URL como un recurso completamente nuevo, sin problemas de contenido obsoleto.

Otra estrategia es la API de purga de CDN: las CDN modernas exponen una API que permite invalidar inmediatamente URLs o grupos de URLs específicos en su caché. Cuando un comerciante modifica una imagen en su panel de administración, una llamada a la API de la CDN invalida la caché de esa imagen. Las visitas siguientes recuperan la nueva versión directamente desde el servidor de origen, que se vuelve a cachear.

Caché CDN vs caché del navegador: complementariedad y diferencias

La caché CDN y la caché del navegador son complementarias y sirven para objetivos distintos. La caché CDN beneficia a todos los visitantes, nuevos y recurrentes: una imagen almacenada en caché en el nodo CDN de Madrid se sirve rápidamente a cualquier visitante en España, haya visitado o no tu tienda previamente. La caché del navegador solo beneficia a los visitantes recurrentes en su propio dispositivo: si un usuario ya descargó la imagen en una visita anterior, su navegador la sirve desde el disco local sin ninguna solicitud de red.

En la práctica, ambos niveles de caché se complementan: la caché CDN reduce la latencia en la primera carga de una página (visitante nuevo o caché del navegador expirada), mientras que la caché del navegador elimina completamente la red en las visitas repetidas en el mismo dispositivo. Un recurso con max-age=31536000 solo requerirá una solicitud de red una vez al año por dispositivo, una ganancia de rendimiento muy significativa para los visitantes fieles.

ETag y Last-Modified: validación condicional de la caché

Incluso con un TTL expirado, el navegador no está obligado a volver a descargar un recurso desde cero. Puede enviar una solicitud condicional para verificar si el recurso ha cambiado: si no es así, el servidor responde con un código HTTP 304 (Not Modified) sin cuerpo de respuesta, ahorrando ancho de banda y confirmando al mismo tiempo la frescura del recurso en caché.

El ETag (Entity Tag) es un identificador único generado por el servidor para una versión específica de un recurso, normalmente un hash del contenido del archivo. Cuando el navegador realiza una solicitud condicional, envía el ETag de su versión en caché en la cabecera If-None-Match. Si el servidor tiene el mismo ETag (el recurso no ha cambiado), responde con 304; de lo contrario, envía la nueva versión con un nuevo ETag.

La cabecera Last-Modified funciona de forma similar: el servidor indica la fecha de la última modificación del recurso, y el navegador la envía en If-Modified-Since en las solicitudes condicionales. Estos mecanismos de validación permiten mantener la caché actualizada sin desperdiciar ancho de banda cuando el contenido no ha cambiado.

Cómo Lexiik gestiona la caché y la invalidación automáticamente

Lexiik implementa una estrategia de caché óptima para las imágenes de tiendas PrestaShop, resolviendo automáticamente el problema de invalidación que normalmente hace que el almacenamiento a largo plazo sea arriesgado. Cada imagen subida a Cloudflare R2 recibe las cabeceras Cache-Control: public, max-age=31536000, immutable, lo que significa un año de caché en todos los nodos de borde de Cloudflare y en los navegadores de los visitantes.

El problema de la invalidación es gestionado automáticamente por Lexiik mediante dos mecanismos. Primero, el versionado de URL: las imágenes servidas por Lexiik CDN utilizan identificadores en sus URLs que cambian automáticamente cuando la imagen se modifica en el panel de administración de PrestaShop. Segundo, las llamadas automáticas a la API de purga de Cloudflare: cuando una imagen cambia, Lexiik envía una solicitud de purga a Cloudflare para invalidar inmediatamente la caché CDN de esa imagen específica, sin afectar a las demás. Los visitantes reciben la nueva imagen en su próxima visita, sin ver nunca una versión obsoleta.

Por qué una caché a largo plazo mejora el SEO

Un TTL de un año en las imágenes de producto mejora el SEO mediante varios mecanismos directos e indirectos. Directamente, las imágenes cargadas desde la caché (CDN o navegador) aparecen en decenas o cientos de milisegundos, frente a varios segundos en una descarga de red completa. Esto mejora el LCP, la métrica de Core Web Vitals más relacionada con las imágenes, y puede llevar una página de una puntuación «Mala» a «Buena» según los umbrales de Google.

Indirectamente, una caché eficaz reduce el número de solicitudes HTTP enviadas a tu servidor de origen. Menos carga en el servidor = mejor TTFB (Time To First Byte) para el contenido HTML dinámico que genera tu PrestaShop. Google recomienda un TTFB inferior a 200 ms; un servidor saturado de solicitudes de imágenes puede tener un TTFB degradado que afecte a todas las métricas de rendimiento.

Por último, para los visitantes recurrentes, que suelen ser los más propensos a convertir, una caché del navegador bien configurada crea una experiencia de navegación casi instantánea. Las páginas de producto parecen cargarse al instante, con las imágenes ya en memoria. Esto suaviza el proceso de compra y reduce los abandonos, con un impacto positivo en las métricas de comportamiento que Google puede tener en cuenta.

• LCP mejorado: imágenes cargadas desde la caché local o CDN en milisegundos
• TTFB mejorado: menos solicitudes al servidor de origen = menor carga del servidor = HTML entregado más rápido
• Mejor puntuación PageSpeed: Google Lighthouse penaliza la ausencia de una política de caché a largo plazo
• Ahorro de ancho de banda: menos datos transferidos = menores costes y mejor rendimiento en móvil
• Mejor experiencia para visitantes recurrentes: navegación casi instantánea para clientes habituales