Cómo gestiona POM Cache una solicitud de página

Una sola vista de página puede pasar por varios puntos de decisión independientes. Entender su orden evita un error común: buscar una cabecera de WordPress en una respuesta que Apache o una CDN ya han servido.

La secuencia siguiente describe la ruta de HTML estático de una solicitud pública típica de GET o de HEAD.

1. Una caché intermedia puede responder primero

Si hay una CDN configurada, esta evalúa su propia clave de caché, las cookies, la política de cadenas de consulta y las reglas de expiración. Un acierto en el borde finaliza la solicitud antes de que el origen la vea.

POM Cache no puede crear, purgar ni diagnosticar por sí solo esa entrada de borde. Al comprobar el comportamiento del origen, usa el método de prueba de origen aprobado de la implementación o invalida primero la copia de borde.

2. Apache puede buscar el archivo estático

Con el bloque de reescritura recomendado instalado, Apache comprueba la solicitud antes de la reescritura estándar de WordPress. La regla proporcionada es deliberadamente estricta: espera una solicitud pública limpia, una URL con barra final, una cadena de consulta vacía, ninguna cookie de omisión listada y un index.html existente en la ubicación calculada de host y ruta.

Cuando se cumplen todas las condiciones, Apache envía el archivo directamente. PHP y WordPress no se inician, por lo que esta es la ruta de origen menos costosa.

La entrega de Apache no añade la cabecera X-POM-Cache específica de PHP. Por tanto, el comentario de generación de caché sin cambios o la observación a nivel de servidor es una prueba mejor.

3. WordPress puede cargar el drop-in temprano

Si Apache no responde, el núcleo de WordPress comprueba WP_CACHE. Cuando está true, WordPress carga wp-content/advanced-cache.php antes del arranque normal de los plugins.

El drop-in de POM Cache usa POM_CACHE_HOME para cargar el tiempo de ejecución temprano. Ese tiempo de ejecución:

• carga la configuración efectiva del sitio;
• rechaza las solicitudes de backend, escritura, Personalizador, estado de consulta y cookies de omisión;
• asigna el host actual y la ruta normalizada a un index.html;
• confirma que el archivo resuelto permanece dentro del directorio de caché configurado;
• sirve un acierto válido y detiene la solicitud.

Un acierto temprano de PHP incluye:

X-POM-Cache: Served static cache from PHP; phase=early

Para HEAD, POM Cache envía el estado y las cabeceras sin el cuerpo del archivo.

4. WordPress renderiza un fallo o una omisión

Si ninguna capa ha servido un archivo, WordPress continúa con normalidad. Una plantilla de tema, un bloque, un shortcode o un plugin puede seguir produciendo una respuesta perfectamente válida aunque no sea almacenable en caché.

Durante esta fase, POM Cache registra el tipo de página y el estado final de la respuesta. También inicia un búfer de salida solo cuando el tiempo de ejecución de HTML está habilitado y la solicitud no está ya excluida.

Esta distinción importa:

• Fallo: no se encontró ningún archivo reutilizable para una solicitud que, por lo demás, era apta.
• Omisión: la política dice que la solicitud no debe leer ni escribir el archivo compartido.

Ambas llegan a WordPress, pero solo se espera que la primera rellene la caché.

5. Se evalúa la respuesta completa

Al final de la renderización, POM Cache comprueba la salida real. El árbol por URL excluye búferes vacíos, respuestas fatales, 404, redirecciones, respuestas REST/feed/robots, representaciones no HTML y documentos sin un marcador de cierre reconocido. En su lugar, los 404 aptos reutilizan un documento compartido independiente después de que WordPress resuelva la ruta que falta; consulta 404 behavior.

También respeta DONOTCACHEPAGE, de modo que otro componente pueda declarar que una página no es adecuada para el almacenamiento compartido.

Si las comprobaciones fallan, el visitante sigue recibiendo la respuesta de WordPress. No se crea ningún index.html.

6. Un archivo apto se escribe de forma atómica

Para una respuesta almacenable en caché, POM Cache:

1. construye el directorio a partir del host de la solicitud actual y la ruta de la URL;
2. resuelve y valida ese directorio por debajo de Cache Location;
3. crea un archivo temporal con nombre único;
4. escribe el HTML completo más los comentarios de generación de caché;
5. rechaza un archivo temporal vacío;
6. renombra el archivo a index.html.

El renombrado evita exponer una página a medio escribir a otra solicitud. El primer visitante recibe el búfer renderizado original; los visitantes posteriores pueden recibir la versión almacenada.

7. Queda disponible un enlace de entrega tardía

Después de que WordPress conozca al usuario actual y el objeto consultado, POM Cache realiza una búsqueda tardía. No sirve desde ese punto de forma predeterminada. Los desarrolladores pueden optar por una política tardía cuidadosamente restringida mediante el filtro de aptitud documentado.

Esta capacidad no es una razón para almacenar en caché vistas privadas. Su propósito es permitir que una integración tome una decisión que era imposible antes de que WordPress se cargara.

Lee el resultado correctamente

Una solicitud es saludable cuando su resultado coincide con la política prevista:

• vista pública repetida → acierto de origen o de borde;
• primera vista pública tras una purga → renderización de WordPress seguida de una escritura;
• solicitud con sesión iniciada, carrito, vista previa, consulta o no HTML → omisión;
• respuesta incompleta o con error → devuelta pero no almacenada.

Usa Understand cache hits and misses para verificar qué resultado se produjo, o Understand cache generation after WordPress renders para las comprobaciones de la respuesta final.