El problema: cada foto de producto es una petición
El e-commerce de moda vive de la fotografía. Solo la portada de esta tienda referencia más de 130 imágenes — sliders de más de 300 KB, fotos de producto de entre 50 y 350 KB — y las páginas de categoría y de producto repiten el patrón. Sin una CDN, cada visitante descarga cada uno de esos archivos desde el servidor de origen: las mismas fotos, miles de veces al día, compitiendo por los mismos workers de PHP y el mismo ancho de banda que deberían estar sirviendo carritos y pagos.
El objetivo no era nada exótico: sacar por completo del origen el tráfico repetido de imágenes, mantener el HTML lo bastante fresco para una tienda, y hacerlo sin tocar el tema de WordPress.
La regla de imágenes: cachear un año, servir en milisegundos
El corazón de la configuración es una única regla de entrega que coincide con las extensiones de imagen (jpg, jpeg, png, gif, webp, svg, ico). Cachea las respuestas correctas en el edge durante un año completo, añade una cabecera CORS para que las imágenes puedan incrustarse donde haga falta, y comprime con Brotli y gzip lo que se beneficia de ello.
Un año suena agresivo hasta que recuerdas cómo cambian realmente las imágenes de producto: no cambian. Una foto subida para un producto conserva su URL hasta que el producto desaparece; un rediseño sube archivos nuevos con nombres nuevos. Los TTLs largos significan que el edge casi nunca tiene que volver a preguntar al origen — en nuestro muestreo, todas las imágenes de la portada ya eran un HIT. Y para el caso raro en que una imagen deba cambiar manteniendo la URL, una purga dirigida limpia exactamente esa entrada.
La regla de HTML: un día, con un truco para el tráfico de campaña
El HTML recibe un trato distinto: la portada se cachea durante un día — lo bastante largo para que el edge absorba casi todo el tráfico anónimo, lo bastante corto para que los cambios de merchandising aparezcan el mismo día, y una purga se encarga de lo urgente.
El detalle que merece la pena copiar es la normalización de la query. El tráfico de campañas sociales llega con parámetros de tracking — cada clic de Facebook lleva un fbclid único. Cacheado de forma ingenua, cada clic sería una URL "distinta", cada visitante de campaña un MISS de caché, y el origen encajaría toda la carga del pico publicitario en el peor momento. La regla excluye fbclid de la clave de caché, así que diez mil clics de campaña son una sola entrada de caché. El parámetro sigue llegando a la analítica; simplemente deja de fragmentar la caché.
Lo que medimos
Números del sitio en producción, medidos a través de la internet pública (así que incluyen la distancia de red real, no condiciones de laboratorio). Una imagen cacheada responde con un time-to-first-byte mediano de en torno a 0,15 segundos. Forzar al edge a pedir el mismo archivo al origen deja la mediana en torno a 0,54 segundos — aproximadamente 3,5 veces más lento. El HTML de la portada, servido como HIT de caché con compresión Brotli, empieza a llegar en unos 0,27 segundos.
Multiplica esa diferencia por 130+ imágenes por vista de página y el efecto en la velocidad percibida no es sutil: el navegador empieza a pintar fotos de producto mientras una configuración sin caché seguiría esperando las primeras. Y cada HIT es una petición que el origen nunca ve — durante un pico de campaña, el trabajo del origen se reduce a servir carritos.
El resto del stack: Redis y WAF sin esfuerzo extra
Otras dos piezas funcionan junto a la caché, ambas activadas en lugar de construidas. En la capa de hosting, una caché de objetos Redis respalda WordPress, convirtiendo las consultas repetidas a la base de datos — opciones, menús, metadatos de producto — en lecturas de memoria para las peticiones que sí llegan a PHP. Delante, el preset del WAF de la cuenta inspecciona el tráfico entrante en el mismo edge que sirve la caché, de modo que los patrones de ataque comunes se filtran antes de llegar a hacer cola para el origen.
Nota honesta: este cliente no usa nuestra optimización de imágenes WebP/AVIF — los números de arriba son pura caché y compresión. Queda margen medible sobre la mesa (los formatos modernos suelen recortar sustancialmente el peso de las imágenes), lo que hace el resultado más transferible, no menos: esto es lo que consigue la caché de edge por sí sola.
Qué copiar para tu propia tienda
El patrón se traslada a cualquier sitio cargado de imágenes con cuatro reglas prácticas. Cachea las imágenes por extensión con un TTL largo y purga cuando cambien, en lugar de usar TTLs cortos "por si acaso" — para lo seguro está la purga. Cachea tu HTML durante horas o un día, no cero, y deja que una purga en cada despliegue se ocupe de la frescura. Normaliza los parámetros de tracking (fbclid, y utm_* donde tu analítica lo permita) fuera de la clave de caché antes de tu próxima campaña, no después de que funda el origen. Y verifica con mediciones, no con sensaciones: un curl con cache-buster frente a uno sin él te dice exactamente lo que vale el edge en tus propias páginas.
Preguntas frecuentes
¿Es seguro un TTL de imagen de 1 año para e-commerce?
Sí, porque las URLs de las imágenes de producto son estables: los productos nuevos traen nombres de archivo nuevos. El caso de riesgo — reemplazar una imagen en la misma URL — se resuelve con una purga dirigida, que surte efecto en segundos.
¿Por qué cachear la portada solo un día cuando las imágenes reciben un año?
El HTML cambia con el merchandising — campañas, precios, productos destacados. Un día significa que el edge sigue absorbiendo casi todo el tráfico de lectura, mientras que los cambios del mismo día aparecen sin que nadie tenga que pensar en ello; los cambios urgentes están a una purga de distancia.
¿Qué hace realmente excluir fbclid de la clave de caché?
Sin ello, cada clic de anuncio es una URL única y por tanto un MISS de caché — tu tráfico de pago, el más caro que tienes, aterriza entero en el origen. Con ello, todos los clics comparten una sola entrada cacheada. El parámetro sigue llegando intacto a tus scripts de analítica.
¿WebP/AVIF lo habría hecho aún más rápido?
Recortaría aún más los tamaños de transferencia (a menudo un 30-70% en fotos), que es exactamente por lo que señalamos que este cliente lo tiene desactivado — la cifra de 3,5x es solo caché. Activar la optimización de imágenes se suma a todo lo descrito aquí, no lo sustituye.
¿Necesito cambiar mi tema de WordPress para algo de esto?
No. Todo lo de este caso práctico — reglas de caché, normalización de query, compresión, WAF, Redis — se configura en la capa de entrega y de hosting. La aplicación no se modificó.