Conceptos de caché

Este capítulo explica las decisiones que toma POM Cache antes de que configures una regla de servidor o soluciones un problema en una página. Léelo cuando necesites entender por qué una solicitud se reutilizó, se renderizó con normalidad o se excluyó deliberadamente.

POM Cache mantiene dos almacenes de origen independientes:

• Caché de HTML estático: páginas públicas completas almacenadas como index.html.
• Caché de JSON progresivo: archivos de datos generados para archivos progresivos compatibles de POM Theme.

La caché de HTML estático es el objeto de la mayoría de los ejemplos de este capítulo. El JSON tiene sus propios controles de elegibilidad, almacenamiento, entrega e invalidación; habilitar un almacén no habilita el otro.

Los tres lugares de donde puede provenir una respuesta

Para una página pública, el navegador puede recibir una respuesta de:

1. Un extremo de CDN: un servicio ascendente reutiliza una copia de extremo antes de que la solicitud llegue al origen.
2. Un acierto de caché de origen: Apache o POM Cache encuentra el index.html existente de la página.
3. WordPress: PHP, WordPress, el tema y los complementos activos renderizan la solicitud.

Estas capas son acumulativas, no intercambiables. Un acierto de CDN correcto no dice nada sobre si el archivo de POM Cache existe en el origen. Del mismo modo, un acierto de POM Cache no significa que la caché de objetos de WordPress haya intervenido.

La regla central de seguridad

Un archivo estático es una salida compartida. POM Cache solo puede reutilizarlo cuando la respuesta es adecuada para cada visitante anónimo representado por el mismo host y la misma ruta de URL.

Eso significa que los siguientes son, intencionadamente, malos candidatos:

• rutas de administración e inicio de sesión;
• vistas autenticadas o protegidas con contraseña;
• estado del carrito, del pago y de la cuenta;
• vistas previas y solicitudes del Personalizador;
• búsquedas con cadenas de consulta y otras cadenas de consulta que modifican el contenido;
• respuestas REST, de feed, de robots, de redirección y no HTML;
• métodos de solicitud que modifican el estado.

Una omisión no es un fallo de caché. A menudo es el resultado correcto.

Cómo se crea y se reutiliza un archivo HTML

Eligible public request
        │
        ├── matching index.html exists
        │       ├── Apache serves it directly, or
        │       └── the early PHP drop-in serves it
        │
        └── no usable file
                └── WordPress renders the page
                        ├── response fails final checks → return only
                        └── response passes final checks → write index.html

La primera solicitud elegible suele ser más lenta porque WordPress debe renderizarla. Las solicitudes coincidentes posteriores pueden reutilizar el archivo. POM Cache no asigna una caducidad basada en la antigüedad a los archivos HTML, por lo que los cambios de contenido deben ir acompañados de la estrategia de purga adecuada.

Elige el concepto que necesitas

• Cómo gestiona POM Cache una solicitud de página sigue una solicitud desde el servidor web hasta la escritura final.
• La caché de HTML estático y la caché de objetos de WordPress son diferentes explica por qué las dos tecnologías resuelven costes distintos.
• Entrega de Apache y entrega de PHP comparadas muestra qué puede y qué no puede inspeccionar cada ruta de origen.
• Comprende los aciertos y fallos de caché ofrece un lenguaje preciso para la verificación y la resolución de problemas.
• Por qué algunas solicitudes nunca deben almacenarse en caché describe el límite de privacidad y corrección.
• Cómo se mantienen aislados los archivos de caché por host y por sitio explica la clave del archivo y las implicaciones del host canónico.
• Cómo funciona POM Cache en WordPress multisitio cubre la infraestructura compartida y la configuración específica de cada sitio.

Cuando estos conceptos estén claros, continúa con Caché de páginas estáticas para conocer el flujo de trabajo operativo.