Como fazer o servidor enviar resposta compactada: guia passo a passo para economizar tráfego

Um único cabeçalho em uma solicitação HTTP pode reduzir o volume de dados baixados várias vezes. Estamos falando da negociação de compactação entre cliente e servidor. Se você trabalha com proxy e paga por cada gigabyte de tráfego, esse assunto afeta diretamente sua conta. Neste guia, vamos mostrar como fazer o servidor enviar uma resposta compactada, como medir a economia real na sua tarefa e quais armadilhas esperar.

Introdução: um cabeçalho pode reduzir o tráfego várias vezes

A compactação HTTP funciona de maneira surpreendentemente simples. O cliente informa ao servidor quais algoritmos de compactação entende. O servidor escolhe um adequado, compacta o corpo da resposta e a envia. O cliente descompacta os dados do seu lado. Como resultado, o que trafega pela rede não é o HTML ou JSON original, mas sua versão compactada, que geralmente pesa de três a cinco vezes menos.

O que você vai obter no final. Depois de ler este guia, você saberá ativar a compactação no lado do cliente, verificar se o servidor realmente enviou uma resposta compactada, medir a economia de tráfego em bytes antes e depois, e diagnosticar situações em que a compactação não está funcionando. Tudo isso é crucial quando você trafega através do proxy Proxeon e paga por gigabytes.

Para quem é este guia. O material é voltado para desenvolvedores, profissionais de scraping, engenheiros de automação e todos que escrevem clientes para trabalhar com HTTP através de proxy. Nível intermediário. Não vamos abordar o que compõe o gasto de tráfego em geral. Isso é tema de um artigo separado. Aqui, focamos estritamente na compactação.

O que você precisa saber de antemão. Basta um entendimento básico do que é uma solicitação e resposta HTTP, o que são cabeçalhos e como executar um comando no terminal. Se você já fez uma requisição com curl ou escreveu um script em Python ou Node.js, vai conseguir sem dificuldade.

Quanto tempo você vai precisar. Ler e repetir todos os exemplos levará cerca de sessenta minutos. Os primeiros resultados práticos você verá em dez minutos, ao comparar o tamanho da resposta compactada com a não compactada com seus próprios olhos.

Preparação inicial

Antes de começar, verifique se você tem tudo o que precisa. Isso economizará tempo e evitará erros no meio do caminho.

Ferramentas necessárias

• curl versão 7.72 ou mais recente. Nas versões de 2026, brotli e zstd são suportados nativamente na maioria dos sistemas.
• Python versão 3.10 ou mais recente com a biblioteca requests instalada, e para brotli adicionalmente o pacote brotli ou brotlicffi.
• Node.js versão 18 ou mais recente. O módulo zlib é embutido e suporta gzip, deflate e brotli.
• Acesso ao proxy Proxeon, se você quiser medir a economia exatamente nas condições em que trabalha diariamente.
• Qualquer editor de texto para escrever scripts.

Requisitos do sistema

Qualquer sistema moderno serve: Windows, macOS ou Linux. Todos os exemplos são multiplataforma. Dois gigabytes de RAM são suficientes. Não há requisitos especiais de processador, embora ao compactar grandes volumes, o algoritmo brotli no nível máximo possa sobrecarregar um núcleo visivelmente.

O que instalar e verificar

1. Abra o terminal e execute o comando para verificar a versão do curl:

   curl --version

2. Observe a primeira linha da saída. Ela mostra a versão. Verifique se na lista de recursos constam brotli e, se possível, zstd.
3. Verifique o Python com o comando

   python --version

   e instale as dependências:

   pip install requests brotli

4. Verifique o Node.js com o comando

   node --version

Dica: Se o curl do seu sistema foi compilado sem brotli, instale-o através do gerenciador de pacotes oficial do seu SO. Nas versões corporativas de 2026, brotli quase sempre está habilitado por padrão.

Backups. Neste guia, não alteramos a configuração de servidores de produção nem tocamos em dados de produção. Apenas enviamos solicitações e medimos respostas. Portanto, backups não são necessários. No entanto, se mais tarde você decidir ativar a compactação no seu próprio servidor web, salve o arquivo de configuração original antes de editar.

✅ Verificação: Todas as três ferramentas respondem ao comando de verificação de versão e mostram o número. A preparação está concluída; vamos em frente.

