O que é compressão Gzip e Brotli?

Gzip e Brotli são algoritmos de compressão que seu servidor web usa para reduzir o tamanho dos arquivos antes de enviá-los ao navegador do visitante. A ideia é simples: arquivos baseados em texto como HTML, CSS e JavaScript contêm muitos padrões repetitivos, e algoritmos de compressão são muito bons em encontrar e eliminar essa redundância. Um arquivo HTML de 100 KB pode ser comprimido para 15-20 KB. O navegador o descomprime instantaneamente, e o visitante nunca percebe nada além de um carregamento de página mais rápido.

Se você já compactou uma pasta no computador, já entende o conceito básico. A compressão na web funciona da mesma forma, só que automática e transparentemente. O servidor comprime a resposta, o navegador a descomprime, e nem o desenvolvedor nem o visitante precisam fazer nada especial (supondo que o servidor esteja configurado corretamente).

Como a compressão web funciona no nível de protocolo

Toda vez que um navegador envia uma requisição HTTP, ele inclui um cabeçalho Accept-Encoding que informa ao servidor quais algoritmos de compressão ele suporta:

Accept-Encoding: gzip, deflate, br

Esse cabeçalho diz que o navegador pode lidar com Gzip, Deflate e Brotli (abreviado como br). O servidor escolhe o melhor algoritmo que suporta, comprime o corpo da resposta e adiciona um cabeçalho Content-Encoding para informar ao navegador qual algoritmo foi usado:

Content-Encoding: gzip

ou:

Content-Encoding: br

O navegador lê esse cabeçalho, aplica o algoritmo de descompressão correspondente e renderiza o conteúdo. Se o servidor não suporta compressão (ou não está configurado), ele envia a resposta sem compressão e nenhum cabeçalho Content-Encoding está presente.

Essa negociação acontece em cada requisição. O servidor pode escolher diferentes métodos de compressão para diferentes tipos de arquivo, ou até servir conteúdo sem compressão para arquivos que não se beneficiam dela.

Gzip: o padrão estabelecido

O Gzip é o cavalo de batalha da compressão web desde o final dos anos 1990. Ele é baseado no algoritmo DEFLATE (uma combinação de LZ77 e codificação de Huffman) e é suportado por literalmente todos os navegadores e servidores web em uso atualmente. Quando as pessoas falam em "habilitar compressão" em um servidor web, geralmente se referem ao Gzip.

O Gzip opera em níveis de compressão configuráveis, tipicamente de 1 (mais rápido, menos compressão) a 9 (mais lento, melhor compressão). A maioria dos servidores web tem como padrão o nível 6, que oferece um bom equilíbrio entre taxa de compressão e uso de CPU. No nível 6, o Gzip tipicamente alcança 70-85% de compressão em arquivos baseados em texto. Isso significa que um arquivo CSS de 100 KB vira aproximadamente 15-30 KB.

As principais vantagens do Gzip são sua universalidade (funciona em todo lugar), sua velocidade em níveis moderados de compressão e as décadas de otimização que entraram em suas implementações. A principal desvantagem é que ele não comprime tão bem quanto o Brotli, especialmente em arquivos menores.

Brotli: a alternativa moderna

O Brotli foi desenvolvido pelo Google e publicado como RFC 7932 em 2016. Foi projetado especificamente para conteúdo web e alcança taxas de compressão 15-25% melhores que o Gzip em ativos web típicos. O Brotli atinge isso usando um algoritmo de compressão mais sofisticado e incluindo um dicionário interno de strings comuns encontradas em conteúdo web (tags HTML, propriedades CSS, palavras-chave de JavaScript etc.).

O Brotli também usa níveis de compressão configuráveis, indo de 0 a 11. Em níveis de qualidade comparáveis, o Brotli produz saída menor que o Gzip, mas nos níveis mais altos (10-11), ele é significativamente mais lento para comprimir. Isso torna a compressão Brotli em alto nível ideal para ativos estáticos que podem ser pré-comprimidos uma vez e servidos muitas vezes, mas menos adequada para conteúdo dinâmico que precisa ser comprimido a cada requisição.

Uma limitação importante: o Brotli só funciona via HTTPS. Os navegadores não aceitam respostas comprimidas com Brotli em conexões HTTP simples. Como a maioria dos sites WordPress deveria estar em HTTPS de qualquer forma (e o HTTP/2 o exige), isso raramente é uma preocupação prática.

Gzip vs. Brotli: uma comparação prática

Veja como os dois algoritmos se comparam em métricas que importam para proprietários de sites WordPress:

• Taxa de compressão: o Brotli tipicamente produz arquivos 15-25% menores que o Gzip em níveis de compressão comparáveis. Em um site WordPress que carrega 500 KB de ativos compressíveis, essa diferença se traduz em cerca de 15-30 KB a menos transferidos por carregamento de página.
• Velocidade de compressão: o Gzip no nível 6 é mais rápido que o Brotli em uma configuração de qualidade equivalente. Para conteúdo dinâmico (páginas HTML geradas pelo PHP), o Gzip costuma ser a escolha mais prática, porque a compressão acontece a cada requisição. O Brotli em níveis 1-4 é comparável em velocidade ao Gzip e ainda comprime um pouco melhor.
• Velocidade de descompressão: o Brotli descomprime ligeiramente mais rápido que o Gzip, o que significa que o navegador consegue processar o conteúdo um pouco mais rápido. A diferença é pequena, mas consistente.
• Suporte de navegadores: todos os navegadores modernos suportam tanto Gzip quanto Brotli. O Internet Explorer (descontinuado) não suportava Brotli, mas Edge, Chrome, Firefox e Safari todos suportam. O suporte global a Brotli está acima de 96%.
• Suporte do servidor: o Apache suporta Brotli via mod_brotli (disponível desde o Apache 2.4.26). O nginx o suporta via módulo ngx_brotli (um módulo de terceiros que precisa ser compilado separadamente). O LiteSpeed tem suporte embutido a Brotli. A maioria dos provedores de hospedagem gerenciada e CDNs suportam ambos.
• Requisito de HTTPS: o Brotli exige HTTPS. O Gzip funciona tanto em HTTP quanto em HTTPS.

