Cómo usar Brotli y Gzip para optimizar streaming y descargas

Si quieres que tu web, tus APIs, descargas y streaming vuelen incluso en conexiones cutres de móvil, uno de los trucos más potentes (y más infravalorados) es la compresión HTTP. Bien usada, la combinación de Brotli y Gzip reduce de forma brutal el tamaño de las respuestas sin que se pierda ni un solo bit de información. Eso se traduce en menos ancho de banda, servidores menos cargados y usuarios con la sensación de que “esto carga al instante”.

En las siguientes líneas vamos a profundizar a fondo en cómo funcionan Gzip y Brotli, en qué se diferencian, cómo elegir niveles de compresión razonables, cómo activarlos en Apache, Nginx, LiteSpeed, Cloudflare, WordPress y en APIs REST, y cómo comprobar que todo está bien configurado. La idea es que acabes con una guía completa para exprimir ambas tecnologías tanto en webs clásicas como en servicios de streaming y sistemas de descargas.

Qué son Gzip y Brotli y por qué importan tanto

Gzip es el veterano de la casa: un formato de compresión basado en el algoritmo DEFLATE, que a su vez combina LZ77 y codificación de Huffman. Lleva desde principios de los 90 acelerando la web y hoy tiene un soporte prácticamente universal en navegadores, servidores y clientes HTTP de todo tipo.

Brotli, creado por Google, también se apoya en ideas similares (LZ77 + Huffman), pero introduce mejoras clave, como el uso de diccionarios estáticos y dinámicos muy optimizados para contenido web (HTML, CSS, JS, JSON, etc.). El resultado es que suele lograr ratios de compresión entre un 20 % y un 30 % mejores que Gzip en muchos archivos de texto.

En la práctica, ambos algoritmos se usan para que el servidor coja los recursos de texto (HTML, CSS, JavaScript, JSON de APIs, XML, fuentes, etc.), los comprima y los envíe al navegador o al cliente. Este, de forma transparente para el usuario, descomprime la respuesta y la procesa normalmente. El usuario solo ve que todo carga antes y consume menos datos.

Un detalle importante: mientras que Gzip se puede usar tanto en HTTP como en HTTPS, la compresión Brotli en la web se usa de facto sobre HTTPS. La buena noticia es que hoy en día prácticamente cualquier proyecto mínimamente serio ya funciona bajo SSL/TLS, así que no suele ser un problema.

Brotli vs Gzip: diferencias reales de rendimiento

Cuando se compara Brotli con Gzip, lo primero que suele mirarse es la tasa de compresión. Hay pruebas públicas que demuestran que, para HTML, CSS, JS o JSON, Brotli puede reducir varios kilobytes adicionales respecto a Gzip a igualdad de condiciones. Por ejemplo, para un HTML sin comprimir de unos 418 kB, se han medido resultados como estos:

• Gzip nivel 9: archivo final de unos 78,7 kB.
• Brotli nivel 11: archivo final de unos 57,2 kB.

La diferencia parece espectacular, pero hay truco: los niveles máximos de compresión de Brotli (10-11) implican más CPU y más tiempo de compresión, lo cual no siempre compensa, sobre todo para contenido dinámico generado al vuelo.

Si igualamos mejor la balanza, por ejemplo comparando Gzip nivel 9 con Brotli nivel 3, el mismo HTML de 418 kB puede quedar en:

• Gzip nivel 9: 78,7 kB.
• Brotli nivel 3: 76,5 kB.

En esa situación, el tamaño es prácticamente el mismo, pero Brotli a nivel 3 comprime y descomprime mucho más rápido y con menos consumo de recursos que Gzip a nivel 9. De ahí que se recomiende usar niveles medios de Brotli (entre 3 y 6) para contenido dinámico y reservar los niveles más altos para precompresión de estáticos (CSS, JS, fuentes, etc.).

En benchmarks independientes se suele ver un patrón parecido: Brotli gana casi siempre en ratio de compresión, mientras que Gzip es algo más rápido en algunos escenarios, especialmente cuando se usan niveles bajos y cuando se trata de comprimir en tiempo real muchos recursos pequeños.