Conceitos básicos em linguagem simples

Antes de apertar botões, vamos entender os termos. Isso levará cinco minutos, mas evitará confusão no futuro.

Como funciona a negociação de compactação

A compactação HTTP depende de três cabeçalhos. Compreender o papel deles resolve a maioria dos problemas.

Accept-Encoding no cliente. Este é o cabeçalho que seu cliente envia junto com a solicitação. Nele, estão listados os algoritmos de compactação que o cliente sabe descompactar. Por exemplo, a string

Accept-Encoding: gzip, br, zstd

Content-Encoding na resposta. Este é o cabeçalho que o servidor adiciona à sua resposta. Ele informa qual algoritmo foi usado para compactar o corpo. Se você vir

Content-Encoding: br

Vary no servidor. O cabeçalho Vary informa a caches e proxies que a resposta depende de certos cabeçalhos da solicitação. Para compactação, é crítico o valor

Vary: Accept-Encoding

Ideia-chave da negociação

Lembre-se da sequência. O cliente pede através do Accept-Encoding. O servidor decide e responde com Content-Encoding. Intermediários se orientam pelo Vary. Se qualquer elo dessa corrente quebrar, você receberá uma resposta não compactada e pagará mais caro pelo tráfego.

Dica: Mesmo que sua biblioteca HTTP adicione Accept-Encoding automaticamente, sempre verifique o cabeçalho real da resposta. A automação às vezes é silenciosa, mas o tráfego sai.

gzip, deflate, brotli, zstd: comparação dos algoritmos

Existem quatro algoritmos de compactação comuns para HTTP. Eles diferem em grau de compactação e carga na CPU. Vamos analisar cada um e resumir os números em uma tabela.

gzip

O mais antigo e universal. Suportado em qualquer lugar: qualquer servidor, qualquer cliente, qualquer proxy. Oferece boa compactação em dados de texto com carga moderada. Se estiver em dúvida, comece com gzip.

deflate

Primo próximo do gzip, usa o mesmo algoritmo internamente, mas com um wrapper diferente. Na prática, é menos comum e às vezes implementado com erros em servidores. A compactação é semelhante à do gzip. Não há razão especial para escolher deflate em vez de gzip.

brotli

Algoritmo moderno, projetado especificamente para a web. Em dados de texto, compacta visivelmente mais que gzip, especialmente em HTML, CSS e JSON. O preço é uma carga maior na CPU ao compactar nos níveis máximos. A descompactação é rápida. Nos cabeçalhos, é indicado como br.

zstd

Algoritmo moderno e rápido, com ajuste flexível de níveis. Oferece compactação no nível do brotli, mas é mais rápido na velocidade de compactação. O suporte na web cresce; até 2026, a maioria dos servidores e clientes atuais o entende. Indicado como zstd.

Tabela de comparação em uma resposta de texto típica

Vamos pegar uma resposta JSON fictícia de 1000 kilobytes sem compactação. Os números são aproximados, dependem do conteúdo, mas refletem a ordem de grandeza corretamente.

• Sem compactação: 1000 KB, economia de 0%, carga mínima na CPU.
• gzip nível 6: cerca de 190 KB, economia de aproximadamente 81%, carga baixa.
• deflate nível 6: cerca de 195 KB, economia de aproximadamente 80%, carga baixa.
• brotli nível 5: cerca de 165 KB, economia de aproximadamente 83%, carga média.
• brotli nível 11: cerca de 140 KB, economia de aproximadamente 86%, carga alta.
• zstd nível 3: cerca de 175 KB, economia de aproximadamente 82%, carga baixa.
• zstd nível 19: cerca de 150 KB, economia de aproximadamente 85%, carga média.

A conclusão é simples. Em dados de texto, qualquer compactação reduz o tráfego em cerca de cinco vezes. A diferença entre os algoritmos é de alguns pontos percentuais. Portanto, para economizar tráfego via proxy, o importante não é qual algoritmo, mas o fato de a compactação estar habilitada.

Dica: Se você apenas baixa dados, e não os envia, a carga na sua CPU é apenas para descompactação, e isso é rápido em todos os algoritmos. Portanto, você pode pedir a opção mais vantajosa em termos de compactação.

✅ Verificação: Você entende que brotli e zstd costumam ser um pouco mais eficientes que gzip em texto, mas gzip é o mais compatível. Isso é suficiente para a prática.

