Como reduzir os custos de banda de proxy ao fazer scraping em grande escala

Proxies residenciais são cobrados por gigabyte, então em um plano por GB sua largura de banda é sua fatura. O problema é que um scraper mal ajustado desperdiça a maior parte dos bytes que paga, baixando imagens, fontes, vídeos e scripts de rastreamento que nunca são usados, buscando novamente páginas que não mudaram, e renderizando navegadores completos quando uma simples requisição HTTP seria suficiente. A boa notícia é que quase todo esse desperdício é fácil de cortar, e um scraper bem ajustado costuma usar menos da metade da largura de banda de um não ajustado para os mesmos dados.

Este é um guia prático para fazer exatamente isso. Nove táticas, ordenadas aproximadamente por impacto, para coletar os mesmos dados através dos seus proxies residenciais pagando por uma fração dos bytes. É o complemento de eficiência de custo à mudança por GB abordada em proxies residenciais cobrados por largura de banda.

1. Não renderize um navegador a menos que seja necessário

Esta é a maior alavanca isolada. Um navegador headless baixa tudo que a página referencia: imagens, CSS, fontes web, vídeo, análises, scripts de anúncios. Para a maioria dos scrapings, você não precisa de nada disso. Se os dados que você quer estão no HTML inicial ou acessíveis via uma API (próxima seção), pule o navegador completamente e use um cliente HTTP simples, requests, httpx ou Scrapy. Um único GET HTTP pode representar uma fração minúscula dos bytes que uma renderização completa de navegador consome.

Reserve o navegador para páginas que genuinamente exigem execução de JavaScript para produzir os dados. Na dúvida, busque primeiro o HTML bruto e verifique se os valores desejados já estão lá.

2. Acesse a API JSON, não o HTML

Muitos sites renderizam seu conteúdo a partir de um endpoint JSON de backend que a página chama após o carregamento. Buscar esse endpoint diretamente, em vez da página HTML completa e seus recursos, costuma representar uma fração dos bytes e fornece dados limpos e estruturados sem necessidade de parsing. Abra a aba de rede do seu navegador, encontre a requisição que retorna os dados (geralmente um XHR/fetch retornando JSON) e chame-a diretamente através do proxy. Uma resposta JSON enxuta pode substituir uma página pesada mais uma renderização de navegador.

3. Bloqueie tipos de recursos pesados quando for necessário usar um navegador

Quando uma página realmente precisa de renderização, não deixe o navegador baixar o que você não vai usar. Tanto o Playwright quanto o Puppeteer permitem interceptar requisições e abortar imagens, mídia, fontes e frequentemente folhas de estilo antes que cheguem ao proxy, o que tipicamente corta a largura de banda em mais da metade. No Playwright:

await context.route("**/*", (route) => {
  const type = route.request().resourceType();
  if (["image", "media", "font"].includes(type)) {
    return route.abort();          // never downloaded, never billed
  }
  return route.continue();
});

Mantenha document, script, xhr e fetch; descarte o resto. O mesmo padrão e as especificidades do Chromium estão em como usar proxies residenciais com Playwright.

4. Mantenha a compressão ativada

Texto se comprime aproximadamente de 5 a 10x, então uma resposta HTML codificada em gzip ou brotli representa uma fração do tamanho bruto. A maioria dos clientes HTTP envia Accept-Encoding: gzip, deflate, br e descomprime de forma transparente por padrão, mas verifique se você não desativou isso, e nunca remova o cabeçalho. Se você está definindo cabeçalhos manualmente, inclua-o:

headers = {"Accept-Encoding": "gzip, br", "User-Agent": "..."}

Os bytes que atravessam o proxy são os comprimidos, então isso é uma redução direta e gratuita no que você é cobrado.

5. Use requisições condicionais para que páginas inalteradas custem quase nada

Para qualquer rastreamento recorrente, não baixe novamente páginas às cegas. As requisições condicionais HTTP permitem que o servidor diga “nada mudou” em uma pequena resposta 304 em vez de reenviar todo o corpo. Armazene o ETag ou Last-Modified de cada busca e envie-o de volta:

# On refetch, send the stored validator
headers = {"If-None-Match": stored_etag}      # or If-Modified-Since
r = client.get(url, headers=headers)
if r.status_code == 304:
    pass   # unchanged: a few bytes instead of the full page

Um 304 custa quase nada comparado a uma página completa, e em um trabalho de monitoramento onde a maioria das páginas raramente muda, isso sozinho pode reduzir drasticamente a largura de banda.

6. Não busque novamente o que não mudou

Relacionado, mas mais amplo que os validadores HTTP: rastreie o que você já coletou e pule isso. Use os timestamps lastmod do sitemap para encontrar URLs alteradas, mantenha um hash de conteúdo por página e pule o reprocessamento de conteúdo idêntico, e elimine duplicatas na fronteira do seu rastreamento para não buscar a mesma URL duas vezes em uma execução. O gigabyte mais barato é aquele que você nunca baixa.