Para APIs, streaming de texto o grandes descargas JSON, la clave está en medir: a veces reducir un 15-20 % adicional el tamaño de la respuesta merece sobradamente el coste extra de CPU, sobre todo si tienes una infraestructura bien dimensionada o si usas CDN con compresión en el edge.

Cómo negocian el cliente y el servidor: Accept-Encoding y Content-Encoding

La compresión HTTP, tanto en webs como en APIs REST o servicios de streaming de datos, se basa en una negociación vía cabeceras. El cliente anuncia qué algoritmos entiende en la cabecera Accept-Encoding (por ejemplo gzip, br) y el servidor responde indicando lo que ha aplicado en la cabecera Content-Encoding.

Un flujo típico de una API sería algo así: el cliente envía Accept-Encoding: gzip, br, el servidor detecta que puede usar Brotli y devuelve Content-Encoding: br. Si el cliente solo entiende Gzip, se usa Content-Encoding: gzip. Si no hay ningún algoritmo en común, el servidor podría responder con un 406 Not Acceptable, aunque lo más habitual es simplemente enviar la respuesta sin comprimir.

Cuando hay varios algoritmos encadenados (caso más raro, pero permitido por la especificación), la cabecera Content-Encoding lista los métodos en orden, para que el cliente pueda descomprimir en el orden inverso. Además, para cachés intermedias como proxies o CDNs, es esencial enviar Vary: Accept-Encoding para que almacenen variantes comprimidas y sin comprimir de un mismo recurso.

En dispositivos con pocos recursos (móviles antiguos, IoT, etc.) hay que tener en cuenta que la descompresión también consume CPU y memoria. En la mayoría de navegadores modernos esto no es problema, pero si desarrollas un cliente específico, conviene establecer umbrales mínimos de tamaño (no tiene sentido comprimir una respuesta JSON de 200 bytes) y elegir bien qué algoritmos vas a soportar.

Arquitectura interna de Brotli: diccionarios y ventana deslizante

Uno de los motivos por los que Brotli consigue archivos más pequeños que Gzip es el uso intensivo de diccionarios de datos. Emplea dos tipos: un diccionario estático y otro dinámico (ventana deslizante), que trabajan juntos para encontrar patrones repetidos y codificarlos de forma muy eficiente.

El diccionario estático incluye más de 13 000 palabras y fragmentos frecuentes en HTML, CSS, JavaScript y texto general, en varios idiomas. Gracias a él, Brotli no necesita analizar byte a byte todo el flujo, sino que puede apoyarse en referencias ya conocidas, un poco como cuando un sistema de plantillas hace referencia a un bloque de código reutilizable.

Dentro de ese diccionario también hay frases parciales y transformaciones: trozos que con un prefijo o sufijo pueden formar palabras nuevas. Así, se ahorra espacio no solo en palabras completas, sino también en combinaciones típicas como etiquetas HTML (<html>, type="text/javascript", etc.).

El diccionario dinámico (la llamada “ventana deslizante”) analiza los datos recientes del flujo, guardándolos en una especie de caché que el algoritmo puede reutilizar. En Brotli esta ventana puede llegar a los 16 MB, mucho mayor que los ~32 KB típicos de Gzip, lo que da muchísimo juego para encontrar patrones en archivos grandes o en streams de datos extensos.

Esta combinación le permite a Brotli brillar especialmente en recursos estáticos grandes (CSS, JS concatenados, bundles modernos, JSON voluminosos para SPA, etc.) y en contenido HTML con muchas repeticiones de estructura.

Compatibilidad de Brotli y Gzip con navegadores, servidores y CDN

Por el lado del cliente, la situación es muy favorable: según recopilaciones tipo Can I use, más del 95 % de los navegadores en uso soportan ya Brotli, incluidos prácticamente todos los basados en Chromium, Firefox y los principales navegadores móviles. Gzip, por su parte, es universal desde hace muchos años.

En el lado del servidor, el panorama es algo más variado. Gzip está disponible de serie en casi cualquier stack (Apache, Nginx, IIS, etc.), mientras que Brotli requiere en algunos casos disponer de módulos o compilaciones específicas:

• Apache: necesitas al menos Apache 2.4 con mod_brotli instalado y habilitado.
• Nginx: suele activarse a partir de versiones recientes (1.18+), a menudo mediante el módulo ngx_brotli, ya sea compilado en el binario o como módulo dinámico.
• LiteSpeed Web Server: trae Brotli activado por defecto desde hace años, sin necesidad de cambios manuales.
• CDN como Cloudflare, KeyCDN, CDN77, Amazon CloudFront, etc., ofrecen soporte para Brotli de forma nativa o mediante opciones de configuración muy sencillas.

Muchos hostings compartidos todavía usan Apache sin mod_brotli o Nginx sin el módulo correspondiente, así que antes de pelearte con configuraciones conviene confirmar con tu proveedor qué está disponible y qué no. En algunos casos, activar Brotli será tan simple como marcar una casilla en el panel de control o en la consola de la CDN.

Activar Gzip en servidores web (Apache y Nginx)

Gzip sigue siendo imprescindible, no solo por compatibilidad con navegadores y clientes antiguos, sino también como respaldo cuando Brotli no está disponible en toda la cadena (servidor de origen, CDN, proxies, etc.). Activarlo suele ser muy directo.

En Apache, lo habitual es utilizar el módulo mod_deflate y declarar los tipos MIME que quieres comprimir. Un ejemplo típico en .htaccess sería:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
  AddOutputFilterByType DEFLATE text/javascript application/javascript
  AddOutputFilterByType DEFLATE application/json application/xml
  AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
  AddOutputFilterByType DEFLATE font/ttf font/otf font/woff font/woff2
</IfModule>

En Nginx, se activa con unas pocas directivas dentro del bloque http del nginx.conf:

gzip on;
gzip_comp_level 2;
gzip_min_length 1100;
gzip_types text/plain text/html text/css text/xml
           application/json application/javascript text/javascript
           application/xml application/xml+rss image/svg+xml;
gzip_vary on;

A partir de ahí, cualquier navegador que envíe Accept-Encoding: gzip recibirá el contenido comprimido, y el resto lo recibirá en claro. Es importante no forzar la compresión sobre archivos ya comprimidos (JPEG, PNG, MP4, ZIP, PDF, etc.), porque la ganancia suele ser mínima y sí se paga un coste de CPU innecesario.

Activar Brotli en Apache, Nginx y LiteSpeed

Para aprovechar Brotli en tu servidor necesitas que el software soporte mod_brotli o módulos equivalentes. Una vez confirmado, basta con habilitarlo y marcar qué tipos de archivo quieres comprimir.

En Apache 2.4+ con mod_brotli instalado, un bloque muy típico sería:

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json application/xml
  AddOutputFilterByType BROTLI_COMPRESS application/x-font-ttf
  AddOutputFilterByType BROTLI_COMPRESS application/vnd.ms-fontobject
  AddOutputFilterByType BROTLI_COMPRESS image/x-icon
</IfModule>

En Nginx con ngx_brotli, suele bastar con algo como esto en nginx.conf:

brotli on;
brotli_comp_level 4;  # niveles 3-6 son buena opción general
brotli_static on;      # sirve .br precomprimidos si existen
brotli_types text/plain text/css application/json application/javascript
             text/xml application/xml application/xml+rss text/javascript
             image/svg+xml;

En entornos donde se precomprimen los recursos (por ejemplo, durante un pipeline de CI/CD que genera .br y .gz), brotli_static on indica a Nginx que sirva esos archivos directamente, en lugar de comprimir cada vez sobre la marcha, ahorrando mucha CPU.

En LiteSpeed Web Server, la buena noticia es que Brotli viene activado por defecto en instalaciones típicas con cPanel y en muchos planes de hosting gestionado. En este caso, prácticamente no hay que tocar nada: el servidor ya decidirá cuándo usar Brotli o Gzip según lo que anuncie el cliente.

Uso de Brotli y Gzip en CDN y redes de entrega de contenido

Si utilizas una CDN moderna, es muy probable que ya tengas acceso a compresión Brotli sin complicarte demasiado. Cloudflare, por ejemplo, fue uno de los primeros en soportarla y hoy la usa en toda su infraestructura, con una implementación muy optimizada.

Durante años, Cloudflare solo pedía Gzip al origen, descomprimía y volvía a comprimir usando Brotli nivel 4 o Gzip nivel 8 antes de devolverlo al usuario. Ahora, con soporte de Brotli de extremo a extremo, Cloudflare puede solicitar directamente contenido Brotli al origen (hasta nivel 11 si lo configuras así) y cachearlo tal cual, sin recomprimir. Eso significa menos latencia y menos consumo de ancho de banda entre origen y edge.