Passo 1: Envie uma solicitação e veja se a resposta é compactada

Objetivo da etapa. Aprender a ver os cabeçalhos Content-Encoding e o tamanho real do corpo. Sem isso, é impossível medir a economia.

Verificação com curl

1. Abra o terminal.
2. Primeiro, solicite o recurso sem compactação para saber o tamanho original. Execute:

   curl -s -o /dev/null -w "%{size_download}" https://example.com/api/data

3. Anote o número. É o tamanho da resposta não compactada em bytes.
4. Agora, peça compactação. A flag --compressed adiciona automaticamente Accept-Encoding e descompacta a resposta:

   curl -s --compressed -o /dev/null -w "%{size_download}" https://example.com/api/data

5. Compare os dois números. O segundo deve ser visivelmente menor, com o mesmo conteúdo.

Importante: O indicador size_download no curl, ao usar --compressed, reflete o tamanho dos dados já descompactados, não o que passou pela rede. Para ver o volume real de rede, use o cabeçalho da resposta e medições intermediárias, que discutiremos na etapa de medição.

Veja os cabeçalhos da resposta

1. Execute a solicitação com a flag de saída de cabeçalhos:

   curl -s -I --compressed https://example.com/api/data

2. Encontre a linha Content-Encoding. Se houver gzip, br ou zstd, o servidor enviou a resposta compactada.
3. Encontre a linha Vary. A presença de Accept-Encoding nela indica configuração correta de cache.

Dica: Para especificar explicitamente o algoritmo desejado, adicione o cabeçalho manualmente:

curl -s -H "Accept-Encoding: br" -I https://example.com/api/data

Trabalhando com o proxy Proxeon

Para medir a economia em condições reais, direcione a solicitação através do proxy. No curl, isso é feito com a flag -x:

curl -s --compressed -x http://login:senha@endereco_proxeon:porta -o /dev/null -w "%{size_download}" https://example.com/api/data

Assim, você verá se a compactação chega pelo proxy e se algum cabeçalho é removido no caminho.

Resultado esperado. Você vê dois números: o tamanho sem compactação e com compactação. E vê o cabeçalho Content-Encoding na resposta. Isso significa que o mecanismo está funcionando.

Possível problema: se os dois números forem iguais e Content-Encoding ausente, o servidor não enviou a compactação. As causas serão discutidas em uma seção separada.

✅ Verificação: Na resposta com a flag --compressed, há uma linha Content-Encoding com um dos algoritmos. A etapa está concluída.

Passo 2: Meça a economia real com Python

Objetivo da etapa. Obter números precisos de tráfego de rede antes e depois da compactação com um script funcional que você possa aplicar à sua tarefa.

Medição simples com requests

A biblioteca requests adiciona Accept-Encoding por padrão e descompacta a resposta. Para medir o tamanho real da rede, observaremos o comprimento do conteúdo bruto antes da descompactação.

1. Crie um arquivo measure.py.
2. Cole o seguinte código:

import requests
url = "https://example.com/api/data"
# Solicitação sem compactação
r_plain = requests.get(url, headers={"Accept-Encoding": "identity"})
size_plain = len(r_plain.content)
# Solicitação com compactação
r_comp = requests.get(url, headers={"Accept-Encoding": "gzip, br, zstd"})
encoding = r_comp.headers.get("Content-Encoding", "nenhum")
size_wire = int(r_comp.headers.get("Content-Length", 0))
size_body = len(r_comp.content)
print("Sem compactação, bytes:", size_plain)
print("Algoritmo de compactação:", encoding)
print("Na rede aproximadamente, bytes:", size_wire)
print("Após descompactação, bytes:", size_body)
if size_plain and size_wire:
saved = 100 - size_wire * 100 
print("Economia de tráfego, %:", saved)

Atenção: O valor Content-Length nem sempre está presente, especialmente em transmissão chunked. Se ausente, use o método mais preciso abaixo.

Medição precisa do volume de rede

Para medir exatamente o que passou pela rede, desative a descompactação automática e conte os bytes do fluxo bruto.

import requests
url = "https://example.com/api/data"
sess = requests.Session()
# Desativa a descompactação automática para ver o tamanho bruto
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, stream=True)
raw_bytes = 0
for chunk in r.raw.stream(8192, decode_content=False):
raw_bytes += len(chunk)
print("Algoritmo:", r.headers.get("Content-Encoding", "nenhum"))
print("Bytes brutos na rede:", raw_bytes)

