O site demora 4 segundos a abrir e o visitante vai-se embora. Parece-lhe familiar? Na maioria das vezes, o problema não está no alojamento nem nas imagens. As páginas simplesmente pesam mais do que deviam porque o servidor as entrega «tal como estão», sem compressão.

A compressão GZIP reduz o tamanho de HTML, CSS e JavaScript em 60 a 80% antes de estes viajarem para o browser. Para o WordPress, isto não é um plugin pesado com muitas definições, mas sim uma diretiva na configuração ou uma caixa de verificação no painel de administração. De acordo com a W3Techs, a compressão é usada por mais de 85% dos sites na internet e, se o seu site não está entre eles, está a perder posições nos motores de busca e conversões sem motivo algum.

Abaixo estão sete formas funcionais de ativar o GZIP: desde a edição manual do.htaccess até a alguns cliques num plugin. No final, vou mostrar-lhe como verificar o resultado e abordar questões comuns sobre compatibilidade com CDN, Brotli e cache.

💡 Resumo rápido:

• Adicionar código de compressão ao .htaccess via FTP
• Escrever gzip on e gzip_types no nginx.conf
• Ativar a compressão com uma caixa de verificação no W3 Total Cache ou WP Rocket
• Verificar o resultado no Chrome DevTools ou GiftOfSpeed

O que é a compressão GZIP e porque é que um site WordPress precisa dela

O GZIP é um algoritmo de compressão que funciona ao nível do servidor: antes de enviar para o browser, «empacota» os ficheiros de texto num formato mais compacto. O browser desempacota-os em tempo real e renderiza a página como habitualmente. O utilizador não nota diferença nenhuma, enquanto o volume de dados transmitidos é reduzido várias vezes.

O que é exatamente comprimido: código HTML da página, folhas de estilo CSS, scripts JavaScript, ficheiros XML, tipos de letra e SVG. O GZIP não mexe nas imagens; para estas existem formatos de compressão separados (WebP, AVIF) e plugins de otimização.

A diferença em números é fácil de ver no Chrome DevTools: a mesma página, antes e depois da compressão, difere em tamanho duas a três vezes. Multiplique isso pelo número de visitantes por mês e obtém poupanças sérias em tráfego e tempo de carregamento.

Uma nuance importante: o GZIP não é a única opção. Os servidores modernos suportam Brotli, um algoritmo da Google que comprime ficheiros de texto 15 a 25% melhor do que o GZIP. Mas o Brotli não está disponível em todos os fornecedores de alojamento, enquanto o GZIP funciona em todo o lado, incluindo as configurações mais antigas. Por isso, vale sempre a pena começar com o GZIP e ligar o Brotli como o nível seguinte, quando a base estiver pronta.

Método 1: via.htaccess no Apache

O cenário mais comum: o site corre em Apache e tudo o que precisa de fazer é adicionar algumas linhas ao ficheiro .htaccess na raiz do site.

Onde está o.htaccess. Ligue-se ao servidor via FTP (por exemplo, através do FileZilla) ou aceda ao gestor de ficheiros do alojamento. Na pasta raiz do site (onde estão o wp-config.php e as pastas wp-content, wp-admin) encontre o .htaccess. Descarregue-o para o seu computador; vamos editar localmente para que, em caso de erro, possa reverter rapidamente.

O que adicionar. Abra o .htaccess num editor de texto (Notepad++, VS Code, Sublime Text) e adicione o seguinte bloco ANTES das linhas # BEGIN WordPress:

1
<IfModule mod_deflate.c>
2
  AddOutputFilterByType DEFLATE text/html text/css text/javascript
3
  AddOutputFilterByType DEFLATE application/javascript application/x-javascript
4
  AddOutputFilterByType DEFLATE application/rss+xml application/xml application/xhtml+xml
5
  AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
6
  AddOutputFilterByType DEFLATE font/ttf font/otf font/opentype application/x-font-ttf
7
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
8
 
9
  BrowserMatch ^Mozilla/4 gzip-only-text/html
10
  BrowserMatch ^Mozilla/4.0[678] no-gzip
11
  BrowserMatch bMSIE !no-gzip !gzip-only-text/html
12
  Header append Vary User-Agent
13
</IfModule>

O que está a acontecer aqui. O bloco <IfModule mod_deflate.c> verifica se o módulo mod_deflate está ativo no servidor (na maioria dos fornecedores de alojamento, está ativo por defeito). As diretivas AddOutputFilterByType DEFLATE especificam que tipos de ficheiro comprimir. As linhas BrowserMatch são uma muleta para versões antigas do Internet Explorer que previne bugs de gzip no IE6 e versões anteriores. O Header append Vary User-Agent diz aos servidores proxy para terem em conta o browser do utilizador ao fazer cache.

