gzip vs Brotli: quanto vale realmente a diferença, e porque um terço dos sites públicos continua a não enviar nada comprimido
- vuetelemetry
- Guias
- 7 min de leitura
O Brotli comprime texto melhor do que o gzip, com uma margem real mas menor do que o marketing sugere. A conclusão mais importante está noutro lado: de 336 organismos públicos medidos, 107 dos que responderam enviam a página inicial sem qualquer compressão.
A comparação costuma ser apresentada como uma escolha, e para uma instalação nova é. Para a maioria dos sites existentes não é, porque a verdadeira pergunta é se alguma coisa está a ser comprimida.
O que medimos, e quanto custa
Medimos 336 organismos públicos portugueses a 6 de setembro de 2026, um pedido a cada um, lendo apenas os cabeçalhos de resposta e o tamanho do HTML transmitido. Responderam 291. 107 deles, 36,8 %, enviavam a página inicial sem qualquer codificação de conteúdo.
O custo não é teórico. Entre os sites que comprimem, a página inicial mediana pesa 29 312 bytes transmitidos. Entre os que não comprimem, a mediana é de 109 705 bytes. São 3,7 vezes mais dados para o mesmo tipo de página, e dezoito dos sites sem compressão ultrapassam os 200 kB só de HTML, o mais pesado com 536 245 bytes.
A comparação em si
Agora a comparação propriamente dita. O gzip é suportado em todo o lado desde os anos 90 e é a escolha predefinida segura. O Brotli, normalizado em 2016, é suportado por todos os browsers atuais em HTTPS e produz geralmente um resultado mais pequeno em texto, com o ganho concentrado em HTML, CSS e JavaScript e não em formatos já comprimidos.
- curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding
- Nenhuma linha content-encoding: nada é comprimido
- content-encoding: br significa que foi negociado o Brotli, gzip significa o recurso alternativo
- Teste em HTTPS: os browsers não oferecem Brotli em HTTP simples
- Limite a compressão aos tipos de texto; imagens e vídeo não ganham nada
A forma honesta de exprimir a diferença é que o Brotli ganha em texto e que a margem varia com o conteúdo e com o nível de compressão escolhido. Quem lhe citar uma única percentagem universal está a citar um teste de referência, não o seu site. Meça o seu: basta um pedido.
Os níveis contam mais do que o algoritmo
A definição do nível conta mais do que a escolha do algoritmo, e é aí que vive a maioria das configurações erradas. O Brotli oferece os níveis 0 a 11. O nível 11 é tão lento que usá-lo em respostas geradas dinamicamente pode custar mais tempo de servidor do que poupa na transferência. A organização habitual é um nível alto para os recursos estáticos comprimidos uma vez na compilação, e um nível moderado para tudo o que é gerado a cada pedido.
O gzip tem a mesma estrutura com os níveis 1 a 9, e a mesma armadilha: o nível máximo raramente é o certo para conteúdo dinâmico.
Negociação, HTTPS, e o que não comprimir
A negociação de conteúdo decide qual é usado, e não depende só de si. O browser envia `Accept-Encoding: gzip, deflate, br` e o servidor escolhe. Configurar ambos significa que os clientes modernos recebem Brotli e tudo o resto recorre ao gzip, e é por isso que não é realmente uma escolha exclusiva.
Um pormenor prático que engana muitas vezes: os browsers só oferecem Brotli em HTTPS. Um site testado em HTTP simples parecerá não suportar Brotli quando na verdade suporta.
Comprimir formatos já comprimidos é trabalho perdido. JPEG, PNG, WebP, MP4 e a maioria dos formatos de tipos de letra não ganham nada e consomem CPU. Limite a compressão aos tipos MIME de texto, que é o predefinido na maioria das configurações sensatas e a primeira coisa a verificar nas outras.
Verifique o seu site num pedido
Verificar o seu próprio site cabe num comando, e é o mesmo que corremos 336 vezes:
FAQ
O Brotli é sempre melhor do que o gzip?
Em texto, o Brotli produz geralmente um resultado mais pequeno do que o gzip com definições comparáveis, e a margem depende do conteúdo e do nível escolhido. Não é melhor em formatos já comprimidos como JPEG ou MP4, onde nenhum dos dois algoritmos ajuda. Configurar ambos é a resposta normal, já que o browser negocia qual recebe.
Como verifico se o meu site comprime alguma coisa?
Envie um pedido com um cabeçalho Accept-Encoding e leia a resposta: curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding. Se não voltar nenhuma linha content-encoding, nada está a ser comprimido.
Porque é que o meu site não usa Brotli se o servidor o suporta?
A razão mais frequente é ter testado em HTTP simples. Os browsers só anunciam Brotli em HTTPS, por isso um teste em HTTP faz um servidor bem configurado parecer não o suportar. A segunda razão mais frequente é o módulo de compressão estar ativo mas limitado a uma lista de tipos MIME que não inclui o seu tipo de conteúdo.
Devo usar o nível de compressão máximo?
Para recursos estáticos comprimidos uma vez na compilação, um nível alto é razoável porque o custo se paga uma única vez. Para respostas geradas a cada pedido, os níveis mais altos podem custar mais tempo de servidor do que a transferência que poupam. Um nível moderado para o conteúdo dinâmico e um alto para os ficheiros estáticos é a organização habitual.
Quanto custa realmente não comprimir?
Na nossa medição de 291 organismos públicos que responderam a 6 de setembro de 2026, a página inicial mediana pesava 29 312 bytes transmitidos com a compressão ativa e 109 705 bytes sem ela, um fator de 3,7 para páginas comparáveis. Dezoito sites sem compressão ultrapassavam os 200 kB só de HTML.
**Comprimir formatos já comprimidos é trabalho perdido.** JPEG, PNG, WebP, MP4 e a maioria dos formatos de tipos de letra não ganham nada e consomem CPU. Limite a compressão aos tipos MIME de texto, que é o predefinido na maioria das configurações sensatas e a primeira coisa a verificar nas outras.