Na prática, muitos servidores são configurados para preferir o Brotli quando o navegador o suporta e recorrer ao Gzip caso contrário. Isso oferece a melhor compressão para navegadores modernos, mantendo compatibilidade com clientes mais antigos.

Como habilitar a compressão no Apache

No Apache, você habilita a compressão Gzip por meio do mod_deflate (nome confuso, mas usa Gzip, não Deflate puro). Adicione o seguinte ao seu arquivo .htaccess:

  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE application/font-woff2

Para Brotli no Apache, é necessário mod_brotli:

  AddOutputFilterByType BROTLI_COMPRESS text/html
  AddOutputFilterByType BROTLI_COMPRESS text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json

Como habilitar a compressão no nginx

No nginx, o Gzip vem embutido e só precisa ser habilitado na configuração:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Para Brotli no nginx, após instalar o módulo ngx_brotli:

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Plugins de cache do WordPress e compressão

Se você não tem acesso à configuração do servidor (comum em hospedagem compartilhada), vários plugins de cache do WordPress podem cuidar da compressão por você:

• WP Rocket: habilita a compressão Gzip automaticamente adicionando regras ao seu arquivo .htaccess. Também cria arquivos HTML estáticos pré-comprimidos no cache.
• W3 Total Cache: oferece compressão Gzip como uma opção configurável em suas configurações de Browser Cache. Também pode servir arquivos pré-comprimidos.
• LiteSpeed Cache: se sua hospedagem roda servidor LiteSpeed, esse plugin habilita automaticamente compressão Gzip e Brotli.
• WP Super Cache: inclui uma opção de compressão Gzip que comprime páginas em cache.
• Autoptimize: embora seja primariamente um plugin de otimização de CSS/JS, também pode servir versões comprimidas dos arquivos que gera.

Tenha em mente que, se o seu servidor já lida com compressão no nível do servidor, habilitá-la novamente por um plugin é desnecessário e pode às vezes causar conflitos (compressão dupla, que os navegadores não conseguem descomprimir).

Quais tipos de arquivo se beneficiam mais da compressão

A compressão funciona melhor em conteúdo baseado em texto e repetitivo. Eis um detalhamento por tipo de arquivo:

• HTML: comprime extremamente bem (redução de 70-90%). Páginas HTML geradas pelo WordPress são repletas de estruturas de tags repetitivas, nomes de classe e espaços em branco.
• CSS: comprime muito bem (redução de 80-90%). Folhas de estilo contêm muitos nomes de propriedades e seletores repetidos.
• JavaScript: comprime muito bem (redução de 70-85%). Arquivos JS têm palavras-chave, nomes de função e padrões estruturais repetidos.
• SVG: comprime extremamente bem (redução de 80-95%). SVGs são baseados em XML e altamente repetitivos.
• JSON: comprime muito bem (redução de 75-90%). Respostas de API e dados de configuração se beneficiam bastante.
• XML e feeds RSS: comprimem muito bem devido a sua estrutura repetitiva de tags.
• Web fonts (WOFF/WOFF2): fontes WOFF2 já incluem compressão Brotli internamente, então a compressão adicional do servidor traz benefício mínimo. Fontes WOFF têm compressão mais leve e podem se beneficiar ligeiramente do Gzip.

O que NÃO deve ser comprimido

Nem todos os tipos de arquivo se beneficiam da compressão, e alguns devem ser ativamente excluídos:

• Imagens JPEG, PNG, WebP, AVIF: esses formatos já são comprimidos. Passá-los por Gzip ou Brotli desperdiça CPU e pode até aumentar levemente o tamanho do arquivo.
• Arquivos de vídeo (MP4, WebM): já comprimidos com codecs altamente eficientes. A compressão do servidor adiciona sobrecarga sem benefício.
• Arquivos de áudio (MP3, AAC, OGG): como vídeo, já comprimidos.
• ZIP, GZIP e outros arquivos compactados: já são comprimidos por definição.
• Arquivos PDF: a maioria dos PDFs usa compressão interna. Compressão adicional traz economia desprezível.

Comprimir arquivos já comprimidos desperdiça CPU do servidor a cada requisição e pode até resultar em saída ligeiramente maior. A maioria das configurações de servidor web e plugins de cache do WordPress limita corretamente a compressão a tipos MIME baseados em texto, mas vale a pena verificar sua configuração para garantir que arquivos binários estejam excluídos.

O que o InspectWP verifica

O InspectWP examina o cabeçalho de resposta Content-Encoding retornado pelo seu site WordPress para determinar se a compressão está ativa. Ele procura especificamente por gzip, br (Brotli) ou deflate no valor do cabeçalho. Se nenhuma compressão for detectada, o relatório a sinaliza como uma questão de desempenho com a recomendação de habilitar Gzip ou Brotli. O método de compressão detectado é exibido na seção de desempenho do relatório, dando uma visão clara de se o seu servidor está corretamente configurado para reduzir os tamanhos de transferência.