Guarde o ficheiro e carregue-o de volta para o servidor, substituindo. Antes disto, não se esqueça de fazer uma cópia de segurança do .htaccess original; se o site ficar em baixo, basta repor a versão antiga e tudo funcionará como antes.

Se, após o carregamento, o site der erro 500, verifique se há espaços extra ou quebras de linha antes de <?php ou depois de tags de fecho no ficheiro. Um erro no .htaccess deita abaixo o site inteiro, por isso é melhor fazer as edições uma de cada vez e verificar após cada uma.

Método 2: num servidor NGINX

O NGINX lida com a compressão de forma diferente do Apache. Aqui não há .htaccess e todas as configurações são escritas no ficheiro nginx.conf ou no ficheiro de configuração de um site específico (normalmente em /etc/nginx/sites-available/).

Adicione ou descomente as seguintes linhas na secção http ou server:

1
gzip on;
2
gzip_vary on;
3
gzip_min_length 1000;
4
gzip_comp_level 6;
5
gzip_types text/plain text/css text/javascript
6
           application/javascript application/x-javascript
7
           application/rss+xml application/xml application/xhtml+xml
8
           image/svg+xml image/x-icon
9
           font/ttf font/otf application/x-font-ttf
10
           application/vnd.ms-fontobject;
11
gzip_disable "MSIE [1-6]\.(?!.*SV1)";

Depois de fazer as alterações, verifique a sintaxe da configuração com o comando nginx -t e recarregue o NGINX: sudo systemctl reload nginx.

O parâmetro gzip_comp_level 6 é um compromisso entre o nível de compressão e a carga do processador. Um valor de 1 é a compressão mínima, 9 é a máxima. Na prática, o nível 6 proporciona quase a mesma poupança que o 9, mas consome notoriamente menos recursos do servidor.

Método 3: num servidor IIS (Windows Server)

O IIS é um servidor web da Microsoft usado em alojamentos Windows. A ativação da compressão aqui é feita de duas formas: através da interface gráfica ou da linha de comandos.

Através da interface do IIS. Abra o Gestor do IIS. Na secção «Componentes» → «Serviços», encontre «Compressão». Marque as caixas «Ativar compressão de conteúdo estático» e «Ativar compressão de conteúdo dinâmico». No painel «Ações», clique em «Aplicar».

Através da linha de comandos (como administrador):

1
:: Static compression
2
appcmd set config /section:urlCompression /doStaticCompression:True
3
 
4
:: Dynamic compression
5
appcmd set config /section:urlCompression /doDynamicCompression:True

A compressão estática guarda em cache, no disco, versões já comprimidas dos ficheiros, poupando tempo de processador. A compressão dinâmica comprime as respostas «em tempo real» e é adequada para páginas personalizadas, mas sobrecarrega o processador. Na prática, para o WordPress, ambos os modos são ativados: o estático trata do CSS/JS, enquanto o dinâmico trata do HTML de cada página.

Método 4: através do painel do fornecedor de alojamento

A maioria dos fornecedores de alojamento modernos ativa o GZIP por defeito. Se estiver no cPanel, vá à secção «Otimização do Site» ou «Desempenho» e procure o interruptor «Compressão» ou «Comprimir conteúdo». No Plesk, o caminho é semelhante: «Desempenho» → «Compressão de Saída».

Se não encontrar o interruptor, escreva para o suporte do alojamento. Este é um pedido padrão; o suporte técnico responde em minutos e, muitas vezes, ativa a compressão ao nível do servidor numa única resposta. Não precisa de explicar o que é o GZIP; basta escrever «Por favor, ative a compressão GZIP para o meu site».

Pode verificar se o alojamento já está a comprimir as páginas antes de qualquer edição; o método está descrito na secção «Como verificar se a compressão está ativada» abaixo. Se a verificação mostrar que o GZIP está a funcionar, salte todos os métodos de servidor e passe para os plugins apenas se quiser gerir a compressão a partir do painel de administração do WordPress.

Método 5: plugin W3 Total Cache

O W3 Total Cache é um dos mais antigos plugins de cache no repositório do WordPress, com um milhão de instalações ativas e uma classificação de 4,5 no WordPress.org. A compressão GZIP é ativada através de uma caixa de seleção separada e não requer a manipulação de ficheiros do servidor.

