Evita trabajo de compresión duplicado

Elige una única capa para comprimir una respuesta determinada. POM Cache suministra el cuerpo canónico; o bien el servidor de origen o bien el CDN debe ser responsable de su codificación de transferencia.

«Ambas funciones de compresión están activadas» no es automáticamente incorrecto, pero su interacción debe ser intencional y observable.

Modelo A: CloudFront es responsable de la compresión

Este es el patrón estándar de POM:

POM Cache index.html
→ origin sends identity body
→ CloudFront selects Brotli/Gzip
→ viewer decodes it

El origen no envía Content-Encoding. CloudFront utiliza el Accept-Encoding normalizado del visitante, las comprobaciones de elegibilidad y la política de caché.

Ventajas:

• sin CPU de compresión en PHP ni Apache;
• un único archivo de origen canónico;
• las variantes de borde se crean cerca de los visitantes;
• la purga de POM Cache se mantiene independiente del formato.

Modelo B: el origen es responsable de la compresión

Un servidor de origen puede aplicar Brotli o Gzip:

POM Cache index.html
→ Apache compresses response
→ origin sends correct Content-Encoding
→ CloudFront passes and caches it

CloudFront no vuelve a comprimir una respuesta que ya tiene Content-Encoding. El origen debe negociar correctamente, enviar la cabecera correspondiente y mantener aisladas las variantes de Accept-Encoding.

Este modelo puede ser útil sin CloudFront o para los tipos que el CDN no comprime.

Encuentra al responsable actual

Solicita directamente al origen a través de la ruta de diagnóstico aprobada con:

Accept-Encoding: br,gzip

Si la respuesta del origen ya tiene Content-Encoding, la compresión del origen está activa. Los posibles responsables incluyen:

• filtros de salida Brotli/Deflate de Apache;
• otro proxy inverso;
• zlib.output_compression de PHP;
• un plugin de optimización;
• una función de hosting gestionado.

Después solicita a través del CDN y compara. No deduzcas la responsabilidad únicamente a partir de la respuesta pública.

Patrones de fallo

Trabajo de CPU sin beneficio añadido

El origen comprime cada fallo de caché mientras que la arquitectura pretendía que CloudFront lo hiciera.

Content-Encoding incorrecto

La cabecera indica Brotli/Gzip pero el cuerpo es identidad, o el cuerpo está codificado dos veces. Los navegadores pueden informar de fallos de decodificación o de contenido truncado.

Desajuste de la clave de caché

Una respuesta codificada se reutiliza para un cliente que no anunció compatibilidad.

Objeto de identidad antiguo

CloudFront se configuró para la compresión después de que el objeto se almacenara en caché y sigue sirviendo la copia anterior sin comprimir.

Reglas de cabecera en conflicto

Varias capas sobrescriben o duplican Content-Encoding o Vary.

Pasa a un único responsable

Para estandarizar en CloudFront:

1. confirma que la compresión de borde y su política de caché están listas;
2. desactiva la compresión del origen para el comportamiento seleccionado;
3. verifica que el origen devuelve identidad con el Content-Length correcto;
4. invalida las rutas de borde controladas;
5. prueba con visitantes de Brotli, Gzip e identidad.

Para estandarizar en el origen:

1. configura la negociación del servidor y Vary: Accept-Encoding;
2. verifica los bytes codificados y las cabeceras antes del CDN;
3. asegúrate de que el CDN almacena en caché correctamente las variantes de codificación;
4. comprende que CloudFront dejará pasar la codificación del origen;
5. invalida las variantes antiguas.

POM Cache permanece sin cambios

Ninguno de los dos modelos requiere archivos .br ni .gz en el árbol de POM Cache. No añadas un paso de compresión PHP a la fase dos solo porque la entrega pública deba estar comprimida.

Utiliza Verifica la entrega Brotli o Gzip después de cada cambio de responsabilidad.