[WP] Compresión Gzip vs Brotli: diferencias entre los dos algoritmos de compresión
Para que un sitio web, incluidos los hechos con el CMS WordPress, sea más rápido, conviene configurar la compresión de datos en el servidor. Así los datos que viajan entre el servidor web y el navegador cargan más rápido y todo el sitio gana velocidad. Es uno de los factores que más tienen en cuenta los administradores de sitios web. La compresión gzip está muy extendida, y en muchos servidores web se está pasando poco a poco de gzip a Brotli como método de compresión, una tendencia en aumento.
1️⃣ ¿Qué es la compresión?
Sitio URL: al abrirla, empieza una conversación entre el navegador y el servidor. En ese momento el navegador le indica al servidor si puede deshacer la compresión del contenido (Compression) y qué algoritmos de compresión usa. Así, cuando el servidor envía datos comprimidos, el navegador puede descomprimirlos correctamente. Por eso, con un servidor y un navegador compatibles con algoritmos de compresión, tu sitio web carga aún más rápido.
Cuando un navegador se conecta a un servidor, envía cabeceras como la compresión gzip o Brotli. El navegador recibe los datos comprimidos con uno de los dos, y los datos comprimidos cargan más rápido que los no comprimidos.
Content-encoding: gzip
Content-encoding: br
Comprobar la compresión Gzip 
Comprobar la compresión Brotli
Los archivos que se comprimen son sobre todo de texto: · HTML · CSS · JavaScript
2️⃣ ¿Qué es la compresión Gzip?
Los algoritmos de compresión más usados por los proveedores de hosting son Gzip y Brotli. La beta de Gzip salió en 1992 y la versión 1.0 se publicó en 1993. En general, Gzip es uno de los métodos estándar para comprimir datos al enviarlos por internet. Se basa en DEFLATE, uno de los primeros algoritmos de compresión, y toma su nombre de gzip, un programa de compresión de archivos creado antes para Unix.
DEFLATE combina el algoritmo LZ77 (Lempel-Ziv 1977) con la codificación Huffman. LZ77 busca datos repetidos, encuentra cadenas coincidentes y las sustituye por códigos. La codificación Huffman usa la frecuencia de cada carácter para asignar los códigos de bits más cortos.
Gzip comprime los datos con DEFLATE y, mediante la cabecera ‘Accept-Encoding: gzip’ de las peticiones y respuestas HTTP, solo comprime cuando el cliente es compatible con Gzip. Esa compresión ayuda a que el sitio web cargue más rápido.
3️⃣ ¿Qué es la compresión Brotli?
Brotli lo desarrollaron en 2013 Jyrki Alakuijala y Zoltán Szabadka, empleados de Google.
Gzip nació para comprimir archivos, pero se adaptó para usarse también en la web. Brotli, en cambio, se desarrolló pensando en la web. Por eso, con Brotli el servidor web puede comprimir el contenido antes de enviarlo al navegador. Como se comprime antes de transmitirse al navegador, es un método mejor y más avanzado.
Brotli usa las mismas dos técnicas básicas que la compresión GZIP: LZ77 y la codificación Huffman.
4️⃣ Compresión Gzip vs. compresión Brotli
Gzip comprime (& descomprime) los datos con el método DEFLATE, y Brotli, con un formato propio que añade modelado de contexto a LZ77 y la codificación Huffman.
- Gzip comprime más rápido que Brotli.
- Brotli se diseñó específicamente para la web.
- Brotli ofrece una mejor tasa de compresión (es decir, archivos comprimidos más pequeños) en todos los niveles.
- Frente a Gzip, Brotli comprime mejor estos tres tipos de archivo: un 21% en HTML, un 17% en CSS y un 14% en JavaScript.
Cada vez más servidores web prefieren Brotli a Gzip. Como Brotli está diseñado para comprimir flujos al vuelo, se dice que su descompresión en el frontend es hasta un 64% más rápida que la de Gzip.
El RFC 1952, publicado en mayo de 1996, explica que el formato Gzip usa el método de compresión DEFLATE e incluye un valor CRC para detectar datos dañados. Al final de los datos comprimidos se guardan el valor CRC-32 y el tamaño de los datos originales.
El RFC 7932, publicado en julio de 2016, indica que Brotli comprime combinando el algoritmo LZ77 con la codificación Huffman. Además, usa como contexto los dos bytes anteriores de los datos sin comprimir para elegir los códigos Huffman y, en lugar de cadenas repetidas, también puede remitir a palabras de un diccionario estático de 122.784 bytes.
Los dos formatos aparecen en la cabecera de respuesta como [Content-Encoding: gzip] y [Content-Encoding: br]. El valor [br] se registró como codificación de contenido HTTP en el RFC 7932.
| Categoría | Gzip | Brotli |
|---|---|---|
| Especificación | RFC 1952 · mayo de 1996 | RFC 7932 · julio de 2016 |
| Método de compresión | DEFLATE (LZ77 y codificación Huffman) | LZ77 y codificación Huffman · contexto de los dos bytes anteriores · diccionario estático de 122.784 bytes |
| Cabecera de respuesta | Content-Encoding: gzip | Content-Encoding: br |
5️⃣ Medición de la compresión Gzip y Brotli: un servidor Nginx + Apache
En un servidor WordPress que usa Nginx y Apache a la vez, se compararon las respuestas de una misma entrada, del archivo CSS de bloques predeterminado de WordPress y del archivo de jQuery cambiando solo la cabecera de la petición. Desde el mismo servidor se enviaron con curl peticiones con solo gzip en [Accept-Encoding], con solo br y sin la cabecera.
for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833El HTML de una entrada se comprimió a 21.390 bytes con la petición gzip y a 20.190 bytes con la petición br, y la petición sin cabecera recibió los 90.833 bytes sin comprimir. La respuesta br fue 1.200 bytes (5,6%) más pequeña que la de gzip.
for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553Con la petición gzip, el archivo CSS se comprimió a 19.655 bytes y el de jQuery a 30.633 bytes. Al pedir solo br o sin cabecera, el servidor envió los originales de 140.829 bytes y 87.553 bytes tal cual, sin la cabecera [Content-Encoding].
nginx -V 2>&1 | grep -c brotli0httpd -M 2>/dev/null | grep -E 'brotli|deflate' deflate_module (shared)
brotli_module (shared)Los archivos estáticos como CSS y JS los sirve y comprime directamente Nginx, y como el Nginx de esta configuración no tiene el módulo Brotli, solo comprime con gzip.
En el caso del HTML, WordPress responde a la petición que Nginx pasa a Apache, y Apache la comprime. Apache tiene tanto el módulo Brotli como el módulo [mod_deflate], que se encarga de la compresión Gzip.
for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633Que el servidor tenga el módulo Brotli no significa que el navegador reciba respuestas comprimidas con Brotli. Al pedir con [gzip, deflate, br, zstd], el mismo valor que envía Edge 155, Apache también comprimió el HTML con gzip, y los tres archivos llegaron en gzip.
Aunque br se pusiera antes que gzip o se marcara como preferido, como en [br;q=1.0, gzip;q=0.5], el HTML llegó en gzip. Al abrir en Edge la misma entrada y los dos archivos, también se transfirieron todos en gzip.
El tiempo hasta el primer byte es la mediana de los valores [time_starttransfer] de curl, medidos 40 veces cada uno con las peticiones en orden aleatorio; cada petición abrió una conexión nueva, así que incluye el tiempo de conexión TLS. En el HTML, la respuesta sin comprimir tardó 22,7 ms, gzip 26,3 ms, br 26,5 ms y la petición igual a la de un navegador 25,0 ms. CSS y JS tardaron entre 18 y 21 ms, con o sin compresión.
La velocidad de compresión de Gzip y Brotli no se midió aquí, sino que se comparó con fuentes públicas. El RFC 7932 indica que Brotli comprime con una tasa de compresión bastante mayor que el programa gzip y descomprime mucho más rápido que las implementaciones actuales de LZMA. Google explica en el repositorio de Brotli que su velocidad es similar a la de deflate, pero que comprime de forma más densa.
En 2015, Cloudflare probó los dos métodos con 10.655 archivos HTML, CSS y JavaScript. Con la máxima calidad, el resultado de Brotli fue de media 1,19 veces más pequeño que el de zlib en su máxima calidad, pero comprimía a 0,5 MB por segundo, mucho más despacio que los 41,9 MB de zlib en el nivel 9. Brotli en el nivel 4 tuvo una tasa de compresión similar a la de zlib en el nivel 8 y, en el promedio general, fue algo más rápido, pero con solo los archivos de menos de 64 KB era 1,48 veces más lento.
Hemos visto cómo optimizar un sitio web comprimiendo archivos como HTML, CSS y JavaScript. Para mejorar la velocidad de un sitio web, la compresión de archivos y la Optimización de imágenes son elementos esenciales.
🔢 FAQ & contenido recomendado
ℹ️ Aviso de afiliados
El contenido de este sitio incluye enlaces de afiliado. Cuando un visitante compra un producto o servicio a través de uno de ellos, el sitio recibe una comisión del vendedor. El importe que paga el comprador(baja durante las promociones ↓)no aumenta. Los precios, descuentos y existencias publicados corresponden al momento de redacción y pueden variar, así que confírmalos con el vendedor antes de comprar. Los productos se eligen y evalúan con criterios propios, y las comisiones no influyen en el orden ni en el contenido de las reseñas.