Instale o plugin a partir do repositório do WordPress, vá a Performance → Browser Cache e localize a secção «HTTP (gzip) compression». Marque a caixa «Enable HTTP (gzip) compression» e guarde as definições. O plugin adicionará automaticamente as diretivas necessárias ao .htaccess ou configurará as regras do NGINX, dependendo do servidor onde o site está a correr.

• Vantagens: não mexe manualmente nos ficheiros do servidor, um milhão de instalações confirma a estabilidade, compatível com CDN e Brotli
• Desvantagens: a interface está sobrecarregada de opções, um principiante pode facilmente quebrar a cache com a caixa de seleção errada

Método 6: plugin WP Rocket

O WP Rocket é um plugin premium de desempenho que adiciona automaticamente regras de GZIP ao .htaccess após a ativação. Não existem definições de compressão no mesmo; esta é ativada automaticamente após a instalação.

• Vantagens: zero trabalho manual, a compressão é ativada automaticamente, o plugin também resolve um conjunto de tarefas relacionadas (cache, lazy loading, minificação)
• Desvantagens: pago (a partir de $59 por ano), pagar a mais apenas pelo GZIP não se justifica

Se já comprou o WP Rocket para outras tarefas, a compressão já está a funcionar. Se está a pensar adquirir o plugin apenas para o GZIP, não o faça: o .htaccess ou o W3 Total Cache fazem o mesmo gratuitamente.

Método 7: plugin WP Super Cache

O WP Super Cache é um plugin de cache gratuito da Automattic (a mesma equipa por detrás do WordPress.com). Funciona de forma mais simples do que o W3 Total Cache: menos definições, menor probabilidade de partir algo.

Instale o plugin, vá a Settings → WP Super Cache → Advanced e encontre o item "Compress pages so they're served more quickly to visitors". Ative e guarde.

• Vantagens: gratuito, interface simples, código estável da Automattic
• Desvantagens: inferior ao W3 Total Cache em funcionalidades de cache, sem ajuste fino dos tipos de compressão

Como funciona a compressão GZIP na prática

Quando um browser solicita uma página, envia o cabeçalho Accept-Encoding: gzip, deflate, br, que significa "compreendo gzip, deflate e brotli, envie em qualquer um destes formatos". O servidor vê este cabeçalho, verifica se a compressão está ativada para o tipo de ficheiro solicitado e, em caso afirmativo, comprime a resposta e adiciona o cabeçalho Content-Encoding: gzip.

O browser recebe os dados comprimidos, descomprime-os em memória e renderiza a página. Para o utilizador, tudo acontece instantaneamente; a descompressão gzip demora frações de milissegundo, mesmo num dispositivo móvel fraco.

Este mecanismo é universal: funciona da mesma forma para Apache, NGINX, IIS e quaisquer plugins WordPress. Os plugins não inventam o seu próprio método de compressão; limitam-se a adicionar as mesmas diretivas de servidor que escrevemos manualmente nos primeiros três métodos.

O que o Google PageSpeed Insights e o GTmetrix mostram

Ambos os serviços, PageSpeed Insights e GTmetrix, verificam a compressão durante cada auditoria e destacam explicitamente o problema se os recursos de texto forem servidos sem GZIP.

No PageSpeed Insights, o aviso aparece como "Enable text compression" na secção "Opportunities" da auditoria. O Lighthouse (o motor do PageSpeed Insights) estima diretamente a poupança potencial em kilobytes para cada recurso não comprimido. No GTmetrix, existe uma verificação semelhante, "Enable GZIP compression" na categoria "Content".

Um ponto importante: nem o PageSpeed Insights nem o GTmetrix distinguem entre GZIP e Brotli ao nível da recomendação. Se a compressão estiver ativada por qualquer um destes métodos, a auditoria mostrará uma marca de verificação verde. Portanto, o GZIP é suficiente para passar na auditoria.

Como verificar se a compressão está ativada

Três métodos, do visual ao de baixo nível.

Método 1: Chrome DevTools. Abra o site, pressione F12, vá ao separador Network. Atualize a página, clique em qualquer linha e veja o separador Headers. Encontre a linha Content-Encoding: gzip na secção Response Headers.

Aí também pode ver o tamanho real e o comprimido: no exemplo acima, a página pesava 51,6 KB e, após a compressão, 17,7 KB.

Método 2: testadores online. GiftOfSpeed GZIP Test (giftofspeed.com/gzip-test) ou Check GZIP Compression (checkgzipcompression.net): insere o URL e obtém um veredito e a percentagem de compressão. Mais rápido do que o DevTools se precisar de verificar o site de outra pessoa ou várias páginas seguidas.