Compare raw_bytes com o tamanho da solicitação não compactada. A diferença é a sua economia real.

Medição via proxy Proxeon

Adicione o parâmetro proxies para obter números em condições reais:

proxies = {
"http": "http://login:senha@endereco_proxeon:porta",
"https": "http://login:senha@endereco_proxeon:porta",
}
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, proxies=proxies, stream=True)

Dica: Execute a medição várias vezes e faça a média. Respostas dinâmicas mudam de tamanho, então uma medição única pode enganar.

Resultado esperado. O script imprime o algoritmo de compactação e o número de bytes brutos, que é menor que o tamanho da resposta não compactada. Se a economia for de setenta por cento ou mais em um recurso de texto, tudo está funcionando.

✅ Verificação: Na saída, o algoritmo não é "nenhum" e os bytes brutos são menores que sem compactação. Ótimo.

Passo 3: A mesma medição em Node.js

Objetivo da etapa. Obter uma ferramenta de medição funcional em JavaScript para quem escreve clientes em Node.

Medição do fluxo bruto

1. Crie um arquivo measure.js.
2. Cole o código que conta os bytes antes da descompactação:

const https = require('https');
const url = 'https://example.com/api/data';
function measure(acceptEncoding) {
 return new Promise((resolve) => {
const req = https.get(url, { headers: { 'Accept-Encoding': acceptEncoding } }, (res) => {
 let bytes = 0;
 res.on('data', (chunk) => { bytes += chunk.length; });
 res.on('end', () => {
resolve({ enc: res.headers['content-encoding'] || 'nenhum', bytes });
 });
});
req.end();
 });
}
(async () => {
 const plain = await measure('identity');
 const comp = await measure('gzip, br, zstd');
 console.log('Sem compactação, bytes:', plain.bytes);
 console.log('Algoritmo:', comp.enc);
 console.log('Compactado na rede, bytes:', comp.bytes);
 const saved = Math.round(100 - (comp.bytes * 100) / plain.bytes);
 console.log('Economia, %:', saved);
})();

Importante: Neste exemplo, lemos o fluxo bruto de res e não conectamos o zlib. Portanto, o contador bytes mostra exatamente o volume de rede. É isso que você paga ao provedor de proxy.

Descompactação manual no Node

Se você também precisar ler o conteúdo, descompacte o fluxo usando o módulo zlib embutido:

const zlib = require('zlib');
let stream = res;
const enc = res.headers['content-encoding'];
if (enc === 'gzip') stream = res.pipe(zlib.createGunzip());
else if (enc === 'br') stream = res.pipe(zlib.createBrotliDecompress());
else if (enc === 'deflate') stream = res.pipe(zlib.createInflate());

Dica: Para zstd, nas versões recentes do Node.js existe zlib.createZstdDecompress. Se sua versão não incluir, atualize o Node ou use um pacote npm separado.

Resultado esperado. O Node imprime a economia em porcentagem, comparável ao que você obteve no Python e no curl.

✅ Verificação: As três ferramentas dão números de economia semelhantes. Isso significa que suas medições são confiáveis.

Passo 4: Por que a resposta chega não compactada

Objetivo da etapa. Aprender a diagnosticar por que a compactação não funcionou e corrigir a causa. Esse é o problema mais comum na prática.

Caso um: o cliente não pediu

A causa mais comum. Seu cliente HTTP não enviou o cabeçalho Accept-Encoding, e o servidor honestamente enviou uma resposta não compactada. Isso acontece quando você define cabeçalhos manualmente e esquece a compactação, ou quando usa um socket de baixo nível.

1. Verifique o que está indo para o servidor. No curl, adicione a flag -v e procure a linha com Accept-Encoding nos cabeçalhos de saída.
2. Se a linha não estiver, adicione-a explicitamente com -H ou a flag --compressed.
3. No Python, verifique se você não sobrescreveu o cabeçalho com um valor vazio.

Atenção: Algumas bibliotecas, ao definir manualmente qualquer cabeçalho, param de adicionar seus valores padrão. Se você definir User-Agent à mão, verifique se Accept-Encoding não desapareceu junto.

Caso dois: o servidor não suporta

