Cómo funciona realmente la compresión HTTP
La compresión en la web es una negociación silenciosa que ocurre en cada petición. El navegador anuncia lo que sabe descomprimir en una cabecera Accept-Encoding — los modernos envían gzip y br. El servidor elige uno, comprime el cuerpo de la respuesta y lo etiqueta con Content-Encoding para que el navegador sepa cómo desempaquetarlo. Ni el código de tu aplicación ni tu HTML cambian; la traducción ocurre por completo en tránsito.
La recompensa es grande porque el texto se comprime extremadamente bien. Una página HTML de 100 KB suele viajar como 20 KB con Gzip; un bundle de JavaScript a menudo se reduce en tres cuartas partes. Para los visitantes con conexiones lentas o móviles esa diferencia es la parte visible de tu tiempo de carga — por eso la compresión es esa rara optimización que es casi gratis y casi siempre acertada para el texto.
Qué mejora Brotli de verdad
La ventaja de Brotli viene de dos decisiones de diseño: un formato más inteligente y un diccionario incorporado de cadenas que aparecen constantemente en la web — etiquetas HTML, nombres de propiedades CSS, tokens habituales de JavaScript. El texto web es exactamente para lo que fue afinado, y en él Brotli suele producir archivos un 15-20% más pequeños que Gzip a los niveles de compresión que los servidores usan en tiempo real.
Mantén el marco honesto, eso sí: ese 15-20% se suma a la reducción del 70-80% que Gzip ya consigue. Si una página viaja a 20 KB con Gzip, Brotli la deja en unos 16-17 KB. Merece la pena — se acumula en cada asset y cada visitante — pero es un refinamiento, no una revolución. Si lees gráficas de benchmarks que prometen diferencias dramáticas, comprueba si comparan el nivel más lento y de mayor esfuerzo de Brotli contra el nivel por defecto de Gzip; con esos ajustes Brotli es demasiado lento para ejecutarse por petición y se usa en cambio para precomprimir archivos estáticos.
La compatibilidad dejó de ser una preocupación hace años: prácticamente todos los navegadores actuales envían br en su Accept-Encoding, y gracias a la negociación el raro cliente antiguo que no lo hace simplemente recibe Gzip. Para el visitante no hay ningún escenario en contra.
Qué no debe comprimirse nunca
La regla espejo importa igual: comprimir bytes ya comprimidos desperdicia CPU y a menudo hace los archivos ligeramente más grandes. Imágenes (JPEG, PNG, WebP, AVIF), vídeo y audio, fuentes en WOFF2, archivos ZIP, PDFs con imágenes incrustadas — sus formatos ya exprimieron la redundancia. No queda nada que Gzip o Brotli puedan encontrar.
Por eso la compresión se configura por tipo de contenido, y por eso una regla general de "comprímelo todo" es un error pequeño pero real. El reparto práctico: tipos de texto activados (HTML, CSS, JS, JSON, XML, SVG), medios binarios desactivados. SVG es el único formato de imagen que pertenece a la columna de texto — es XML, y se comprime de maravilla.
Dónde debería ejecutarse: en el edge, no en tu servidor de aplicación
La compresión cuesta CPU en cada respuesta, y cuanto más abajo en la cadena se ejecuta, menos veces se ejecuta. Cuando comprime el edge, una página cacheada se comprime una vez y esa copia comprimida es la que se sirve desde la caché miles de veces — tu origen no gasta nada, y el edge almacena cada variante que el cliente puede aceptar.
En cdn.com.tr esto es un ajuste por regla de entrega: cada regla lleva una lista de compresión (gzip, zip, brotli) que activas desde el panel, junto a las opciones de caché y optimización de esa misma regla. Activar Brotli es una casilla, no una migración de servidor — y como vive en la regla, puedes comprimir tus páginas con fuerza mientras dejas en paz la regla de tus medios ya comprimidos, que es exactamente el reparto que defendía la sección anterior.
Verifica lo que envías de verdad
Las suposiciones sobre compresión fallan con la frecuencia suficiente como para que la comprobación merezca treinta segundos. Pide una página dos veces con ofertas distintas de Accept-Encoding y lee el Content-Encoding que vuelve. Ya que estás, compara los tamaños transferidos — la diferencia es tu ahorro, medido en lugar de creído.
Una advertencia al probar a través de una CDN: el edge puede haber cacheado la variante de una petición anterior, así que usa un query string rompe-caché para ver el comportamiento fresco, y recuerda que una copia comprimida en caché respondiendo al instante es precisamente el objetivo.
Dos peticiones, dos ofertas — lee lo que vuelve
# what does the server send when offered brotli?
curl -sI -H 'Accept-Encoding: br' https://example.com/ | grep -i content-encoding
# and when offered only gzip?
curl -sI -H 'Accept-Encoding: gzip' https://example.com/ | grep -i content-encoding
# compare actual transferred bytes (compressed vs uncompressed)
curl -so /dev/null -H 'Accept-Encoding: br' -w 'brotli: %{size_download} bytes\n' https://example.com/
curl -so /dev/null -H 'Accept-Encoding: identity' -w 'plain: %{size_download} bytes\n' https://example.com/Preguntas frecuentes
¿Debería activar Brotli y Gzip a la vez?
Sí — esa es la configuración normal. La negociación elige Brotli para los navegadores que ofrecen br y recurre a Gzip para el resto. Activar ambos es una mejora estricta frente a cualquiera de los dos por separado.
¿La compresión ralentiza mi servidor?
Cuesta CPU, pero a los niveles usados por petición el coste es pequeño frente al ancho de banda ahorrado — y cuando el edge comprime el contenido cacheado, tu origen no paga nada en absoluto: la copia comprimida se crea una vez y se sirve desde la caché.
¿Por qué el tráfico de imágenes de mi CDN no muestra compresión?
Porque eso es lo correcto: JPEG, PNG, WebP y AVIF ya son formatos comprimidos, y recomprimirlos desperdicia CPU para una ganancia nula (a veces negativa). La compresión es para texto. Si quieres imágenes más pequeñas, la palanca es el formato y el tamaño — conversión a WebP/AVIF — no Content-Encoding.
¿Tengo que cambiar el código de mi web para usar Brotli?
No. La compresión se negocia entre navegador y servidor/edge en cada petición; tu HTML, CSS y JavaScript quedan intactos. En cdn.com.tr es un interruptor en la regla de entrega, y el edge se encarga del resto.