Almacenamiento en caché de páginas estáticas

El almacenamiento en caché de páginas estáticas convierte el HTML final de una página pública apta en un archivo reutilizable. Es más eficaz para el tráfico anónimo, porque un acierto puede evitar el renderizado de plantillas, las consultas a la base de datos y, en la ruta de Apache, incluso al propio PHP.

POM Cache almacena un archivo llamado index.html para cada nombre de host y ruta de URL que cumpla los requisitos. Las páginas ordinarias con URL limpias no usan copias comprimidas, variantes específicas de usuario ni caducidad basada en antigüedad. Las variantes de consulta finitas opcionales tienen su propia caducidad.

Qué necesitas antes de habilitarlo

Confirma estas condiciones:

  • el sitio usa enlaces permanentes bonitos que funcionan;
  • las páginas públicas normales se renderizan correctamente sin caché;
  • PHP puede escribir debajo de Cache Location;
  • WP_CACHE es true;
  • POM_CACHE_HOME apunta al directorio de POM Cache instalado;
  • wp-content/advanced-cache.php es el drop-in de POM Cache previsto;
  • sabes qué cambios editoriales provocarán una purga automática o manual;
  • cualquier CDN se puede omitir o invalidar durante la verificación del origen.

POM Cache informa de las tres comprobaciones de arranque de WordPress en POM Cache → Advanced → WordPress configuration. El informe es de solo lectura.

  1. Enable the static HTML cache y guarda la elección de tiempo de ejecución del sitio actual.
  2. Install and verify the advanced-cache drop-in.
  3. Genera una página pública sencilla e inspecciona the cache file layout.
  4. Aprende which pages can be cached y which requests are excluded.
  5. Prueba logged-in behavior y cookies, query strings, and methods.
  6. Revisa errors and 404 responses y response headers.
  7. Opcionalmente, cache selected taxonomy filters con listas de términos acotadas y caducidad.
  8. Añade la entrega directa de Apache únicamente después de que la ruta de PHP sea correcta.

Este orden mantiene el comportamiento de la aplicación observable antes de que el servidor web empiece a omitir PHP.

Para comprender las dos etapas de PHP en detalle, lee Phase one: early static delivery y Phase two: validate and store the rendered response. Estos artículos explican por qué un acierto posterior contiene el marcador de caché almacenado aunque el primer visitante reciba la respuesta original de WordPress.

La generación y la entrega son independientes

POM Cache necesita WordPress para crear un archivo que falta:

First eligible request
→ WordPress renders
→ POM Cache checks the complete response
→ temporary file is written
→ temporary file becomes index.html

Las solicitudes posteriores pueden reutilizarlo:

Repeat request
→ Apache direct hit, or
→ early PHP hit through advanced-cache.php, or
→ WordPress renders because the request bypasses or misses

El ajuste Caching controla la generación de PHP y la entrega estática para el sitio actual. Las reglas de Apache copiadas previamente operan antes de que se pueda leer ese ajuste de PHP; si deshabilitas la caché como medida de emergencia, elimina o deshabilita también la reescritura directa y purga los archivos HTML existentes.

Decide cómo vuelven a estar actualizadas las páginas

Los archivos HTML permanecen hasta que se eliminan o se reemplazan. En General → Runtime, POM Cache ofrece purgas opcionales para:

  • cambios en publicaciones públicas;
  • cambios en términos de taxonomías.

Ambos interruptores borran el árbol HTML del sitio actual cuando ocurre su evento correspondiente. Son deliberadamente amplios porque un cambio de contenido puede afectar a las páginas de inicio, los archivos, los menús, los bloques de contenido relacionado o a varias URL.

Si dejas un interruptor deshabilitado, haz que la purga manual forme parte del flujo de publicación. Borrar POM Cache no invalida automáticamente un CDN intermedio.

Criterios de aceptación en producción

Antes del despliegue, demuestra todo lo siguiente:

  • una página canónica sin sesión iniciada crea un index.html;
  • una vista repetida reutiliza la respuesta almacenada;
  • el estado de inicio de sesión, contraseña, autor de comentario y WooCommerce la omite;
  • las cadenas de consulta significativas y las solicitudes no HTML permanecen dinámicas;
  • las vistas previas, redirecciones y salidas incompletas no se almacenan; los 404 reutilizan un documento compartido independiente después de que WordPress resuelva la solicitud;
  • un cambio en una publicación o un término sigue la política de invalidación elegida;
  • los límites de host y subsitio permanecen diferenciados;
  • el comportamiento de Apache/CDN coincide con el contrato de seguridad de PHP.

Empieza con Enable the static HTML cache. Usa Caching concepts primero si “hit”, “miss” y “bypass” aún no te quedan claros.