O servidor pode não suportar compactação, ou não suportar o algoritmo solicitado. Nesse caso, ele envia a resposta não compactada, o que é permitido pelo padrão.

1. Peça algoritmos diferentes um a um: primeiro gzip, depois br, depois zstd.
2. Veja em qual deles aparece Content-Encoding na resposta.
3. Se em nenhum, o servidor não envia compactação. Você não pode mudar isso em um servidor de terceiros, mas pode escolher outro endpoint ou API, se houver.

Dica: Muitas APIs só enviam compactação para respostas acima de um certo tamanho. Respostas pequenas geralmente são deixadas sem compactação de propósito, pois a sobrecarga de compactação supera o benefício.

Caso três: intermediário removeu o cabeçalho

Entre você e o servidor pode haver um nó de cache, gateway ou proxy que remove ou altera os cabeçalhos de compactação. Às vezes, o intermediário descompacta a resposta para suas próprias necessidades e entrega a versão descompactada a você.

1. Faça uma solicitação diretamente e outra através do proxy e compare os cabeçalhos Content-Encoding.
2. Se diretamente há compactação, mas via intermediário não, o intermediário está interferindo.
3. Ao usar o proxy Proxeon, a compactação é transmitida de forma transparente; portanto, se você vir diferença, procure o problema no servidor de destino ou no CDN dele.

Resultado esperado. Você sabe exatamente em qual dos três elos a compactação se perde e entende o que fazer a respeito.

✅ Verificação: Você consegue explicar em uma frase por que uma resposta específica veio não compactada. Diagnóstico concluído.

Passo 5: Armadilhas ao trabalhar com compactação

Objetivo da etapa. Evitar erros sutis que corrompem dados ou distorcem medições.

Compactação dupla

Às vezes, o conteúdo já está compactado no nível do aplicativo, e o servidor compacta novamente. Ou o contrário: você compacta o corpo da solicitação, e o proxy ou biblioteca faz isso de novo. A compactação dupla quase não traz ganho, às vezes até aumenta o tamanho e certamente desperdiça CPU.

1. Verifique se a resposta não tem dois valores ao mesmo tempo em Content-Encoding, por exemplo gzip dentro de br.
2. Não compacte manualmente o que a biblioteca já compactará automaticamente.
3. Se vir uma cadeia de codificações, descompacte na ordem inversa.

Fluxo corrompido

Uma queda de conexão ou erro do intermediário pode fazer com que o fluxo compactado chegue incompleto. Ao descompactar, você obterá um erro ou dados truncados.

1. Sempre envolva a descompactação em tratamento de erros.
2. Em caso de erro de descompactação, repita a solicitação, em vez de tentar ler dados corrompidos.
3. Compare o tamanho real com o Content-Length, se estiver presente.

Atenção: Nunca salve dados parcialmente descompactados como resultado. Um JSON corrompido parece plausível, mas causará erros ocultos no pipeline.

Descompactação manual quando a biblioteca não faz

Se você desativou a descompactação automática para medir com precisão ou usa um cliente de baixo nível, terá que descompactar manualmente. Exemplo em Python:

import gzip, brotli, zlib
def decompress(data, encoding):
if encoding == "gzip":
return gzip.decompress(data)
if encoding == "br":
return brotli.decompress(data)
if encoding == "deflate":
return zlib.decompress(data)
return data

Dica: Se a descompactação deflate falhar com erro, tente chamar zlib.decompress com parâmetro wbits igual a menos quinze. Alguns servidores enviam deflate puro sem o wrapper zlib.

Resultado esperado. Você sabe descompactar qualquer um dos formatos suportados manualmente e trata erros de fluxo corretamente.

✅ Verificação: Seu script não trava em uma resposta corrompida, mas repete a solicitação. Resiliência alcançada.

Passo 6: O que não faz sentido compactar

Objetivo da etapa. Não desperdiçar CPU e tempo compactando o que já está compactado. Isso economiza recursos sem perder benefícios de tráfego.

Formatos já compactados

Alguns dados são armazenados em formatos que já usam compactação internamente. Tentar compactá-los novamente é inútil: o ganho será de frações de porcentagem, e a CPU será carregada à toa.

• Imagens: JPEG, PNG, WebP, AVIF já são compactados internamente.
• Vídeos: MP4, WebM, MKV contêm fluxo de vídeo altamente compactado.
• Áudio: MP3, AAC, OGG são compactados por natureza.
• Arquivos: ZIP, RAR, 7z, gz já são contêineres compactados.

