Como validar compressão Brotli e gzip em um site criado por IA

Um site criado por IA pode gerar HTML, CSS e JavaScript maiores do que o necessário. Mesmo depois de remover código e minificar arquivos, ainda existe outra pergunta: quantos bytes realmente atravessam a rede até o navegador?

Brotli e gzip reduzem o corpo transferido sem mudar o conteúdo que a aplicação recebe depois da descompressão. A economia pode ser relevante para recursos textuais, mas só existe quando cliente, plataforma e resposta negociam a mesma codificação.

Este guia mostra como separar tamanho de origem e tamanho transferido, validar Accept-Encoding e Content-Encoding, evitar dupla compressão e confirmar o comportamento na URL publicada.

Separe minificação de compressão HTTP

Minificação altera o arquivo da build: remove espaços, comentários e outras partes dispensáveis do código. Compressão HTTP codifica os bytes durante a entrega e o navegador os descomprime antes de usar o recurso.

São camadas complementares:

Não marque a tarefa como concluída porque o .js no disco está minificado. Também não tente compensar um bundle enorme apenas ativando Brotli: a descompressão devolve o mesmo JavaScript, que ainda precisa ser analisado e executado.

O artigo sobre Core Web Vitals em sites criados por IA ajuda a relacionar peso de rede com LCP e responsividade. Para imagens, use o guia específico de otimização antes da publicação, porque JPEG, WebP e AVIF já aplicam compressão própria.

Entenda a negociação de conteúdo

O navegador anuncia as codificações que aceita no request:

Accept-Encoding: gzip, br

A resposta codificada declara o que foi aplicado:

Content-Encoding: br
Vary: Accept-Encoding

O RFC 9110 define Accept-Encoding como a preferência do cliente por codificações de conteúdo. identity representa a resposta sem codificação. O servidor pode escolher uma opção aceitável ou devolver o corpo sem compressão quando isso for permitido.

Content-Encoding descreve a transformação aplicada à representação. O navegador precisa desse header para saber como recuperar os bytes originais. Um arquivo Brotli servido sem Content-Encoding: br não vira JavaScript ou CSS por adivinhação.

O RFC 7932 registra br como a codificação HTTP do formato Brotli. Gzip continua sendo um fallback amplamente aceito. A melhor resposta não é escolher um vencedor universal, mas negociar uma codificação suportada e manter identity funcional quando necessário.

Escolha recursos que realmente se beneficiam

Compressão de entrega costuma ajudar conteúdo textual e formatos com redundância:

• HTML;
• CSS;
• JavaScript;
• JSON;
• XML;
• SVG;
• manifestos e outros textos.

Evite tratar todo arquivo como candidato. PNG, JPEG, WebP, AVIF, MP4, PDF, ZIP e WOFF2 normalmente já são comprimidos. Recomprimi-los pode consumir CPU sem reduzir de forma útil o corpo.

O tipo declarado importa. Uma plataforma pode decidir se comprime com base em Content-Type, status e tamanho mínimo. O guia de nosniff e tipos MIME mostra por que extensão e conteúdo precisam concordar antes de otimizar a entrega.

Faça um inventário da build:

recurso:
Content-Type esperado:
tamanho no disco:
minificado?
formato já comprimido?
crítico para a primeira dobra?
codificação observada:
bytes transferidos:

Priorize os maiores recursos textuais que participam da rota inicial. Um JSON de desenvolvimento que não é publicado não deve comandar a otimização.

Meça a resposta negociada

Teste a URL final seguindo redirects. Primeiro peça Brotli ou gzip:

curl -sS -L --compressed \
  -H 'Accept-Encoding: br, gzip' \
  -D /tmp/headers-br-gzip.txt \
  -o /dev/null \
  -w 'url=%{url_effective}\nstatus=%{http_code}\nbytes=%{size_download}\n' \
  https://exemplo.com/assets/app.js

--compressed mantém a descompressão automática para a saída, enquanto o header explícito restringe a negociação a Brotli e gzip. size_download registra os bytes transferidos antes dessa descompressão.

Confira nos headers:

• Content-Encoding;
• Content-Type;
• Vary;
• Content-Length, quando existir;
• Cache-Control;
• status de cache da CDN;
• URL efetiva depois dos redirects.

Compare com uma requisição que pede o corpo sem codificação:

curl -sS -L \
  -H 'Accept-Encoding: identity' \
  -D /tmp/headers-identity.txt \
  -o /dev/null \
  -w 'url=%{url_effective}\nstatus=%{http_code}\nbytes=%{size_download}\n' \
  https://exemplo.com/assets/app.js

Confira Content-Encoding também em /tmp/headers-identity.txt. Se o servidor responder com br, gzip ou outra codificação, essa medição não é um baseline sem compressão e não deve entrar no cálculo de economia. Nem todo servidor é obrigado a oferecer identity para todos os recursos; registre o comportamento quando o pedido não for atendido.

Use também o painel Network do navegador. As colunas “Transferred” e “Resource size” ajudam a distinguir bytes de rede, tamanho descomprimido e resposta atendida por cache. Rode com cache desativado apenas para medir a transferência inicial; depois valide a navegação normal.