Si tu origen soporta Brotli, puedes configurar, por ejemplo con Nginx, algo como:

brotli on;
brotli_comp_level 11;
brotli_static on;
brotli_types text/plain text/css application/javascript application/x-javascript
             text/xml application/xml application/xml+rss text/javascript
             image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;

Con esa configuración, los activos coincidentes se entregarán extremadamente comprimidos a Cloudflare, que a su vez podrá servirlos directamente a los usuarios compatibles. Para navegadores sin soporte Brotli, la CDN se encargará de descomprimir y reenviar en Gzip o sin compresión según proceda.

Otras CDN como KeyCDN, CDN77 o Amazon CloudFront ofrecen también Brotli. En algunos casos basta marcar una opción en el panel; en otros hay que jugar con cabeceras como Accept-Encoding o desactivar la compresión automática de la propia CDN para no interferir con lo ya comprimido en origen.

Cómo integrar Brotli y Gzip en WordPress y otros CMS

En WordPress, la activación de la compresión no depende del propio CMS, sino del servidor web (Apache, Nginx, LiteSpeed, etc.) o de la CDN que tengas delante. Los plugins solo pueden ayudar a modificar la configuración del servidor cuando éste lo permite.

Muchos plugins de caché como W3 Total Cache, WP Rocket o LiteSpeed Cache ofrecen opciones para activar Gzip y, a veces, Brotli. En Apache, lo que hacen realmente es escribir o modificar las reglas de .htaccess para activar mod_deflate o mod_brotli. Si el módulo no está instalado en el servidor, el plugin no podrá hacer magia.

En Nginx, como no hay .htaccess, estos plugins no pueden actuar directamente sobre la compresión. Tendrás que editar los archivos de configuración (o pedir a tu proveedor que lo haga) para añadir las directivas gzip y brotli correspondientes, y luego recargar Nginx.

Hay hostings administrados (por ejemplo, algunos basados en Cloudflare integrado) que activan Brotli automáticamente para todos los sitios sin necesidad de plugins. En esos casos, añadir otro plugin de compresión suele ser redundante e incluso contraproducente, porque puede provocar doble compresión o conflictos con el proxy inverso.

Compresión Brotli y Gzip en APIs REST, streaming y descargas

Más allá de las webs clásicas, Brotli y Gzip son fundamentales para APIs REST, servicios de streaming de datos y descargas de ficheros. En estos entornos, reducir el tamaño del payload impacta directamente en latencia, coste de ancho de banda y experiencia de usuario.

En una API, lo normal es comprimir formatos de texto como application/json, application/xml, text/html y similares, mientras que se dejan sin comprimir formatos ya optimizados (imágenes, vídeo, ficheros ZIP, etc.). El servidor mira el header Accept-Encoding del cliente y decide si enviar la respuesta en Brotli, Gzip o sin compresión.

En servicios de streaming de texto (por ejemplo, SSE o websockets con mensajes JSON, logs en tiempo real, etc.) la compresión hay que tratarla con más cuidado. Comprimir bloques muy pequeños uno a uno puede hacer que el overhead supere al beneficio. Generalmente se configuran umbrales de tamaño para decidir a partir de qué punto se aplica la compresión.

En descargas HTTP de ficheros grandes, el planteamiento es diferente. Si el archivo ya es un ZIP, un .tar.gz o un vídeo, añadir Gzip/Brotli encima no aporta casi nada. En cambio, si entregas paquetes grandes de JSON, XML o CSV, comprimir con Brotli o Gzip puede suponer reducciones de tamaño enormes y tiempos de transferencia mucho menores para los usuarios.

Qué comprimir y qué no comprimir

Una de las buenas prácticas clave es tener muy claro qué tipos de contenido merece la pena comprimir y cuáles no. Como regla general, deberías activar Brotli y Gzip para:

• HTML y plantillas renderizadas en servidor (text/html).
• CSS y JavaScript (text/css, application/javascript, etc.).
• JSON y XML de APIs (application/json, application/xml).
• Fuentes web (TTF, OTF, WOFF, WOFF2) si tu servidor lo permite.
• SVG (image/svg+xml), que aunque es imagen, en realidad es texto.