Para esses recursos, Accept-Encoding não trará economia no corpo. Além disso, o servidor geralmente não os compacta novamente, pois é configurado por lista de tipos MIME.

O que vale a pena compactar

• HTML, CSS, JavaScript.
• Respostas JSON e XML de APIs.
• Texto simples, CSV, logs.
• SVG, porque é basicamente texto.

Dica: Se você baixa principalmente arquivos de mídia, a economia com compactação será quase zero. Aqui, o ganho vem de outra coisa: solicitar apenas os tamanhos e formatos desejados, e não o fato da compactação. Mas isso já é tema de gestão de tráfego, não de compactação em si.

Resultado esperado. Você não gasta recursos compactando formatos binários e aplica compactação apenas onde ela realmente ajuda.

✅ Verificação: Você consegue dizer em um segundo se vale a pena compactar um tipo específico de resposta. Compreensão formada.

Verificação do resultado

Hora de garantir que tudo está configurado corretamente. Siga o checklist.

Checklist de funcionamento

1. Seu cliente envia o cabeçalho Accept-Encoding com os algoritmos desejados.
2. A resposta contém Content-Encoding com um desses algoritmos em recursos de texto.
3. O script de medição mostra um volume de rede menor que o não compactado, pelo menos setenta por cento para texto.
4. Através do proxy Proxeon, a compactação é mantida e os números coincidem com a solicitação direta.
5. A descompactação não gera erros e os dados são lidos corretamente.
6. Formatos binários não são compactados.

Como testar

1. Pegue três endpoints diferentes: um com JSON, um com HTML, um com imagem.
2. Execute cada um através do seu script de medição.
3. Verifique se nos dois primeiros a economia é alta e no terceiro próxima de zero.

Indicadores de sucesso. Para uma API de texto, você vê consistentemente economia na faixa de setenta a noventa por cento. Para mídia, a economia é mínima, e isso é normal. Através do proxy, os números não pioram.

✅ Verificação: Todos os seis itens do checklist foram atendidos. A compactação está configurada e medida corretamente.

Erros comuns e soluções

Abaixo estão problemas frequentes no formato problema, causa, solução.

A resposta não é compactada, embora Accept-Encoding tenha sido enviado

Causa: o servidor não suporta compactação para esse tipo de conteúdo ou para respostas desse tamanho. Solução: tente outro algoritmo e verifique se o recurso é texto e grande o suficiente.

Economia não é visível no curl, size_download não muda

Causa: a flag --compressed mostra o tamanho após a descompactação. Solução: meça o volume de rede separadamente com um script sem descompactação automática, como nos passos de Python e Node.

A biblioteca retorna lixo em vez de texto

Causa: você desativou a descompactação automática, mas não descompactou o fluxo manualmente. Solução: identifique o Content-Encoding e aplique a função de descompactação correspondente.

Erro ao descompactar deflate

Causa: o servidor enviou deflate puro sem o wrapper. Solução: chame a descompactação com o parâmetro wbits menos quinze.

Através do proxy, a compactação desaparece

Causa: no caminho, há um nó que altera cabeçalhos, geralmente o CDN do site de destino. Solução: compare a solicitação direta e a via proxy e identifique o elo. O proxy Proxeon transmite cabeçalhos de forma transparente, então o problema geralmente está no servidor.

Tamanho da resposta diferente em medições repetidas

Causa: o conteúdo é dinâmico e muda de uma solicitação para outra. Solução: faça a média de várias medições e compare com os mesmos parâmetros de solicitação.

Content-Length ausente

Causa: a transmissão chunked não informa o comprimento antecipadamente. Solução: conte os bytes manualmente à medida que lê o fluxo, como nos exemplos de script.

Compactação dupla sobrecarrega a CPU

Causa: o conteúdo é compactado duas vezes em níveis diferentes. Solução: remova a compactação manual onde a biblioteca ou servidor já a faz.

Recursos adicionais

Quando o cenário básico estiver dominado, há espaço para evoluir.

Escolha da prioridade dos algoritmos

No cabeçalho Accept-Encoding, você pode especificar pesos usando valores q, indicando preferências ao servidor. Por exemplo,

Accept-Encoding: zstd;q=1.0, br;q=0.9, gzip;q=0.8

