Comparativa independiente · sin rankings de pago
Inicio / Blog / Técnico / Encabezados de caché HTTP: hacer que el navegador, la CDN y la aplicación cooperen

Encabezados de caché HTTP: hacer que el navegador, la CDN y la aplicación cooperen

Control de caché inconsistente entre nginx, PHP y Cloudflare: resultado: contenido obsoleto para los usuarios u origen saturado porque nada se puede almacenar en caché en el borde.

Redacción Hébergeurs.eu 8 min Actualizado 19 jul. 2026

La página del producto muestra el precio anterior después de una promoción flash: el soporte culpa a "la CDN". En realidad, PHP envía Cache-Control: public, max-age=3600 en el catálogo HTML, Cloudflare respeta esta directiva y solo la API del carrito devuelve no-store. Los activos de JavaScript se mantienen actualizados gracias al hash en el nombre del archivo; el catálogo HTML permanece congelado durante una hora entera. Nadie ha documentado qué capa almacena en caché qué recurso.

Los encabezados de caché HTTP son el contrato entre su origen, la CDN y el navegador. Desalineado, pagas varias veces: latencia para el usuario, sobrecarga de origen o contenido desactualizado que debilita la confianza. Una CDN activada sin una política coherente añade un paso a la red sin eliminar el beneficio.

La suite establece una matriz recurso por recurso, no un control deslizante "habilitado para caché" en el panel de alojamiento.

Cache-Control: las directivas que realmente importan

Cache-Control es la directiva más leída por navegadores y CDN. Cada palabra clave tiene un efecto específico:

DirectivaEfecto
edad-max=NRecurso considerado N segundos nuevos en el lado del navegador
s-maxage=NMisma lógica, pero para cachés compartidas (CDN)
sin tiendaSin almacenamiento: datos confidenciales, páginas de cuentas
sin cachéAlmacenamiento autorizado, revalidación obligatoria antes de su uso
inmutableActivo con huellas dactilares: sin revalidación innecesaria
obsoleto mientras se revalidaOfrecer una versión obsoleta durante una actualización asincrónica

Para HTML dinámico (catálogo, artículos, páginas personalizadas), prefiera "privado, sin caché" o una "edad máxima" corta junto con revalidación. Para recursos estáticos con un hash en el nombre (/app.abc123.js), el estándar esperado es public, max-age=31536000, inmutable.

Una CDN no adivina su intención: obedece los encabezados, a menos que exista una regla de anulación explícita en el panel.

En hosting compartido o VPS con CDN integrado (OVH, Infomaniak, etc.), compruebe que las reglas del panel no contradicen lo que envía su aplicación. Los conflictos entre nginx, PHP y CDN son una de las causas más comunes de contenido obsoleto.

CDN, origen y trampa de encabezado Vary

El encabezado Vary le dice al caché qué dimensiones de la solicitud influyen en la respuesta. Siguen surgiendo dos casos:

Variar: Aceptar-Codificación: esencial si sirve Brotli y gzip según el cliente. Sin Vary, una CDN puede almacenar en caché la versión gzip y entregársela a un cliente que espera Brotli.

Variar: Aceptar: necesario si negocia el formato de imagen (WebP, AVIF) a través del encabezado Aceptar. Sin Vary, la CDN puede enviar un AVIF a un navegador que no lo admita. Para conocer la estrategia completa, consulte WebP y AVIF.

Configure la clave de caché en el lado CDN: incluya codificación, excluya cookies de sesión en recursos públicos. Una Set-Cookie en un archivo CSS puede evitar el almacenamiento en caché perimetral con algunos proveedores.

ETag, respuestas 304 y carga en origen

La revalidación condicional le permite evitar volver a descargar un archivo sin cambios. El cliente envía "If-None-Match" con la ETag recibida; el servidor responde 304 sin cuerpo si el contenido es idéntico.

En un clúster de múltiples nodos, una ETag (inodo, marca de tiempo) generada por máquina se vuelve inconsistente: el cliente recibe 200 en lugar de 304 y el origen se hace cargo de la carga. Prefiera un hash de contenido estable o delegue el caché a la CDN con duraciones prolongadas en activos con huellas dactilares.

Para un usuario JSON API (/api/me, /api/orders), la norma sigue siendo no-store o un caché muy corto con clave por usuario. Una caché CDN compartida en estas rutas expone datos privados.

Estrategia por tipo de recurso

Cada tipo de archivo merece su política: documentada, probada y compartida con el equipo:

