Qué páginas se pueden almacenar en caché

POM Cache está diseñado para HTML de WordPress público y completo que pueda reutilizarse para visitantes anónimos. Una ruta no pasa a ser apta solo porque devuelva el estado 200; tanto la petición entrante como el documento terminado deben superar las comprobaciones de caché.

Candidatos típicos

Las familias normales de páginas de WordPress que se reconocen durante el renderizado incluyen:

• la página de inicio estática;
• la página de entradas;
• las páginas publicadas y las entradas individuales;
• los archivos de categoría, etiqueta, autor, fecha, tipo de contenido y otros archivos;
• las rutas de archivo paginadas;
• los tipos de contenido públicos personalizados enrutados mediante los condicionales estándar de WordPress.

Una búsqueda enrutada a través de una ruta limpia de enlace permanente bonito puede reconocerse como un tipo de página de WordPress, pero una búsqueda convencional que dependa de ?s=... tiene un estado de consulta relevante y se omite. Evalúa si los resultados de búsqueda son realmente lo bastante estables para el sitio antes de ampliar cualquier política en torno a ellos.

Requisitos de la petición

Para HTML estático ordinario, el candidato debe:

• solicitarse con GET o HEAD;
• estar en el nombre de host público canónico;
• estar representado por una ruta de URL limpia;
• estar libre de cookies de omisión de autenticación, contraseña, autor de comentario, sesión y carrito;
• quedar fuera de la administración de WordPress y de las rutas PHP internas;
• no estar relacionado con el Personalizador ni con la vista previa;
• solicitarse como HTML en lugar de JSON o datos enlazados.

Los parámetros solo de seguimiento reconocidos por POM Cache pueden eliminarse en la ruta PHP. Cualquier otro valor de consulta implica que la petición sigue siendo dinámica.

Requisitos de la respuesta

Después de que WordPress renderice, el resultado debe:

• pertenecer a un tipo de página de frontend conocido según la política predeterminada;
• contener una salida no vacía;
• incluir un marcador de fin de documento reconocido, normalmente </html>;
• evitar un error fatal de PHP;
• evitar una redirección rastreada, o un estado de REST, feed, mapa del sitio o robots;
• no ser un 404 ordinario;
• seguir estando permitido por DONOTCACHEPAGE;
• seguir teniendo la caché habilitada cuando se produce la escritura.

Estas comprobaciones hacen que la aptitud sea una propiedad de la petición final, no solo de la URL.

Público no siempre significa cacheable

Una página públicamente accesible puede variar según:

• la geolocalización;
• el estado de consentimiento;
• la asignación de prueba A/B;
• la moneda;
• el estado de membresía;
• las cabeceras proporcionadas por el navegador;
• una sesión de terceros;
• el inventario o los precios en vivo.

POM Cache no puede inferir todos los invariantes de la aplicación. Si la salida varía pero la diferencia no forma parte de la clave de host y ruta, la integración debe definir DONOTCACHEPAGE, establecer una omisión adecuada antes de la entrega desde caché o mantener la ruta fuera del almacenamiento directo en caché del servidor.

La mejora del lado del cliente es distinta: una estructura HTML pública común puede ser segura si los datos privados se obtienen después de la carga mediante una API correctamente protegida y nunca se incrustan en el documento estático.

POM Tweaks Country pricing zones usa este modelo cuando su comprobación universal de seguridad HTML es correcta. POM Cache permite entonces un archivo por host y ruta cuyos precios de WooCommerce, insignias de oferta, acciones, estado de variación y precarga compatible de POM Faceted Search permanecen neutros. El navegador resuelve la zona actual mediante peticiones no cacheables. Si la comprobación no está lista o pasa a ser insegura, toda la caché HTML del sitio actual se omite hasta que se corrija la condición.

Evalúa una ruta nueva

Antes de añadirla a una lista de precalentamiento:

1. compara el HTML sin sesión iniciada en dos sesiones de navegador limpias;
2. repite con los estados de inicio de sesión, contraseña, comercio, consentimiento y localización que use el sitio;
3. identifica cada parámetro de consulta y cabecera que pueda cambiar el contenido;
4. confirma el nombre de host canónico y el enlace permanente;
5. genera un archivo e inspecciónalo en busca de marcado privado o específico de la sesión;
6. verifica la ruta de invalidación elegida de entrada/término/manual;
7. prueba la misma ruta a través de Apache y del CDN, no solo a través de WordPress.

Si no puedes explicar por qué un documento almacenado es válido para todas las peticiones anónimas coincidentes, deja la ruta como dinámica.

Usa Which requests are excluded como lista de comprobación negativa.