Por qué POM Cache no crea archivos comprimidos

POM Cache almacena deliberadamente el documento canónico sin comprimir. La compresión se aplica cuando se entrega la respuesta, momento en el que el servidor o la CDN saben qué acepta el visitante.

Esto significa que una página caché normal tiene:

index.html

y no tiene hermanos gestionados por POM como:

index.html.br
index.html.gz

Una sola fuente, varias variantes de transferencia

Un visitante puede anunciar:

Accept-Encoding: br,gzip

Otro cliente puede aceptar solo Gzip o identity. El contenido es el mismo; solo cambia su codificación de transmisión.

Mantener un único archivo de origen permite que la capa de entrega seleccione:

• Brotli para una solicitud compatible apta;
• Gzip para otra solicitud compatible;
• la representación sin comprimir cuando no hay ninguna codificación compatible disponible.

Por qué la generación es el momento equivocado

Si POM Cache comprimiera durante la respuesta de WordPress, añadiría:

• trabajo de CPU al fallo de caché;
• varios archivos por página;
• gestión de escritura atómica para cada variante;
• más contabilidad de almacenamiento;
• limpieza de variantes después de cada purga;
• ajustes de formato y calidad dentro de PHP;
• modos de fallo adicionales cuando un hermano está incompleto.

Nada de eso mejora el HTML canónico. Una CDN puede realizar la negociación cerca del visitante y reutilizar el objeto comprimido en el borde.

La invalidación sigue siendo más sencilla

POM Cache reemplaza o elimina un archivo HTML. El borde puede descartar sus variantes Brotli, Gzip e identity para la ruta pública correspondiente según el modelo de invalidación de la CDN.

Por tanto, POM Cache no necesita saber:

• qué codificaciones se han solicitado;
• qué ubicaciones de borde las contienen;
• si la CDN recomprimió o dejó pasar una codificación del origen;
• cuándo caduca una variante de transferencia individual.

La compresión no es minificación

Estas operaciones resuelven problemas diferentes:

• La minificación de HTML cambia el documento canónico al eliminar o reescribir texto.
• Brotli/Gzip codifica la misma respuesta para la transferencia y el cliente la revierte.
• POM Cache almacena y reutiliza el documento canónico terminado.

POM Cache no realiza ni minificación ni compresión. Si otro componente cambia el HTML, valida el resultado antes de que se convierta en un archivo estático.

La compresión no es caché de páginas

Una respuesta dinámica comprimida puede seguir requiriendo un renderizado completo de WordPress. Un acierto de POM Cache sin comprimir puede seguir evitando WordPress.

Mídelas por separado:

Modelos de implementación admitidos

Usa un único responsable explícito de la compresión:

1. Compresión en el borde: el origen devuelve la representación simple de POM Cache y la CDN la comprime.
2. Compresión en el origen: Apache u otro servidor comprime y envía la Content-Encoding correcta; la CDN deja pasar y almacena en caché esa representación.

La arquitectura estándar de POM usa el primer modelo con CloudFront.

Si falta la entrega comprimida, configura la CDN o el servidor. Buscar en el directorio de POM Cache archivos .br o .gz no puede diagnosticarlo.

Continúa con Usar la compresión Brotli de CloudFront con POM Cache o Evitar trabajo de compresión duplicado.