Por el contrario, es recomendable excluir de la compresión:

• Imágenes como JPEG, PNG, WebP, AVIF, GIF.
• Vídeos (MP4, WebM, etc.).
• Archivos ZIP, RAR, 7z, .tar.gz y similares.
• PDF y otros binarios ya muy optimizados.

También es sensato definir un tamaño mínimo de respuesta (por ejemplo, 1 o 2 KB) para evitar comprimir mensajes diminutos donde apenas hay ahorro. Así, ahorras CPU y evitas añadir latencia en contenido donde la compresión no aporta nada.

Cómo comprobar si Gzip o Brotli están activos

Una vez configurada la compresión, toca verificar que realmente se está aplicando y que los headers responden a lo esperado. Hay varias formas de hacerlo, desde herramientas online hasta utilidades de línea de comandos o las DevTools del navegador.

Servicios como Gift of Speed, el test de Brotli de KeyCDN o herramientas de Paul Calvano permiten introducir una URL y ver si la respuesta llega comprimida con Gzip, Brotli o sin compresión, además del tamaño antes y después.

En el navegador, basta abrir las Herramientas de desarrollo (Network/Red), recargar la página y seleccionar un recurso (por ejemplo, el HTML principal). En el panel de cabeceras verás algo como:

• content-encoding: br si se está usando Brotli.
• content-encoding: gzip si se está usando Gzip.
• Ausencia de content-encoding si llega sin comprimir.

También puedes recurrir a curl desde la consola, forzando un Accept-Encoding concreto y revisando la respuesta:

curl -H "Accept-Encoding: br" -I https://tu-dominio.com
curl -H "Accept-Encoding: gzip" -I https://tu-dominio.com

Si ves Content-Encoding: br o Content-Encoding: gzip en la respuesta, todo está funcionando. Aprovecha también para comprobar que se envía Vary: Accept-Encoding, algo esencial para caches y CDNs.

Impacto en rendimiento, CPU y seguridad

Activar Brotli y Gzip es una de las optimizaciones con mejor relación coste/beneficio en rendimiento web y de APIs, pero conviene no olvidar sus implicaciones en recursos y seguridad.

Por el lado del rendimiento, la compresión reduce drásticamente el tamaño de los archivos, lo que se traduce en menos tiempo de descarga, mejores métricas como First Contentful Paint y Time to First Byte percibido, y un descenso directo en el consumo de ancho de banda (algo que se nota en la factura de proveedores como AWS).

El coste está en la CPU y la memoria necesarias para comprimir y descomprimir. Brotli, sobre todo en niveles altos, es más exigente que Gzip. Por eso, para contenido dinámico conviene usar niveles intermedios (3-5), y dejar los niveles extremos para precompresión de estáticos o para escenarios muy concretos.

En seguridad, la compresión puede verse afectada por ataques teóricos como BREACH, que explotan variaciones en el tamaño de las respuestas comprimidas para intentar deducir datos sensibles. Aunque son escenarios bastante específicos, es buena idea:

• Evitar comprimir respuestas muy sensibles que mezclen secretos con datos controlados por el usuario.
• Separar tokens y credenciales de cualquier entrada aportada por el cliente.
• Aplicar medidas clásicas como CSRF tokens, rate limiting y monitorización de patrones sospechosos.

Con una configuración sensata, Brotli y Gzip se convierten en aliados clave para acelerar tanto sitios web como APIs y servicios de streaming y descargas sin poner en riesgo la seguridad.

Todo este ecosistema de compresión —desde Gzip, que sigue siendo el estándar de facto, hasta Brotli, que exprime al máximo la reducción de tamaño con diccionarios avanzados y ventanas de análisis mucho mayores— te da un margen enorme para optimizar cómo viajan tus datos por la red: combinando ambos algoritmos con niveles de compresión razonables, eligiendo bien qué tipos de contenido comprimir, apoyándote en CDNs que soportan Brotli de extremo a extremo y verificando siempre las cabeceras y el impacto real en tus métricas de rendimiento, puedes conseguir que tu web, tus APIs, tus streams y tus descargas se sientan mucho más ligeros y ágiles sin tocar ni una línea de lógica de negocio.