[WP] Compressão Gzip vs Brotli: a diferença entre os dois algoritmos de compressão
Para deixar sites mais rápidos, incluindo os feitos com o CMS WordPress, vale configurar a compressão de dados no servidor. Assim, os dados trocados entre o servidor web e o navegador carregam mais rápido e o site todo fica mais veloz. É um dos fatores que os administradores de sites mais consideram. A compressão gzip é muito usada, e em muitos servidores web há uma migração crescente do gzip para a compressão Brotli .
1️⃣ O que é compressão?
Site URL: ao abri-la, começa uma conversa entre navegador e servidor. Nesse momento o navegador informa ao servidor se consegue desfazer a compressão do conteúdo (Compression) e quais algoritmos de compressão usa. Isso ajuda o navegador a descomprimir os dados corretamente quando o servidor os envia comprimidos. Então, com servidor e navegador que suportam algoritmos de compressão, seu site carrega ainda mais rápido.
Quando um navegador se conecta a um servidor, ele envia cabeçalhos como compressão gzip ou Brotli. Os dados comprimidos com um dos dois chegam ao navegador, e dados comprimidos carregam mais rápido que dados sem compressão.
Content-encoding: gzip
Content-encoding: br
Verificar a compressão Gzip 
Verificar a compressão Brotli
Os arquivos comprimidos são principalmente texto: · HTML · CSS · JavaScript
2️⃣ O que é a compressão Gzip?
Os algoritmos de compressão mais usados pelas hospedagens são Gzip e Brotli. O beta do Gzip saiu em 1992, e a versão 1.0 foi lançada em 1993. Em geral, o Gzip é um dos métodos padrão para comprimir dados enviados pela internet. Ele se baseia no DEFLATE, um dos primeiros algoritmos de compressão, e herdou o nome do gzip, programa de compressão de arquivos criado antes para Unix.
O DEFLATE combina o algoritmo LZ77 (Lempel-Ziv 1977) com a codificação de Huffman. O LZ77 procura dados repetidos, encontra sequências iguais e as substitui por códigos. A codificação de Huffman usa a frequência de cada caractere para atribuir os códigos de bits mais curtos.
O Gzip comprime dados com DEFLATE e, usando o cabeçalho ‘Accept-Encoding: gzip’ em requisições e respostas HTTP, só comprime quando o cliente suporta Gzip. Essa compressão ajuda os sites a carregar mais rápido.
3️⃣ O que é a compressão Brotli?
O Brotli foi desenvolvido em 2013 pelos engenheiros do Google Jyrki Alakuijala e Zoltán Szabadka.
O Gzip foi pensado originalmente para comprimir arquivos, mas foi adaptado para uso na web. Já o Brotli foi desenvolvido desde o início para a web. Assim, com o Brotli o servidor web pode comprimir o conteúdo antes de enviá-lo ao navegador. Como é comprimido antes de ser transmitido ao navegador, é uma abordagem melhor e mais avançada.
O Brotli usa as mesmas duas técnicas centrais da compressão GZIP: LZ77 e codificação de Huffman.
4️⃣ Compressão Gzip vs compressão Brotli
O Gzip comprime (e descomprime) dados com o método DEFLATE, enquanto o Brotli usa um formato próprio, que acrescenta modelagem de contexto ao LZ77 e à codificação de Huffman.
- O Gzip comprime mais rápido que o Brotli.
- O Brotli foi projetado especificamente para a web.
- O Brotli oferece uma taxa de compressão melhor (ou seja, arquivos comprimidos menores) em todos os níveis.
- Comparado ao Gzip, o Brotli comprime melhor estes três tipos de arquivo: 21% no HTML, 17% no CSS e 14% no JavaScript.
Cada vez mais servidores web preferem o Brotli ao Gzip. Como o Brotli foi feito para comprimir fluxos na hora, a descompressão no front-end seria até 64% mais rápida que a do Gzip.
A RFC 1952, publicada em maio de 1996, explica que o formato Gzip usa o método de compressão DEFLATE e inclui um valor CRC para detectar dados corrompidos. O valor CRC-32 e o tamanho dos dados originais ficam no fim dos dados comprimidos.
A RFC 7932, publicada em julho de 2016, diz que o Brotli comprime combinando o algoritmo LZ77 com a codificação de Huffman. Além disso, usa os dois bytes anteriores dos dados sem compressão como contexto para escolher os códigos de Huffman e, em vez de sequências repetidas, pode se referir a palavras de um dicionário estático de 122.784 bytes.
Os dois formatos aparecem no cabeçalho de resposta como [Content-Encoding: gzip] e [Content-Encoding: br]. O valor [br] foi registrado como codificação de conteúdo HTTP na RFC 7932.
| Item | Gzip | Brotli |
|---|---|---|
| Especificação | RFC 1952 · maio de 1996 | RFC 7932 · julho de 2016 |
| Método de compressão | DEFLATE (LZ77 e codificação de Huffman) | LZ77 e codificação de Huffman · contexto dos dois bytes anteriores · dicionário estático de 122.784 bytes |
| Cabeçalho de resposta | Content-Encoding: gzip | Content-Encoding: br |
5️⃣ Compressão Gzip e Brotli medida: um servidor Nginx + Apache
Num servidor WordPress com Nginx e Apache juntos, comparei as respostas de um post, do arquivo CSS padrão de blocos do WordPress e do arquivo jQuery, mudando só o cabeçalho da requisição. Requisições com só gzip em [Accept-Encoding], só br e sem cabeçalho foram enviadas com curl do mesmo servidor.
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: 90833O HTML de um post foi comprimido para 21.390 bytes na requisição gzip e para 20.190 bytes na br, e a requisição sem cabeçalho recebeu os 90.833 bytes sem compressão. A resposta br foi 1.200 bytes (5,6%) menor que a 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: 87553Na requisição gzip, o arquivo CSS foi comprimido para 19.655 bytes e o jQuery para 30.633 bytes. Com só br ou sem cabeçalho, o servidor devolveu os originais de 140.829 e 87.553 bytes como estavam, sem cabeçalho [Content-Encoding].
nginx -V 2>&1 | grep -c brotli0httpd -M 2>/dev/null | grep -E 'brotli|deflate' deflate_module (shared)
brotli_module (shared)Arquivos estáticos como CSS e JS são entregues e comprimidos diretamente pelo Nginx, e como o Nginx desta configuração não tem módulo Brotli, ele só comprime com gzip.
No HTML, o WordPress responde à requisição que o Nginx repassa ao Apache, e o Apache comprime. O Apache tem tanto o módulo Brotli quanto o módulo [mod_deflate], que cuida da compressão 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: 30633Ter um módulo Brotli no servidor não significa que o navegador receba respostas comprimidas com Brotli. Com a requisição [gzip, deflate, br, zstd], o mesmo valor que o Edge 155 envia, o Apache também comprimiu o HTML com gzip, e os três arquivos voltaram em gzip.
Mesmo colocando br antes de gzip ou marcando-o como preferido, como em [br;q=1.0, gzip;q=0.5], o HTML voltou em gzip. Abrindo o mesmo post e os dois arquivos no Edge, todos também vieram em gzip.
O tempo até o primeiro byte é a mediana dos valores [time_starttransfer] do curl, medidos 40 vezes cada com a ordem embaralhada; cada requisição abriu uma conexão nova, então o tempo de conexão TLS está incluído. No HTML, a resposta sem compressão levou 22,7 ms, gzip 26,3 ms, br 26,5 ms e a requisição tipo navegador 25,0 ms. CSS e JS levaram 18–21 ms, com ou sem compressão.
A velocidade de compressão do Gzip e do Brotli não foi medida aqui, mas comparada com fontes públicas. A RFC 7932 diz que o Brotli comprime com taxa bem maior que o programa gzip e descomprime muito mais rápido que as implementações atuais de LZMA. No repositório do Brotli, o Google explica que ele tem velocidade parecida com o deflate, mas comprime de forma mais densa.
Em 2015, a Cloudflare testou os dois métodos em 10.655 arquivos HTML, CSS e JavaScript. O Brotli na qualidade máxima gerou resultados em média 1,19 vez menores que o zlib na qualidade máxima, mas comprimiu a 0,5 MB por segundo, bem mais lento que os 41,9 MB do zlib nível 9. O Brotli nível 4 teve taxa parecida com a do zlib nível 8 e foi um pouco mais rápido na média geral, mas 1,48 vez mais lento olhando só arquivos menores que 64 KB.
Vimos como otimizar um site comprimindo arquivos como HTML, CSS e JavaScript. Para acelerar um site, a compressão de arquivos e a Otimizar Imagens são essenciais.
🔢 FAQ & conteúdo recomendado
ℹ️ Aviso de afiliados
O conteúdo deste site contém links de afiliados. Quando um visitante compra um produto ou serviço por meio de um desses links, o site recebe uma comissão do vendedor. O valor que o comprador paga (em promoções, ele diminui ↓) não aumenta por causa disso. Preços, descontos e informações de estoque valem para o momento em que o texto foi escrito e podem ter mudado, por isso confirme com o vendedor antes de comprar. Os produtos são escolhidos e avaliados por critérios próprios, e o recebimento de comissão não influencia a ordem de apresentação nem o conteúdo das avaliações.