Não use Content-Length como única medida

Uma camada que comprime dinamicamente pode remover Content-Length ou usar transferência em chunks. A ausência do header não prova ausência de compressão.

Compare:

• Content-Encoding observado;
• bytes efetivamente baixados;
• tamanho do recurso decodificado;
• protocolo e cache;
• repetição sob a mesma condição.

A documentação atual de compressão de conteúdo da Cloudflare explica que a borda pode entregar gzip, Brotli, Zstandard ou nenhuma codificação conforme o request, o plano e as regras aplicadas. Ela também documenta que transformações podem exigir descompressão e recompressão no caminho.

Por isso, um header copiado da origem não prova o que o visitante recebeu. A resposta pública é a evidência operacional.

Preserve variantes de cache corretamente

Quando a mesma URL pode gerar corpos codificados de maneiras diferentes, a seleção da variante precisa considerar Accept-Encoding.

Em HTTP, isso costuma aparecer como:

Vary: Accept-Encoding

Não adicione Vary amplo por hábito. O objetivo é impedir que uma variante Brotli seja reutilizada para um cliente que não a aceita, sem fragmentar o cache por headers irrelevantes.

O artigo sobre como configurar Cache-Control aprofunda variantes, frescor e revalidação. Compressão reduz bytes; cache evita transferências. São otimizações diferentes e devem ser medidas separadamente.

Evite pré-comprimir de forma incompatível

Algumas builds geram irmãos como:

app.js
app.js.gz
app.js.br

Esses arquivos só ajudam quando a camada de entrega sabe selecionar a variante, definir Content-Encoding, preservar o Content-Type original e responder corretamente a clientes sem suporte.

Não publique app.js.br e altere o HTML para carregá-lo diretamente como script. A URL, o tipo e a codificação precisam formar uma resposta HTTP válida.

Também não comprima um corpo no código e mantenha Content-Length ou ETag calculados para bytes diferentes. Ao transformar uma resposta, atualize os headers na camada responsável ou deixe a plataforma fazer a negociação.

Conheça o limite do pacote do Site no Ar

No Site no Ar, o agente edita HTML e assets dentro de public/ pelo contrato de Publicação. Esses arquivos não definem uma configuração arbitrária da borda.

Incluir _headers, uma regra de servidor ou arquivos .br não garante que a plataforma os interprete como política de compressão. Hoje, o upload comum não oferece um controle por Site para escolher algoritmos ou reescrever headers de resposta.

Trate a compressão automática da infraestrutura como comportamento a ser observado na URL publicada. Se um produto exigir outra política, a mudança precisa acontecer em uma camada autorizada que controle a resposta HTTP ou em suporte explícito da plataforma, não em um arquivo presumido dentro do ZIP.

O que continua sob controle do projeto é valioso:

• remover dependências e código sem uso;
• minificar a build;
• escolher formatos adequados;
• evitar duplicação de conteúdo;
• enviar Content-Type correto pelo tipo de arquivo;
• medir a URL padrão e os domínios próprios;
• republicar a versão aprovada no mesmo Site.

Diagnostique falhas sem mascarar a causa

Mude uma variável por vez. Se você remover metade do JavaScript, trocar imagens e ativar outra camada de entrega na mesma publicação, não saberá qual ação mudou os bytes ou a experiência.

Prompt copiável para o agente

Audite a compressão HTTP desta landing page sem publicar ainda.

Fonte e build: [caminhos]
URL atual: [URL]

- Inventarie HTML, CSS, JavaScript, JSON, SVG, fontes, imagens e mídia.
- Registre tamanho no disco, Content-Type, Content-Encoding e bytes transferidos.
- Compare requests com --compressed e Accept-Encoding: identity.
- Siga redirects e registre a URL efetiva.
- Não confunda minificação, formato de arquivo, cache e compressão HTTP.
- Não crie arquivos .br ou .gz sem provar que a camada de entrega os negocia.
- Remova desperdício na fonte antes de depender da compressão.
- Depois da republicação, repita a medição na URL padrão e no domínio próprio.
- Entregue evidências antes/depois e qualquer limite da plataforma.

Checklist final

• recursos textuais e já comprimidos foram separados;
• tamanho de origem e bytes transferidos foram medidos;
• redirects foram seguidos e a URL efetiva foi registrada;
• Accept-Encoding e Content-Encoding foram observados;
• Content-Type corresponde ao recurso;
• variantes de cache consideram a codificação quando necessário;
• ausência de Content-Length não foi tratada como falha isolada;
• arquivos pré-comprimidos não dependem de interpretação presumida;
• a Version publicada não foi confundida com configuração da borda;
• URL padrão e domínio próprio foram comparados;
• a página foi testada sem cache e em navegação normal;
• redução de bytes não substituiu a revisão de código e execução.

Compressão HTTP boa é invisível para a aplicação e verificável na rede. O visitante recebe menos bytes, o navegador recupera exatamente o recurso esperado e a equipe consegue provar qual camada produziu o resultado.