Caché y cabeceras de respuesta

Las cabeceras revelan qué capa respondió y cómo pueden tratar la respuesta las cachés posteriores. El HTML estático almacena el cuerpo del documento, no una reproducción serializada de todas las cabeceras producidas durante el renderizado original de WordPress.

Cabeceras de una petición PHP temprana

Cuando el drop-in sirve index.html, POM Cache envía:

HTTP status: 200
Content-Type: text/html; charset={WordPress site charset}
Content-Length: {file size}
X-POM-Cache: Served static cache from PHP; phase=early

Content-Length se envía cuando el sistema de archivos informa de un tamaño. Para HEAD, la respuesta tiene las cabeceras pero POM Cache no lee el cuerpo del archivo.

El valor de X-POM-Cache es de diagnóstico. No define la frescura del navegador ni la de la CDN.

Cabeceras de Apache

La entrega directa de Apache se produce sin PHP, por lo que no añade la cabecera de acierto PHP de POM Cache. El bloque de rewrite suministrado establece UTF-8 como juego de caracteres predeterminado, mientras que el resto del comportamiento de la respuesta sigue la configuración efectiva de Apache, del host virtual, del proxy y de la CDN.

No trates la ausencia de X-POM-Cache como prueba de un fallo. Usa el comentario de generación sin cambios, los registros del servidor o una traza de origen aprobada.

Cabeceras mientras WordPress renderiza

Para un renderizado dinámico normal del frontend en el que se inicia su búfer de salida, POM Cache envía:

Vary: Cookie

Esto anuncia que el estado de las cookies puede afectar a la representación dinámica. Un despliegue puede sobrescribir o suprimir ese valor con la constante de configuración POM_CACHE_VARY_HEADER.

Cambiar Vary afecta al comportamiento de la caché ascendente y a la cardinalidad de la clave de caché. Coordínalo con la configuración de la CDN en lugar de tratarlo como una cabecera cosmética.

Lo que POM Cache no establece para el HTML estático

El tiempo de ejecución HTML no define una política integrada de Cache-Control basada en la antigüedad y no crea variantes Brotli/Gzip. La vida útil del navegador, la vida útil del edge compartido, la revalidación y la codificación de contenido pertenecen al servidor web o a la CDN.

Esto difiere de la caché JSON Progresivo independiente, que tiene un valor configurable de Cache-Control para JSON. No traslades las expectativas de cabeceras JSON al HTML.

Las cabeceras originales de WordPress no se almacenan en index.html

Supón que el primer renderizado dinámico añade una cabecera PHP personalizada. El cuerpo HTML puede almacenarse en caché, pero esa cabecera no se incrusta como metadatos de respuesta en el archivo. Una petición posterior de Apache o de PHP temprano solo tendrá las cabeceras suministradas por esa vía de entrega.

Si se requiere una cabecera pública en cada respuesta en caché —política de seguridad, indicación de CDN, metadatos de idioma u otro invariante—, configúrala en una capa que se ejecute para los archivos estáticos, normalmente el servidor web o la CDN.

Las cabeceras que contienen datos por usuario, por petición o secretos son indicio de que la respuesta no debería compartirse.

Las cabeceras de la CDN describen una caché distinta

Los servicios pueden añadir Age, Via, X-Cache o valores específicos del proveedor. Interprétalos por separado:

• Acierto de CDN → se reutilizó el objeto del edge;
• X-POM-Cache ... phase=early → el PHP de origen reutilizó el HTML de POM Cache;
• ninguno → podría ser entrega directa de Apache o un renderizado dinámico.

Traza desde la capa más externa hacia dentro y evita usar la cabecera de un proveedor como evidencia para otra capa.

Inspeccionar una respuesta

Con el panel de red del navegador o un cliente de línea de comandos aprobado:

1. registra la URL final y el estado;
2. inspecciona Content-Type, Content-Length, Vary, Cache-Control, Age y los diagnósticos de caché;
3. repite después de una purga del origen;
4. repite después de la invalidación del edge;
5. compara las peticiones anónimas y las autenticadas;
6. envía HEAD y confirma que no hay cuerpo;
7. confirma que las peticiones no HTML de Accept nunca reciben el archivo de la página.

No compartas valores de autorización, Cookie o Set-Cookie en los registros de soporte.

Continúa con Verificar un acierto de caché para una comprobación capa por capa.