Compressão Gzip no Nginx: Acelere o Carregamento do Seu Site

A compressão Gzip no Nginx ajuda seu site a carregar mais rápido ao reduzir respostas baseadas em texto antes de enviá-las pela rede. Se suas páginas incluem arquivos HTML, CSS, JavaScript, JSON, XML ou SVG, a compressão pode reduzir o tamanho da transferência sem alterar o que os usuários veem no navegador.

O objetivo é simples: enviar menos bytes, reduzir o tempo de espera e fazer melhor uso da largura de banda. Para a maioria dos sites em produção, o Gzip é uma das melhorias de desempenho do Nginx mais fáceis de ativar com segurança.

Como a Compressão Gzip Funciona no Nginx

A compressão Gzip ocorre depois que o Nginx selecionou uma resposta, mas antes de enviá-la ao cliente. O navegador anuncia suporte com o cabeçalho de requisição Accept-Encoding. Se o Gzip estiver ativado e o tipo de resposta corresponder à sua configuração, o Nginx comprime o corpo e o envia com Content-Encoding: gzip.

Isso funciona melhor para formatos de texto porque eles contêm padrões repetidos. Templates HTML, nomes de classes CSS, identificadores JavaScript e chaves JSON geralmente comprimem muito bem. Imagens, vídeos, PDFs e arquivos compactados já estão normalmente comprimidos, então tentar aplicar gzip neles pode desperdiçar CPU sem reduzir significativamente o arquivo.

Uma configuração básica geralmente vai no bloco http para que se aplique a todos os blocos de servidor:

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

A diretiva gzip on ativa a compressão. gzip_types informa ao Nginx quais tipos MIME comprimir além do padrão text/html. gzip_min_length evita gastar CPU em respostas pequenas, onde a sobrecarga do cabeçalho Gzip pode anular o benefício.

gzip_vary on adiciona um cabeçalho Vary: Accept-Encoding. Isso é importante se seu site estiver atrás de um CDN ou cache compartilhado, porque os caches precisam saber que versões comprimidas e não comprimidas são variantes diferentes da mesma URL.

Para uma base de desempenho mais ampla do Nginx, você também pode querer revisar Ajuste de desempenho do Nginx.

Um detalhe que pega muitas pessoas: o Nginx sempre comprime text/html quando o Gzip está ativado, então text/html não precisa aparecer em gzip_types. Se você adicioná-lo mesmo assim, o Nginx pode avisar que o tipo MIME é duplicado. Esse aviso é inofensivo, mas é um sinal de que a configuração foi copiada sem ser limpa.

Escolhendo Configurações de Compressão Seguras

O maior erro com a compressão Gzip no Nginx é tratar o nível de compressão como um botão de volume. Mais alto nem sempre é melhor. Os níveis Gzip geralmente variam de 1 a 9. O nível 1 é o mais rápido, mas comprime menos. O nível 9 comprime mais, mas pode custar significativamente mais CPU.

Para muitos sites, gzip_comp_level 4, 5 ou 6 é uma faixa prática. Oferece boa compressão sem sobrecarregar demais o servidor. Se seu servidor Nginx lida com alto tráfego ou roda em uma instância pequena, evite pular direto para o nível 9.

Padrões bons se parecem com isso:

• Use gzip_comp_level 5 para uma configuração equilibrada.
• Use gzip_min_length 1024 para que respostas pequenas pulem a compressão.
• Comprima ativos baseados em texto, não mídia já comprimida.
• Mantenha gzip_vary on quando caches ou CDNs estiverem envolvidos.
• Teste o uso de CPU após ativar a compressão.

Aqui está um cenário comum. Você administra um site de documentação com muitas páginas CSS, JavaScript e HTML. Antes do Gzip, uma página carrega 650 KB de ativos de texto. Após ativar a compressão, o tamanho da transferência pode cair drasticamente, enquanto o navegador ainda recebe os mesmos arquivos após a descompressão. Usuários em conexões mais lentas sentem mais a melhoria.

Os ganhos nem sempre são iguais em todos os sites. Uma página dominada por imagens JPEG não melhorará muito com o Gzip. Um painel que envia grandes respostas JSON pode melhorar bastante.

Para APIs, seja mais deliberado. Comprimir uma resposta JSON pequena como {"ok":true} geralmente é inútil. Comprimir um resultado de busca de 300 KB ou uma carga de relatório pode valer a pena. Se sua API retorna dados privados e reflete entrada controlada pelo usuário na mesma resposta, discuta os riscos de compressão com a equipe de aplicação antes de ativá-la em todos os lugares. Isso não significa "nunca comprimir APIs". Significa que a compressão pertence ao mesmo balde de revisão que cache, cookies e cabeçalhos de resposta.

