En arquitecturas modernas con CDN y múltiples capas de proxy, la ubicación de la compresión es tan importante como la compresión en sí. Una mala decisión puede provocar doble compresión, ineficiencia de caché y consumo innecesario de CPU.
Este artículo define la ubicación correcta de la compresión en una infraestructura con Cloudflare, un Nginx proxy inverso y un Nginx backend.
Topología de referencia
Cliente
↓
Cloudflare (CDN)
↓
Nginx Proxy Inverso
↓
Nginx BackendRol de cada capa
Cloudflare
- Terminación TLS
- Brotli / Gzip
- Caché global
- Optimización de contenido
Nginx Proxy Inverso
- Control de cabeceras
- Caché intermedia (
proxy_cache) - Seguridad y rate limiting
Nginx Backend
- Generación de contenido
- Lógica de aplicación
- Acceso a recursos internos
Ubicación correcta de la compresión
Compresión habilitada en:
- Cloudflare (Brotli/Gzip)
- Nginx proxy inverso (Gzip como fallback)
Compresión deshabilitada en:
- Nginx backend
Justificación técnica
- Cloudflare siempre descomprime y recomprime el contenido.
- La compresión en el backend no llega al cliente final.
- Se evita la doble compresión y el desperdicio de CPU.
- La caché funciona mejor sin múltiples variantes de
Accept-Encoding. - El proxy inverso es el último control interno antes del CDN.
Configuración recomendada por capa
Cloudflare
- Brotli: Activado
- Auto Minify: Opcional
- Rocket Loader: Desactivado en WordPress
Nginx Proxy Inverso
- Gzip: Activado
- Brotli: No necesario
Nginx Backend
- Gzip: Desactivado
- Brotli: Desactivado
Validación del diseño
Desde Internet
curl-I https://dominioDebe devolver:
Server: cloudflare
Content-Encoding: br|gzipDesde el proxy al backend
curl-I http://backendNo debe aparecer Content-Encoding.
Conclusión
La compresión debe habilitarse una sola vez, en el punto más cercano al cliente que controle la salida del tráfico. En infraestructuras con Cloudflare, esto implica delegar Brotli al CDN y usar Gzip únicamente en el Nginx frontal, manteniendo el backend limpio y eficiente.