Guía completa de estrategias de caché de imágenes - Cache-Control, ETag y configuración CDN
Fundamentos del caché de imágenes web - Roles del caché del navegador y CDN
Las imágenes suelen representar entre el 50-70% del volumen total de transferencia de una página web. Una estrategia de caché efectiva elimina descargas redundantes, mejorando significativamente la velocidad de carga y la experiencia del usuario.
Jerarquía de caché: caché en memoria del navegador (más rápido, válido durante la sesión) → caché en disco del navegador (rápido, persistente entre sesiones) → caché en el borde CDN (reduce la carga del servidor origen) → servidor origen. Cada capa puede configurarse de forma independiente.
El equilibrio fundamental del caché: cuanto mayor sea el tiempo de caché, mejor será el rendimiento (menos solicitudes), pero mayor será el retraso en la actualización del contenido. Las imágenes rara vez se modifican una vez publicadas, por lo que son ideales para cachés prolongados. La clave es diseñar un mecanismo que invalide el caché de forma fiable cuando sea necesario actualizar.
Estrategia de recursos inmutables: para imágenes con hash de contenido en el nombre de archivo (como hero-a3f2b1.jpg), se puede establecer un tiempo de caché extremadamente largo (1 año), ya que cuando el contenido cambia, el nombre del archivo también cambia y el navegador solicita la nueva URL. Este es el patrón de caché más eficiente.
Diseño de cabeceras Cache-Control - Combinación de directivas
Cache-Control es la cabecera de respuesta principal para controlar el comportamiento del caché HTTP.
Directivas comunes: max-age=31536000 (caché por 1 año), no-cache (debe validar antes de usar), no-store (no almacenar en caché), public (CDN puede almacenar), private (solo el navegador puede almacenar), immutable (el contenido nunca cambia, no necesita validación).
Combinaciones recomendadas:
- Imágenes estáticas con hash:
Cache-Control: public, max-age=31536000, immutable - Imágenes que pueden actualizarse:
Cache-Control: public, max-age=86400, must-revalidate - Imágenes dinámicas como avatares:
Cache-Control: public, max-age=3600, must-revalidate - Imágenes sensibles:
Cache-Control: private, no-store
La directiva immutable indica al navegador que no necesita revalidar ni siquiera con una recarga forzada, eliminando solicitudes condicionales innecesarias. Chrome y Firefox soportan esta directiva.
stale-while-revalidate=86400 permite seguir usando el caché expirado mientras se revalida en segundo plano, sin que el usuario perciba retraso.
ETag y solicitudes condicionales - Revalidación eficiente del caché
Cuando el caché expira, las solicitudes condicionales permiten al servidor confirmar si el contenido realmente ha cambiado, evitando retransmitir imágenes no modificadas.
Flujo de trabajo de ETag: el servidor incluye ETag: "abc123" en la respuesta (normalmente un hash del contenido). Cuando el caché del navegador expira, envía una solicitud condicional con If-None-Match: "abc123". Si el contenido no ha cambiado, el servidor responde con 304 Not Modified (sin cuerpo de respuesta) y el navegador continúa usando el caché.
Last-Modified / If-Modified-Since: alternativa basada en marcas de tiempo. Tiene precisión de segundos, menos precisa que ETag, pero más simple de implementar. Ambos pueden usarse simultáneamente, con ETag teniendo mayor prioridad.
ETag fuerte vs débil: ETag fuerte ("abc123") indica identidad a nivel de bytes; ETag débil (W/"abc123") indica equivalencia semántica (permite diferencias menores como cambios en espacios). Las imágenes normalmente usan ETag fuerte.
Impacto en rendimiento: aunque las respuestas 304 no transmiten datos de imagen, siguen requiriendo un viaje de red. Para imágenes con hash en el nombre de archivo, usar max-age largo + immutable para evitar completamente las solicitudes condicionales es la mejor opción. ETag es adecuado para escenarios donde el nombre de archivo no cambia pero el contenido puede actualizarse.
Diseño de caché CDN - Configuración de CloudFront y Cloudflare
Los CDN almacenan imágenes en nodos de borde globales, reduciendo la carga del servidor origen y la latencia del usuario.
Configuración de CloudFront: controla el comportamiento del caché CDN mediante políticas de caché (Cache Policy). Se recomienda crear una política dedicada para imágenes: TTL de 86400-31536000 segundos, habilitar compresión Gzip/Brotli (efectiva para SVG), negociación de contenido basada en la cabecera Accept (selección automática WebP/AVIF).
Configuración de Cloudflare: Page Rules o Cache Rules establecen el nivel de caché para rutas de imágenes. Browser Cache TTL controla el tiempo de caché del navegador. La función Polish optimiza automáticamente el formato y calidad de las imágenes.
Diseño de claves de caché: el CDN distingue versiones según la clave de caché. La clave predeterminada es la URL completa. Si se usa negociación de contenido (misma URL devuelve diferentes formatos), es necesario incluir la cabecera Accept en la clave de caché; de lo contrario, todos los usuarios recibirán el primer formato almacenado.
Protección del origen: configurar Origin Shield (CloudFront) o Tiered Caching (Cloudflare) para reducir solicitudes al origen. Los fallos de caché de múltiples nodos de borde se consolidan en una única solicitud al origen.
Estrategias de invalidación de caché - Asegurar que las actualizaciones se reflejen oportunamente
La invalidación de caché es uno de los problemas más difíciles en los sistemas de caché. Es necesario encontrar un equilibrio entre la eficiencia del caché y la frescura del contenido.
Hash en nombre de archivo (recomendado): incluir un hash del contenido en el nombre del archivo (como logo-v2f3a1b.png). Cuando el contenido cambia, el hash cambia, la URL cambia y el navegador solicita automáticamente el nuevo archivo. No es necesario invalidar activamente el caché. Las herramientas de compilación (Webpack, Vite) lo manejan automáticamente.
Purga de caché CDN: eliminar activamente el caché en el CDN mediante API. CloudFront usa Invalidation (las primeras 1000 por mes son gratuitas); Cloudflare usa Purge Cache. Adecuado para actualizaciones urgentes pero no debe ser un mecanismo habitual.
Parámetro de consulta de versión: image.jpg?v=2. Simple pero con defectos - algunos CDN ignoran los parámetros de consulta por defecto, requiriendo configuración para incluirlos en la clave de caché. Menos fiable que el hash en nombre de archivo.
TTL corto + solicitud condicional: establecer un max-age corto (como 1 hora), validando mediante ETag después de la expiración. Equilibra frescura y rendimiento, pero añade sobrecarga de red por las solicitudes condicionales.
Mejores prácticas: recursos estáticos con hash en nombre de archivo + caché largo; imágenes dinámicas con TTL corto + ETag; CDN Invalidation como medida complementaria para actualizaciones urgentes.
Control avanzado de caché con Service Worker - Soporte offline
Service Worker proporciona una capa de caché completamente programable, permitiendo acceso offline y estrategias de caché granulares.
Estrategia Cache First: primero verifica el caché, si hay coincidencia devuelve directamente; si no, solicita a la red y almacena el resultado. Ideal para recursos de imagen que cambian poco. La experiencia del usuario es la más rápida, aunque puede mostrar contenido desactualizado.
Estrategia Network First: primero solicita a la red, si tiene éxito actualiza el caché y devuelve; si falla, recurre al caché. Adecuada para escenarios que requieren frescura pero también soporte offline.
Stale While Revalidate: devuelve inmediatamente el contenido del caché (incluso expirado), mientras solicita la actualización en segundo plano. El usuario ve una respuesta instantánea y en la siguiente visita ve el contenido actualizado. El mejor equilibrio entre experiencia de usuario y frescura.
Caché dedicado para imágenes: crear un Cache Storage independiente para imágenes con un límite de tamaño (como 50MB). Cuando se excede el límite, usar la estrategia LRU (Least Recently Used) para eliminar imágenes antiguas.
Pre-caché de imágenes críticas: durante la fase de instalación del Service Worker, pre-almacenar imágenes críticas como logos e iconos, asegurando que la interfaz principal se muestre completa en modo offline. Usar la biblioteca Workbox para simplificar la gestión de caché del Service Worker.