7. Busque apenas os bytes de que precisa

Se você só precisa dos cabeçalhos de um arquivo ou do primeiro bloco (uma verificação de metadados, uma checagem de content-type), não baixe o arquivo inteiro. Uma requisição HEAD retorna cabeçalhos sem corpo, e uma requisição Range puxa apenas os bytes que você especifica onde o servidor suporta isso:

client.head(url)                                   # headers only, no body
client.get(url, headers={"Range": "bytes=0-2047"}) # first 2 KB only

Isso importa mais quando seu rastreamento toca em mídia grande, PDFs ou downloads onde você só precisa de uma pequena parte ou apenas metadados.

8. Torne as retentativas e a segmentação geográfica eficientes

Toda tentativa falha ainda gasta largura de banda, então retentativas desperdiçadoras inflam silenciosamente sua fatura. Recue e limite as retentativas em vez de martelar uma URL que falha, e evite filtros geográficos excessivamente restritos (país + cidade + ASN ao mesmo tempo) que causam falhas e novas tentativas quando nenhum IP correspondente está disponível, afrouxe um filtro em vez disso. Configure timeouts sensatos para que uma resposta travada não se arraste, e ajuste sua estratégia de sessão ao trabalho para não reestabelecer fluxos desnecessariamente. Requisições eficientes são requisições baratas.

9. Meça bytes por registro

Você não pode cortar o que não mede. Acompanhe a largura de banda por trabalho e, melhor ainda, bytes por registro extraído com sucesso, e o desperdício se revela: uma página que custa megabytes por linha geralmente está puxando recursos que você poderia bloquear ou renderizando quando poderia ter acessado uma API. Registre isso, observe a tendência e otimize os piores infratores primeiro.

Uma nota sobre fazer isso de forma responsável

Cortar largura de banda não é apenas mais barato para você, é mais leve para os sites dos quais você coleta: requisições menos numerosas e menores significam menos carga em seus servidores. Isso alinha eficiência de custo com boa conduta. Continue coletando dados públicos, respeite os termos e limites de taxa de cada site, e deixe a eficiência reduzir sua pegada. Nossa política de uso aceitável é a fonte de verdade sobre o que é permitido na Shifter.

Perguntas frequentes

O que consome mais largura de banda ao fazer scraping através de proxies? A renderização completa de navegador, por uma margem considerável, porque baixa todas as imagens, fontes, vídeos e scripts da página. Cortar a renderização (ou bloquear tipos de recursos pesados quando for necessário renderizar) é a mudança de maior impacto que você pode fazer.

Bloquear imagens e fontes prejudica o scraping? Geralmente não, você raramente precisa delas para extração de dados. Teste se o site não carrega o conteúdo alvo de forma preguiçosa (lazy-load) atrás de imagens; para a grande maioria dos trabalhos, bloquear requisições de imagem, mídia e fonte é seguro e corta substancialmente a largura de banda.

Proxies residenciais cobram por requisições falhas ou bloqueadas? Os bytes que atravessam o proxy são cobráveis, então tentativas falhas e retentativas ainda custam largura de banda. É por isso que retentativas eficientes, timeouts sensatos e evitar filtros geográficos excessivamente restritos (que causam falhas) importam para sua fatura.

Acessar a API JSON de um site é permitido? Chamar um endpoint público que a própria página usa é prática comum e muito mais eficiente, mas os termos e limites de taxa do site ainda se aplicam. Colete de forma responsável e obtenha aconselhamento jurídico para qualquer coisa incerta.

Quanto posso economizar realisticamente? Varia de acordo com o alvo, mas pular a renderização desnecessária, bloquear recursos pesados e não buscar novamente páginas inalteradas costumam cortar a largura de banda total em mais da metade para os mesmos dados extraídos.

Conclusão

Em um plano por GB, eficiência de largura de banda é eficiência de custo, e a maioria dos scrapers deixa muito dinheiro na mesa: renderizando quando poderiam buscar, baixando recursos que nunca leem, e puxando novamente páginas que nunca mudaram. Trabalhe nessa lista, pule o navegador quando puder, acesse a API, bloqueie recursos pesados, mantenha a compressão ativada, use requisições condicionais, não busque novamente páginas inalteradas, busque apenas o que precisa, torne as retentativas eficientes e meça, e os mesmos dados voltam por uma fração dos bytes.

Essa eficiência se soma à qualidade do pool: IPs limpos significam menos bloqueios e retentativas, o que significa menos bytes desperdiçados, então vale a pena escolher os proxies certos para scraping junto com o ajuste do seu cliente. Veja os planos por GB na página de preços, depois aponte um scraper bem ajustado para o gateway residencial e observe os bytes caírem.