Como Reduzir os Custos de Largura de Banda de Proxy: Corte Sua Conta de GB em 60-90%

Em proxies com cobrança por GB, sua conta é medida em bytes, não em requisições — e a maioria desses bytes são imagens e fontes que você nunca analisa. Veja como eliminá-los e cortar uma conta de GB residencial pela metade ou mais.

Em proxies com cobrança por GB, sua conta é medida em bytes, não em requisições — e a verdade desconfortável é que a maioria desses bytes são imagens, fontes e folhas de estilo que você nunca analisa. Uma única foto de produto em alta resolução pode ter 2,2 MB; uma renderização completa de uma página no navegador pode ter de 2 a 5 MB. O HTML enxuto do qual você realmente extrai dados costuma ter menos de 150 KB. Elimine o resto e uma conta de GB residencial cai de 60-90%. Este guia é o manual prático: bloqueie ativos, pule páginas inalteradas, comprima e direcione para JSON em vez de HTML.

Primeiro, saiba pelo que você está sendo cobrado

A largura de banda residencial é medida pela soma dos dados transmitidos em ambas as direções: cabeçalhos de requisição mais corpo da requisição, e cabeçalhos de resposta mais corpo da resposta. Isso significa que cada ativo que uma página carrega — cada imagem, fonte e script de rastreamento — aparece na sua fatura, mesmo que nada disso alimente seu analisador. O alvo da otimização é simples: baixe apenas os bytes dos quais você extrai dados. Todo o resto é desperdício pelo qual você está pagando.

Bloqueie ativos em um navegador sem cabeça

Se você está dirigindo um navegador, esta é a alavanca única mais poderosa. Playwright e Puppeteer permitem interceptar requisições e abortar os tipos de recursos que você não precisa. Bloquear imagens, mídias, fontes e folhas de estilo geralmente reduz o peso da página pela maioria — o DOM ainda é construído, então seus seletores e qualquer JSON de hidratação sobrevivem:

// Playwright: abort the resource types you never parse
await page.route('**/*', (route) => {
  const type = route.request().resourceType();
  if (['image', 'media', 'font', 'stylesheet'].includes(type)) {
    return route.abort();
  }
  return route.continue();
});
await page.goto(url, { waitUntil: 'domcontentloaded' });

Duas precauções: não bloqueie as chamadas XHR/fetch que carregam os dados que você deseja, e teste se a página ainda renderiza o que você precisa — bloquear demais pode quebrar a lógica própria de um site. Se você está ponderando entre um navegador e requisições simples, nossa análise do custo de renderização vs requisições HTTP mostra a diferença de 10-50x que torna essa decisão importante.

Pule páginas que não mudaram

O byte mais barato é aquele que você não baixa. Duas técnicas reduzem o desperdício de re-busca em trabalhos de monitoramento. Uma requisição HEAD puxa apenas cabeçalhos para verificar Content-Length ou Last-Modified antes de você se comprometer com o GET completo. Melhor ainda, um GET condicional envia o ETag ou timestamp da última vez e o servidor responde com 304 Not Modified com um corpo vazio quando nada mudou — você paga por alguns bytes de cabeçalho em vez da página inteira:

import requests

# conditional GET: 304 = near-zero bytes when unchanged
headers = {"If-None-Match": last_etag,
           "If-Modified-Since": last_seen}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)

if r.status_code == 304:
    pass  # unchanged, no body downloaded, no GB spent
else:
    process(r.content)
    last_etag = r.headers.get("ETag")

Para um scraper que verifica as mesmas páginas diariamente, os GETs condicionais sozinhos podem reduzir drasticamente a largura de banda, porque a maioria das páginas não muda entre as execuções.

Sempre aceite compressão

Texto comprime bem — HTML, JSON e CSS encolhem de 70-90% com gzip ou brotli — e você é cobrado pelo tamanho comprimido que realmente cruza a rede. Envie um cabeçalho Accept-Encoding e deixe o servidor comprimir. No requests do Python, isso está ativado por padrão quando você não interfere; em um cliente bruto, solicite explicitamente:

headers = {"Accept-Encoding": "gzip, deflate, br"}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)
# requests transparently decompresses; you're billed on the small size

Direcione para JSON, não HTML

A maior vitória estrutural é pular a página renderizada completamente. Muitos sites hidratam a partir de um endpoint JSON que carrega os mesmos dados em uma fração dos bytes — o preço e o estoque de um produto como uma resposta de API de 10 KB em vez de uma página renderizada de 3 MB. Encontre a chamada XHR na aba de Rede do seu navegador e acesse-a diretamente. Lojas Shopify são o exemplo clássico: o endpoint products.json entrega todo o catálogo sem nenhum HTML. Quando você pode ler a API, faça isso — é a diferença entre kilobytes e megabytes por registro.

Deixe a API contar os bytes para você

Se você prefere não ajustar manualmente as regras de bloqueio por site, uma Scraper API que renderiza apenas quando necessário e retorna markdown ou JSON analisado faz a eliminação de ativos para você — você recebe o conteúdo extraído, não os megabytes de onde ele veio. E em proxies residenciais com cobrança por GB as economias são diretas: menos bytes na rede é menos dólares na fatura, sem perder nada dos dados que você mantém. Para a visão completa do que um gigabyte realmente compra, veja nossa análise de preço por GB.

Faça scraping de forma mais enxuta em proxies residenciais com cobrança por GB

Perguntas frequentes

Como é calculada a largura de banda de proxy?

Pelos bytes totais transmitidos em ambas as direções: cabeçalhos de requisição mais corpo da requisição, e cabeçalhos de resposta mais corpo da resposta. Assim, cada imagem, fonte e script que uma página carrega conta para seu uso, não apenas o HTML que você analisa. É por isso que bloquear ativos não usados e pular páginas inalteradas se traduz diretamente em uma conta mais baixa em planos com cobrança por GB.

Bloquear imagens quebra o scraping?

Não se você for cuidadoso. Bloquear imagens, mídias, fontes e folhas de estilo deixa o DOM e o JavaScript intactos, então seus seletores e qualquer JSON de hidratação ainda funcionam — você está apenas pulando a carga visual. O risco é bloquear demais: nunca aborte as chamadas XHR/fetch que carregam seus dados, e teste se a página ainda produz o que você precisa antes de executar em escala.

Qual é a maior economia de largura de banda?

Direcionar para um endpoint JSON em vez de renderizar a página completa, onde houver. Uma resposta de API de 10 KB pode substituir uma renderização de 3 MB para o mesmo registro — uma redução de 99%. Depois disso, bloquear ativos em um navegador sem cabeça e usar GETs condicionais em re-raspagens são as maiores vitórias. A compressão é quase gratuita e deve estar sempre ativada.

Quanto posso economizar realisticamente?

Bloquear ativos geralmente reduz o peso de uma página renderizada em bem mais da metade; GETs condicionais podem reduzir a largura de banda de re-raspagem a quase zero para páginas que não mudam; e mudar de HTML para uma rota JSON é frequentemente uma redução de mais de 90% por registro. Juntos, uma redução de 60-90% em uma conta de GB residencial é uma meta realista para a maioria dos projetos.

Nada disso muda o que você extrai — muda o que você paga para extrair. Bloqueie os ativos que você nunca lê, pule as páginas que não mudaram, aceite compressão e prefira rotas JSON a renderizações completas. Em proxies com cobrança por GB, esses quatro hábitos rotineiramente reduzem uma conta em mais da metade. Para a arquitetura que escala isso em milhões de páginas, veja nosso guia sobre arquitetura de scraping em larga escala.

Obtenha conteúdo analisado sem os bytes desperdiçados