Cache-Control en imágenes de tu web de empresa: cabeceras HTTP, max-age, immutable y errores que sirven contenido obsoleto

Las imágenes de tu web de empresa suelen ser los archivos más pesados y los que más veces se vuelven a descargar en visitas repetidas. Sin una política clara de Cache-Control, el navegador o el CDN no saben cuánto tiempo pueden guardar cada JPG o WebP. Resultado: más latencia, más ancho de banda y, a veces, fotos antiguas que no se actualizan cuando cambias el diseño.

En esta guía verás qué cabeceras usar en imágenes estáticas, cómo combinar max-age e immutable, qué papel juega el CDN y qué errores conviene evitar en webs corporativas.

Qué es Cache-Control en imágenes estáticas

Cache-Control es una cabecera HTTP que indica al navegador, proxies y CDN si pueden almacenar una respuesta y durante cuánto tiempo. En imágenes de /storage, /img o assets con hash en el nombre, el objetivo habitual es cachear agresivamente porque el contenido no cambia mientras el nombre del archivo sea el mismo.

No sustituye optimizar peso ni elegir formatos modernos, pero multiplica el efecto de esas mejoras en usuarios que vuelven a tu site o navegan varias páginas en la misma sesión.

Por qué importa en una web de empresa

En sitios B2B y corporativos se repiten muchos assets: logo, iconos, fotos de servicios, capturas de casos de éxito. Sin caché:

• Cada página vuelve a pedir las mismas miniaturas del blog o del equipo.
• El servidor trabaja de más en tráfico que podría servirse desde el edge con un CDN.
• Lighthouse y usuarios móviles perciben una web más lenta en la segunda visita.

Una política coherente también reduce coste de hosting y mejora la experiencia en mercados con conexiones limitadas.

Cabeceras recomendadas para imágenes con nombre versionado

Cuando el archivo incluye hash o versión (hero-v3.a4f2c9.webp), un patrón seguro es:

Cache-Control: public, max-age=31536000, immutable

public permite que CDN y navegador almacenen la respuesta. max-age=31536000 (un año) es habitual para assets inmutables. immutable avisa al cliente de que no revalide en la misma sesión si la URL no cambia — útil en scroll largo con muchas imágenes.

Si regeneras imágenes con el mismo nombre (sin hash), evita immutable y usa max-age moderado más revalidación (must-revalidate) o cambia el nombre al publicar.

Imágenes del CMS sin hash: equilibrio entre frescura y velocidad

Fotos de blog, equipo o producto que sustituyes desde el CMS suelen mantener la misma URL. Ahí conviene:

• Cache-Control: public, max-age=86400 (24 h) o max-age=604800 (7 días) según frecuencia de cambios.
• Purgar caché del CDN al actualizar la imagen, si usas uno.
• Combinar con preload solo en el hero LCP, no en toda la galería.

Documenta en el proceso editorial quién purga CDN y cuándo, para no mezclar fotos nuevas con caché antigua.

ETag, Last-Modified y CDN

Además de Cache-Control, el servidor puede enviar ETag o Last-Modified. En assets versionados suelen sobrar si ya cacheas un año con URL única. En imágenes de CMS, un ETag correcto permite 304 Not Modified y ahorra bytes sin servir un JPG completo.

En CDN, alinea la TTL del edge con la cabecera de origen y evita reglas contradictorias (origen dice 1 año, CDN 1 hora).

Errores frecuentes

• Cache-Control: no-store en todo el sitio. A veces se copia de páginas dinámicas y se aplica a estáticos; las imágenes nunca se cachean.
• max-age enorme sin versionado. Cambias la foto del equipo pero los visitantes siguen viendo la anterior una semana.
• Olvidar el CDN al desplegar. Origen correcto, edge obsoleto.
• Confundir caché de HTML con caché de imagen. Las páginas PHP/Laravel suelen ser no-cache; los JPG en /storage deben ser cacheables.
• Lazy loading mal aplicado en LCP. La caché no arregla un hero mal priorizado; repasa lazy loading.

Checklist rápido

1. ¿Imágenes con hash o query de versión tienen max-age largo e immutable?
2. ¿Fotos del CMS tienen TTL acorde al ritmo editorial y purga de CDN?
3. ¿Apache/Nginx sirven cabeceras distintas para /storage y HTML?
4. ¿Has comprobado en DevTools → Network que una segunda visita usa disk cache o 304?
5. ¿Tras un cambio de marca, actualizaste nombres de archivo o invalidaste caché?

Conclusión

Cache-Control bien configurado convierte imágenes ya optimizadas en assets que casi no penalizan visitas repetidas. Es un ajuste de infraestructura pequeño con impacto directo en velocidad percibida y costes.

Si quieres revisar cabeceras, CDN y flujo de publicación de imágenes en tu web de empresa, en aatsoft podemos auditar origen, edge y CMS contigo.