Cache de dados descompactados

Se você acessa o mesmo recurso repetidamente, armazene em cache o resultado descompactado do seu lado. Isso reduz tanto o tráfego quanto a carga na CPU para descompactação repetida.

Medição em massa para uma lista de URLs

Envolva o script de medição em um loop sobre uma lista de endpoints e compile uma tabela de economia. Assim, você encontrará os endpoints mais pesados sem compactação no seu projeto e cuidará deles primeiro.

Dica: Mantenha um registro da economia em bytes por dia. Multiplicando pelo preço do gigabyte, você obtém o benefício monetário visível da compactação habilitada ao usar proxy.

✅ Verificação: Você consegue compilar uma tabela resumida de economia para vários recursos com uma única execução do script.

FAQ

Devo sempre pedir brotli em vez de gzip?

Se você apenas baixa, a descompactação é rápida em todos os algoritmos, então pode pedir o mais eficiente. Na prática, inclua os três no Accept-Encoding: gzip, br, zstd. O servidor escolherá o melhor disponível.

Quanto tráfego a compactação economiza em uma API de texto?

Geralmente de setenta a noventa por cento. Ou seja, uma resposta que pesava um gigabyte passará pela rede como cento e cinquenta ou duzentos megabytes. A economia ao pagar por gigabyte é direta e perceptível.

A compactação afeta a velocidade da resposta?

Menos dados são transmitidos mais rápido, especialmente em canais lentos. O pequeno atraso na compactação no servidor geralmente é mais do que compensado pela redução no tempo de transmissão.

Por que o curl mostra o mesmo tamanho com e sem a flag de compactação?

Porque --compressed exibe o tamanho do corpo já descompactado. O volume real de rede é menor. Meça o fluxo bruto separadamente com um script.

Posso compactar o corpo de uma solicitação POST?

Sim, para isso o cliente define Content-Encoding na solicitação, mas o servidor precisa saber descompactar. Nem todos os servidores suportam, então verifique a documentação da API.

A compactação funciona através do proxy Proxeon?

Sim. O proxy transmite os cabeçalhos Accept-Encoding e Content-Encoding de forma transparente, portanto toda a economia é mantida. Por isso, é vantajoso medir diretamente pelo proxy, em condições reais.

O que fazer se o servidor não enviar compactação?

Verifique se você está pedindo compactação e se o recurso é texto. Se o servidor ainda assim não compactar, você não pode mudar o servidor de terceiros, mas pode escolher outro endpoint ou compactar os dados na sua camada de cache.

Vale a pena compactar imagens via Accept-Encoding?

Não. Formatos como JPEG e WebP já são compactados. A compactação adicional não trará ganho e apenas sobrecarregará a CPU.

Como escolher entre zstd e brotli?

Para download, a diferença no tráfego é de alguns pontos percentuais. Inclua ambos no Accept-Encoding e deixe o servidor decidir. Se o servidor suportar apenas um, você receberá exatamente esse.

Preciso de Vary no trabalho do cliente?

Como cliente, você não define Vary; o servidor o define. Mas entendê-lo é útil: ele explica por que o cache às vezes entrega a versão compactada e às vezes a não compactada.

Conclusão

Você percorreu o caminho da teoria até as medições práticas. Agora você entende como a compactação é negociada via Accept-Encoding, Content-Encoding e Vary. Sabe pedir compactação em curl, Python e Node.js, e, principalmente, medir o volume real de rede antes e depois. Você sabe por que a resposta às vezes chega não compactada e como diagnosticar as três causas típicas. Você entendeu as armadilhas: compactação dupla, fluxo corrompido e descompactação manual. E você não desperdiça mais recursos compactando imagens, vídeos e arquivos.

O que fazer agora. Execute o script de medição em todos os endpoints principais do seu projeto. Encontre aqueles onde a compactação não está ativada e peça-a explicitamente. Mantenha um registro dos bytes economizados para ver o benefício monetário ao usar o proxy Proxeon. Quando dominar o cenário básico, avance para medição em massa por lista de URLs e prioridades de algoritmos com valores q.

A compactação é uma das formas mais baratas de reduzir sua conta de tráfego. Um cabeçalho corretamente enviado pode reduzir o volume de dados várias vezes. Agora essa ferramenta está em suas mãos, e você pode aplicá-la com consciência e números precisos.