RecursoPolítica recomendada
CSS/JS con hash1 año, inmutable
Imágenes estáticasDe 7 a 30 días + purga específica tras la implementación
HTML públicoshort max-age + stale-when-revalidate, o no-cache
API de usuarioprivado, sin tienda
Feeds, mapas del sitioRevalidación corta de max-age o ETag

En WordPress, los complementos modifican los encabezados sin coordinación: audite el filtro wp_headers y compare lo que devuelven nginx, PHP-FPM y CDN. Un complemento de caché de página puede entrar en conflicto con un complemento de minificación que cambia los nombres de los archivos.

Para la implementación e invalidación, haga una referencia cruzada de esta lectura con HTTP/2 y multiplexación: menos conexiones no compensan los activos mal almacenados en caché.

Purga, implementación y errores clásicos

En cada auditoría se repiten tres errores:

  1. Olvídese de la limpieza de CDN después de la implementación de HTML sin huellas dactilares: el visitante ve la versión anterior durante horas.
  2. Cache-Control: max-age=0 sin no-store — comportamiento variable dependiendo de la CDN; alguna tienda de todos modos.
  3. Cookies en activos: Set-Cookie en un archivo estático puede bloquear el almacenamiento en caché perimetral.

Pruebe sistemáticamente con curl -I desde el borde de la CDN y desde el origen. Los encabezados deben ser idénticos o la diferencia debe estar documentada (terminación TLS a CDN, compresión, etc.).

Compare ofertas con CDN integrada a través de nuestro directorio y la comparación: algunos hosts imponen reglas predeterminadas que usted debe conocer antes de implementar.

La parte superior: CDN habilitado, nada almacenable en caché

Esto es lo que no dice la casilla de verificación "CDN habilitado" en el panel.

Lograr que las tres capas cooperen significa aceptar que cada tipo de archivo tenga su propia política, no una configuración global de "activación de caché".

Decide y avanza sin puntos ciegos

En medio día, podrás recuperar el caché:

  1. Dibuje una matriz recurso → directiva (Cache-Control, Vary, duración) y compártala con el equipo.
  2. Activos estáticos Huella digital (hash en el nombre) para permitir duraciones prolongadas sin purga ciega.
  3. Marque los encabezados Variar si está negociando compresión o formato de imagen.
  4. Prueba con curl -I desde el borde y el origen: documenta las desviaciones esperadas.
  5. Planifique una depuración específica para cada implementación de HTML, nunca una "purga de todo" sin una cola de reversión.
  6. Compare hosts con CDN a través del directorio si está migrando o renegociando su pila.

Para una auditoría rápida, tome una URL HTML y un archivo JS; los encabezados deben ser consistentes en las tres capas. Si ya eres anfitrión de un jugador europeo, consulta su perfil en Hébergeurs.eu para conocer las reglas CDN predeterminadas.

Preguntas frecuentes

¿público versus privado versus sin tienda?

"público" permite que la CDN almacene en caché la respuesta de todos los visitantes. "privado" limita el almacenamiento al navegador del usuario, adecuado para páginas de cuentas. no-store prohíbe cualquier almacenamiento, incluso en la memoria, de datos confidenciales. no-cache permite el almacenamiento pero requiere revalidación antes de su uso.

edad máxima y s-máxima?

max-age se aplica al navegador; s-maxage a cachés compartidos como CDN. En un activo versionado (/app.abc123.js), una max-age larga junto con inmutable evita solicitudes innecesarias. El HTML dinámico merece duraciones cortas o una revalidación sistemática.

¿Cómo invalidar después de la implementación?

Tome huellas digitales de los archivos (hash en el nombre), purgue la CDN de manera específica en las URL en cuestión o agregue un parámetro de versión. Evite la purga total en producción sin un plan de reversión: puede saturar el origen si todo el tráfico vuelve a fallar.

¿ETag o última modificación?

El ETag permite una revalidación condicional precisa (respuesta 304 sin cuerpo). "Última modificación" también funciona, pero la ETag basada en un hash de contenido es más confiable en clústeres. Tenga cuidado con las ETags generadas por máquinas: hacen que la revalidación sea ineficaz.


El caché efectivo se lee en los encabezados, no en la casilla de verificación CDN del panel de alojamiento.

Compara proveedores europeos

Filtra por cumplimiento, ubicación y caso de uso — luego abre las fichas para verificar el alcance real.

Explorar el directorio
Blog

Lecturas relacionadas

Todos los artículos →