Comprender la generación de caché tras el renderizado de WordPress

La fase dos crea HTML estático. A diferencia del drop-in inicial, se ejecuta con WordPress cargado, por lo que puede clasificar la página consultada, observar redirecciones y cabeceras de estado, e inspeccionar el documento renderizado completo.

El visitante no espera a un rastreador independiente. Un fallo de caché apto puede rellenar su propia entrada de caché.

Cuándo comienza el almacenamiento en búfer de salida

POM Cache inicia su búfer de salida HTML cuando:

  • General → Runtime → Caching está habilitado;
  • la solicitud no es una operación del backend;
  • no queda ninguna cadena de consulta significativa;
  • el tiempo de ejecución estático no se ha deshabilitado ya.

El renderizado dinámico de WordPress continúa entonces con normalidad. POM Cache registra condicionales para los tipos de páginas del frontend habituales, como páginas, entradas, archivos, términos, autores, la portada y la página de entradas. También anota el estado de REST/feed/robots/404 y los estados de redirección rastreados.

La primera puerta de inspección

Al final de la solicitud, la devolución de llamada del búfer de salida rechaza el almacenamiento cuando detecta:

  • un error fatal de PHP;
  • DONOTCACHEPAGE;
  • una cadena de consulta significativa;
  • POST, PUT o DELETE, o datos de formulario enviados;
  • una vista previa;
  • una ruta rechazada del backend de WordPress o de PHP;
  • salida de REST, robots, redirección, feed o sitemap;
  • una representación JSON/ActivityPub/de datos enlazados;
  • un tipo de página no reconocido bajo la política predeterminada;
  • una cookie de omisión de WordPress, contraseña, autor de comentario o WooCommerce.

Los desarrolladores pueden inspeccionar o transformar el búfer en esta etapa con el filtro de búfer de salida documentado, pero un despliegue público no debería usar ese gancho para disfrazar una solicitud no segura como cacheable.

La puerta final del documento

Una respuesta que pasa la primera puerta todavía necesita ser un documento de caché completo. POM Cache no escribe cuando:

  • el búfer está vacío;
  • la solicitud es un 404, que usa el documento compartido independiente en lugar de un archivo por URL;
  • no hay ningún marcador de fin de documento reconocido;
  • el tiempo de ejecución se deshabilitó antes de la escritura;
  • hay una cookie de omisión presente en la comprobación final.

Para las páginas estándar, la señal de finalización importante es una etiqueta de cierre </html>. Esto evita que una respuesta PHP truncada reemplace una página estática anteriormente válida.

Construir la copia almacenada

POM Cache mantiene separados el búfer renderizado del visitante y el búfer de almacenamiento. Añade comentarios de diagnóstico a la copia que se escribirá:

<!-- Page generated in 0.123 seconds. -->
<!-- Cached page generated by POM-Cache on 2026-07-27 12:34:56 -->
<!-- pom cache -->

Los valores anteriores son ejemplos. La duración de la generación de la página y la marca de tiempo reflejan la solicitud que creó el archivo.

Como el primer visitante recibe el búfer original de WordPress, estos comentarios de almacenamiento se observan de forma más fiable en una visita posterior.

Publicación atómica

La operación de archivo sigue esta secuencia:

  1. calcular el directorio de host y ruta;
  2. crear los directorios que falten;
  3. resolver el directorio real y verificar la contención de la raíz de caché;
  4. escribir el búfer de almacenamiento completo en un archivo .tmp con nombre único;
  5. cerrarlo y rechazarlo si su tamaño es cero;
  6. renombrarlo a index.html.

Por tanto, los demás visitantes deberían ver o bien el archivo completo anterior o bien el archivo completo nuevo, no una respuesta escrita parcialmente.

Ganchos de invalidación automática

Cuando los interruptores de tiempo de ejecución correspondientes están habilitados, la fase dos también registra purgas amplias del sitio actual para:

  • guardados, eliminaciones, envíos a la papelera, publicaciones, transiciones de estado y asignaciones de términos relevantes de entradas públicas;
  • creación, edición, eliminación de términos y cambios admitidos en metadatos de términos.

Las revisiones, los autoguardados y los tipos de contenido no visibles no se tratan como cambios de página pública en la ruta de purga de entradas.

Los ganchos eliminan el árbol del sitio; no intentan predecir la única página afectada, porque el contenido puede aparecer en archivos, navegación, elementos relacionados o plantillas compartidas.

Verificar un archivo generado

  1. Elimina la caché HTML actual del sitio.
  2. Solicita una URL publicada sencilla una vez sin haber iniciado sesión.
  3. Confirma que Cache Contents informa de un archivo.
  4. Localiza su index.html según el diseño del archivo de caché público.
  5. Confirma que contiene la página completa y los tres comentarios de diagnóstico.
  6. Solicita una URL deliberadamente incompleta, redirigida o 404 y confirma que no reemplaza ni crea un archivo normal.

Para los filtros de desarrollador que participan en estas puertas, usa Filtros del búfer de salida.