gzip vs Brotli: lo que vale de verdad la diferencia, y por qué un tercio de los sitios públicos sigue sin enviar nada comprimido
- vuetelemetry
- Guías
- 7 min de lectura
Brotli comprime mejor el texto que gzip, con una diferencia real pero menor de lo que sugiere el marketing. El hallazgo más importante está en otra parte: de 336 organismos públicos medidos, 107 de los que respondieron envían su página de inicio sin ninguna compresión.
La comparación suele plantearse como una elección, y para un despliegue nuevo lo es. Para la mayoría de los sitios existentes no lo es, porque la pregunta real resulta ser si se está comprimiendo algo.
Lo que medimos, y lo que cuesta
Medimos 336 organismos públicos portugueses el 6 de septiembre de 2026, una petición a cada uno, leyendo solo las cabeceras de respuesta y el tamaño del HTML transmitido. Respondieron 291. 107 de ellos, el 36,8 %, enviaban su página de inicio sin ninguna codificación de contenido.
El coste no es teórico. Entre los sitios que comprimen, la página de inicio mediana pesa 29 312 bytes transmitidos. Entre los que no comprimen, la mediana es de 109 705 bytes. Son 3,7 veces más datos para el mismo tipo de página, y dieciocho de los sitios sin comprimir superan los 200 kB solo de HTML, el más pesado con 536 245 bytes.
La comparación en sí
Ahora, la comparación en sí. gzip tiene soporte universal desde los años noventa y es la opción segura por defecto. Brotli, normalizado en 2016, lo admiten todos los navegadores actuales sobre HTTPS y suele producir un resultado más pequeño en texto, con la ganancia concentrada en HTML, CSS y JavaScript y no en formatos ya comprimidos.
- curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding
- Ninguna línea content-encoding: no se comprime nada
- content-encoding: br significa que se negoció Brotli, gzip significa el recurso alternativo
- Prueba sobre HTTPS: los navegadores no ofrecen Brotli por HTTP simple
- Limita la compresión a los tipos de texto; imágenes y vídeo no ganan nada
La forma honesta de expresar la diferencia es que Brotli gana en texto y que el margen varía con el contenido y el nivel de compresión elegido. Quien te cite un único porcentaje universal te está citando un banco de pruebas, no tu sitio. Mide el tuyo: basta una petición.
Los niveles importan más que el algoritmo
El ajuste del nivel importa más que la elección del algoritmo, y es donde vive la mayoría de los errores de configuración. Brotli ofrece niveles del 0 al 11. El nivel 11 es tan lento que usarlo en respuestas generadas dinámicamente puede costar más tiempo de servidor del que ahorra en la transferencia. Lo habitual es un nivel alto para los recursos estáticos comprimidos una vez al construir, y un nivel moderado para todo lo que se genera en cada petición.
gzip tiene la misma estructura con niveles del 1 al 9, y la misma trampa: el nivel máximo rara vez es el adecuado para contenido dinámico.
Negociación, HTTPS, y lo que no hay que comprimir
La negociación de contenido decide cuál se usa, y no depende solo de ti. El navegador envía `Accept-Encoding: gzip, deflate, br` y el servidor elige. Configurar ambos significa que los clientes modernos reciben Brotli y todo lo demás recurre a gzip, por eso no es realmente una elección excluyente.
Un detalle práctico que confunde a menudo: los navegadores solo ofrecen Brotli sobre HTTPS. Un sitio probado por HTTP simple parecerá no admitir Brotli aunque sí lo haga.
Comprimir formatos ya comprimidos es trabajo perdido. JPEG, PNG, WebP, MP4 y la mayoría de los formatos de fuentes no ganan nada y consumen CPU. Limita la compresión a los tipos MIME de texto, que es lo predeterminado en la mayoría de las configuraciones razonables y lo primero que hay que comprobar en las que no lo son.
Comprueba tu sitio en una petición
Comprobar tu propio sitio cabe en un comando, y es el mismo que lanzamos 336 veces:
FAQ
¿Brotli es siempre mejor que gzip?
En texto, Brotli suele producir un resultado más pequeño que gzip con ajustes comparables, y el margen depende del contenido y del nivel elegido. No es mejor en formatos ya comprimidos como JPEG o MP4, donde ninguno de los dos algoritmos ayuda. Configurar ambos es la respuesta normal, ya que el navegador negocia cuál recibe.
¿Cómo compruebo si mi sitio comprime algo?
Envía una petición con una cabecera Accept-Encoding y lee la respuesta: curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding. Si no vuelve ninguna línea content-encoding, no se comprime nada.
¿Por qué mi sitio no usa Brotli si el servidor lo admite?
La razón más frecuente es que probaste por HTTP simple. Los navegadores solo anuncian Brotli sobre HTTPS, así que una prueba por HTTP hace que un servidor bien configurado parezca no admitirlo. La segunda razón más frecuente es que el módulo de compresión está activado pero limitado a una lista de tipos MIME que no incluye tu tipo de contenido.
¿Debo usar el nivel de compresión máximo?
Para recursos estáticos comprimidos una vez al construir, un nivel alto es razonable porque el coste se paga una sola vez. Para respuestas generadas en cada petición, los niveles más altos pueden costar más tiempo de servidor que la transferencia que ahorran. Un nivel moderado para el contenido dinámico y uno alto para los archivos estáticos es lo habitual.
¿Cuánto cuesta de verdad no comprimir?
En nuestra medición de 291 organismos públicos que respondieron el 6 de septiembre de 2026, la página de inicio mediana pesaba 29 312 bytes transmitidos con la compresión activa y 109 705 bytes sin ella, un factor de 3,7 para páginas comparables. Dieciocho sitios sin comprimir superaban los 200 kB solo de HTML.
**Comprimir formatos ya comprimidos es trabajo perdido.** JPEG, PNG, WebP, MP4 y la mayoría de los formatos de fuentes no ganan nada y consumen CPU. Limita la compresión a los tipos MIME de texto, que es lo predeterminado en la mayoría de las configuraciones razonables y lo primero que hay que comprobar en las que no lo son.