# 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:

```js
// 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](https://quantumproxies.io/blog/headless-browser-vs-http-requests-cost) mostra a diferença de 10-50x que torna essa decisão importante.

![Uma página de produto como o proxy a cobra: uma foto em resolução máxima de 2,2 MB e as fontes, folhas de estilo e scripts ao redor, contra o HTML enxuto que você realmente analisa, muitas vezes abaixo de 150 KB. O quadro lista os pesos: 2-5 MB por renderização completa de navegador e uma conta 60-90% menor depois que os recursos são bloqueados.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785335198/blog/generated/qp-b9-068-diag1.png)
*Você paga pela página inteira, mas analisa apenas uma fração dela — bloquear ativos é a maior vitória econômica disponível.*

## 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:

```python
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:

```python
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](https://quantumproxies.io/blog/shopify-products-json-scraping) 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](https://quantumproxies.io/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](https://quantumproxies.io/residential-proxies) 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](https://quantumproxies.io/blog/residential-proxy-pricing-per-gb-explained).

![Um route handler do Playwright que aborta toda solicitação de imagem, mídia, fonte e folha de estilo e deixa todo o resto seguir. O quadro divide os recursos: bloquear as imagens, mídias, fontes e CSS cobrados mas não usados; manter o HTML, o JSON e as chamadas XHR ou fetch que trazem os dados, e testar se a página ainda os renderiza.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785335199/blog/generated/qp-b9-068-diag2.png)
*Bloqueie os recursos cobrados mas não usados; mantenha os endpoints HTML, JSON e XHR que carregam seus dados reais.*

[Faça scraping de forma mais enxuta em proxies residenciais com cobrança por GB](https://quantumproxies.io/residential-proxies)

## 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](https://quantumproxies.io/blog/large-scale-web-scraping-architecture).

[Obtenha conteúdo analisado sem os bytes desperdiçados](https://quantumproxies.io/scraper-api)