Método 3: curl a partir da linha de comandos. Se estiver em Linux/macOS ou no WSL no Windows:

1
curl -I -H "Accept-Encoding: gzip" https://yoursite.com | grep Content-Encoding

A resposta Content-Encoding: gzip significa que a compressão está a funcionar. Uma resposta vazia significa que não.

Breve explicação em vídeo

Para fechar o tópico com um lado visual, aqui está um pequeno vídeo que mostra todo o processo de ativação do GZIP via .htaccess e verificação do resultado no Chrome DevTools:

⁉️🤔 Perguntas frequentes

A compressão GZIP torna o servidor mais lento?

Pelo contrário. Sim, o processador gasta recursos na compressão, mas esta é uma carga microscópica comparada com o ganho da redução dos dados transmitidos. No nível de compressão 6 (o compromisso padrão), o processador trata disso em milissegundos. O único cenário onde a compressão pode ser notada é num VPS muito fraco com 512 MB de memória e milhares de visitantes simultâneos. Mas nessa situação, tem problemas mais sérios do que o GZIP. Na prática, a compressão não torna o servidor mais lento: uma página WordPress típica é comprimida em 2 a 5 milissegundos, enquanto a poupança na transmissão de dados pela rede ascende a dezenas e centenas de milissegundos para cada visitante. A compressão é sempre mais benéfica do que a sua ausência.

GZIP ou Brotli: o que escolher em 2026?

Comece com GZIP; funciona em qualquer alojamento e é suportado por todos os browsers, sem exceção. O Brotli comprime consideravelmente melhor, mas requer HTTPS (não é um problema em 2026) e suporte do lado do servidor. Se o alojamento ou a CDN (Cloudflare, BunnyCDN) suportar Brotli, ative-o como um complemento ao GZIP. A maioria dos sites modernos usa ambos: o servidor serve Brotli aos browsers que o compreendem e GZIP a todos os outros.

A compressão GZIP é compatível com CDN?

Totalmente. CDNs como a Cloudflare ou a BunnyCDN comprimem o conteúdo nos seus próprios servidores de borda, frequentemente em Brotli, mesmo que o seu alojamento não o suporte. Se o site já estiver por detrás da Cloudflare, verifique se a opção "Brotli" está ativada em "Speed" → "Optimization". Neste cenário, configurar o GZIP ao nível do servidor continua a ser útil como alternativa para pedidos diretos ao servidor de origem.

Tenho um plugin de cache. Preciso de ativar o GZIP separadamente?

Depende do plugin. O WP Rocket ativa o GZIP automaticamente, o W3 Total Cache com uma caixa de verificação separada, o WP Super Cache com uma caixa de verificação separada. Verifique as definições do seu plugin; quase todos os plugins de cache têm uma opção de compressão, mas nem todos a ativam por padrão. Não confie em "deve funcionar"; verifique através do DevTools após a configuração.

Posso comprimir páginas através do functions.php?

Tecnicamente pode, através da função PHP ob_start('ob_gzhandler'), mas não o recomendamos. Este método comprime a saída PHP e não afeta ficheiros estáticos (CSS, JS) que constituem a maior parte do tráfego. A compressão do lado do servidor (Apache/NGINX) funciona para todos os tipos de ficheiro e não sobrecarrega o processador PHP. Deixe a compressão PHP para aqueles casos raros em que o acesso às configurações do servidor é fisicamente impossível.

Conclusões: o que e quando ativar

O GZIP não é uma opção de "configurar e esquecer", mas sim uma higiene básica para um site WordPress. Se neste momento não sabe se o seu servidor comprime páginas, abra o DevTools e verifique o cabeçalho Content-Encoding. Está em falta? Volte ao método 1 e adicione três linhas ao .htaccess.

Matriz de decisão resumida:

• Site em Apache e não tem medo de FTP → método 1 (.htaccess), 5 minutos
• Site em NGINX e tem acesso às configurações → método 2 (nginx.conf), 10 minutos com verificação de sintaxe
• Por princípio, não mexe nos ficheiros do servidor → W3 Total Cache ou WP Super Cache, 2 minutos
• Já paga pelo WP Rocket → não faça nada, a compressão funciona de origem
• Não quer configurar absolutamente nada → escreva ao suporte do alojamento

Verifique o resultado com qualquer um dos três métodos acima e feche esta questão para sempre. Esta é daquelas otimizações raras que realmente se faz uma vez e continua a poupar tráfego e a acelerar o site anos mais tarde, sem atualizações, subscrições e configurações repetidas.