Como Testar se o Gzip Está Funcionando

Após alterar a configuração do Nginx, teste a sintaxe antes de recarregar:

nginx -t

Em seguida, recarregue o Nginx através do seu gerenciador de serviços ou processo de implantação. Um recarregamento geralmente é suficiente porque isso é uma mudança de configuração, não um reinício completo do binário.

Você pode verificar uma resposta com curl:

curl -I -H "Accept-Encoding: gzip" https://example.com/app.css

Procure por este cabeçalho:

Content-Encoding: gzip

Também verifique:

Vary: Accept-Encoding

Se você não vir Content-Encoding: gzip, verifique o tipo MIME da resposta. Por exemplo, um arquivo JavaScript servido como text/plain ainda pode comprimir se text/plain estiver incluído, mas uma resposta de API personalizada usando um tipo de conteúdo incomum pode não corresponder à sua lista gzip_types.

As ferramentas de desenvolvedor do navegador também podem ajudar. Abra a aba Rede, recarregue a página e inspecione os cabeçalhos de resposta e o tamanho transferido. O tamanho transferido deve ser menor que o tamanho do recurso não comprimido para arquivos compressíveis.

Se você também está usando um CDN, lembre-se de que o CDN pode realizar sua própria compressão. Nesse caso, o Nginx pode não ser a camada final que decide o que o navegador recebe. Teste tanto o acesso direto à origem quanto a URL pública do CDN quando possível.

Se a resposta da origem direta estiver comprimida, mas a resposta do CDN não estiver, verifique as configurações de compressão do CDN e o comportamento da chave de cache. Se a resposta do CDN estiver comprimida, mas a origem não, isso pode ser aceitável. Muitas equipes intencionalmente deixam o CDN lidar com a compressão estática pública enquanto mantêm a configuração da origem mais simples.

Quando Ter Cuidado com o Gzip

O Gzip é seguro para a maioria dos conteúdos estáticos e dinâmicos, mas há casos em que você deve desacelerar e testar cuidadosamente.

Não comprima arquivos que já estão comprimidos. Exemplos comuns incluem:

• .jpg, .jpeg, .png e .webp
• .mp4, .mov e outros formatos de vídeo
• .zip, .gz, .tar.gz e arquivos compactados
• A maioria dos arquivos de fonte, dependendo do formato e caminho de entrega

Você também deve monitorar o uso de CPU. A compressão não é gratuita. Se seu servidor já está perto dos limites de CPU, ativar compressão agressiva pode piorar os tempos de resposta sob carga. Comece com configurações moderadas, depois monitore tráfego, latência e CPU.

Aplicações sensíveis à segurança também devem evitar expor segredos em respostas comprimidas próximas a entradas controladas pelo atacante. Este é um risco mais especializado, mas vale a pena conhecer para aplicativos que refletem entrada do usuário em páginas contendo tokens ou dados privados.

Para ativos estáticos, outra opção é pré-comprimir arquivos durante seu pipeline de build e servir versões .gz do disco. Isso pode reduzir a CPU em tempo de execução, especialmente para grandes pacotes JavaScript. Respostas de API dinâmicas ainda precisam de compressão em tempo de execução se você quiser que sejam comprimidas.

Se você serve arquivos pré-comprimidos, ative gzip_static on; e certifique-se de que o arquivo .gz foi gerado a partir da mesma versão exata do ativo que o arquivo não comprimido. Um app.js.gz desatualizado ao lado de um app.js mais novo é um bug frustrante: apenas clientes que solicitam Gzip veem o código antigo.

gzip_static on;

Essa diretiva é útil para artefatos de build, não para respostas upstream dinâmicas. Para respostas dinâmicas provenientes de um servidor de aplicação, o Nginx ainda precisa de compressão em tempo de execução, a menos que o upstream já envie um corpo comprimido.

Quando Buscar Ajuda

Chame um administrador Nginx experiente ou engenheiro DevOps se ativar o Gzip causar alta CPU, comportamento inconsistente do CDN ou respostas quebradas para clientes mais antigos. Você também deve buscar ajuda se as configurações de compressão estiverem misturadas em vários arquivos de configuração incluídos e você não tiver certeza de qual bloco está realmente ativo.

Para um site simples, o Gzip pode ser ativado em minutos. Para uma aplicação de alto tráfego, trate como qualquer mudança de desempenho: teste, implemente gradualmente e monitore o resultado.

A compressão Gzip no Nginx é uma maneira prática de acelerar o carregamento para sites e APIs com muito texto. Mantenha os tipos MIME focados, escolha um nível de compressão moderado e verifique os cabeçalhos após o recarregamento. Uma vez funcionando, os usuários recebem respostas menores enquanto seu código de aplicação permanece o mesmo.