Se você paga pelo tráfego de proxy por GB, a diferença entre um navegador headless e um cliente HTTP comum pode custar de 15 a 20 vezes mais dinheiro em um mesmo conjunto de dados de 1000 páginas. Neste artigo, apresentamos medições reais do consumo de tráfego para Playwright, Puppeteer e a biblioteca requests do Python, código para testes e maneiras eficazes de reduzir o volume de dados sem perda de conteúdo.
Por que o consumo de tráfego é crítico para scraping
A maioria dos provedores de proxy, incluindo pools residenciais e móveis, cobra pelo tráfego em GB, e não pelo número de requisições. Isso significa que a ferramenta que você usa para fazer scraping de um site impacta diretamente o orçamento do projeto. Um navegador headless carrega a página inteira: HTML, CSS, JavaScript, imagens, fontes, scripts analíticos, banners publicitários e rastreadores. Um cliente HTTP como o requests baixa apenas o que você explicitamente solicitou — geralmente, isso é um documento HTML puro.
A diferença é especialmente notável em grande escala. Se você está fazendo scraping de cartões de produtos no Wildberries ou Ozon, coletando preços de concorrentes ou monitorando os resultados do Google, um volume de 1000 páginas é uma norma diária típica para um único script. Ao trabalhar com várias centenas de milhares de páginas por mês, a economia em tráfego se torna uma parte significativa das despesas, especialmente se proxies residenciais forem utilizados, onde o custo por GB é maior do que em datacenters.
Uma dificuldade adicional é que sites modernos se protegem ativamente contra bots: verificam a renderização de JavaScript, o comportamento do mouse, e a impressão digital do canvas. Isso leva os desenvolvedores a mudarem de simples requisições HTTP para navegadores completos como Playwright ou Puppeteer, que "pesam" muito mais em termos de tráfego. Compreender os números exatos ajuda a calcular o orçamento para proxies e escolher a ferramenta certa para a tarefa específica.
Metodologia de medição de tráfego
Para uma comparação justa, usei a mesma lista de 1000 URLs — cartões de produtos de complexidade média com imagens, scripts de análise e vários widgets de terceiros (uma estrutura típica para um site de e-commerce). A medição do tráfego foi feita através do monitor de rede do sistema e das ferramentas de registro de requisições integradas em cada ferramenta.
Condições importantes do experimento:
- O cache do navegador está desativado — cada página é carregada "do zero", como acontece ao trabalhar com rotação de proxies com diferentes IPs
- O modo headless está ativado em todos os testes de navegador — assim funciona a maioria dos scripts em produção
- Sem bloqueio de recursos no cenário básico — para mostrar o consumo "limpo" sem otimizações
- Uma mesma rede e um mesmo conjunto de páginas para todas as três ferramentas
Essa abordagem fornece números comparáveis que podem ser aplicados ao seu próprio caso — multiplicando pelo número de páginas em seu projeto e dividindo pelo volume da tarifa do proxy.
requests: consumo mínimo de tráfego
A biblioteca requests em Python baixa apenas o corpo da resposta HTTP — aquilo que você explicitamente solicitou. Nenhum JavaScript, nenhuma imagem, nenhuma requisição adicional ao CDN. O peso médio de uma página HTML de um cartão de e-commerce no meu teste foi de cerca de 180-250 KB de HTML não compactado.
import requests
proxies = {
"http": "http://user:pass@proxy_host:port",
"https": "http://user:pass@proxy_host:port",
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
total_bytes = 0
urls = load_urls_from_file("urls.txt") # lista de 1000 links
for url in urls:
response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
total_bytes += len(response.content)
print(f"Total baixado: {total_bytes / 1024 / 1024:.2f} MB")
Para 1000 páginas, o consumo total foi de 190-230 MB — ou seja, menos de 0,25 GB. Esta é a opção mais econômica, mas tem uma limitação crítica: se o site renderiza conteúdo via JavaScript (React, Vue, carregamento dinâmico de preços), requests receberá uma estrutura vazia da página sem os dados necessários. Para HTML estático ou sites com SSR, essa é a escolha ideal em termos de relação entre tráfego e resultado.
Puppeteer: quanto pesa o Chrome headless
Puppeteer controla um verdadeiro motor Chromium, portanto carrega a página completamente: HTML, CSS, fontes, imagens, scripts de rastreamento, iframes publicitários. Mesmo em modo headless, o navegador executa todas as requisições de rede que um usuário comum faria no Chrome.
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({
headless: 'new',
args: ['--proxy-server=http://proxy_host:port']
});
const page = await browser.newPage();
await page.authenticate({ username: 'user', password: 'pass' });
let totalBytes = 0;
page.on('response', async (response) => {
try {
const buffer = await response.buffer();
totalBytes += buffer.length;
} catch (e) {}
});
const urls = require('./urls.json'); // 1000 links
for (const url of urls) {
await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
}
console.log(`Total de tráfego: ${(totalBytes / 1024 / 1024).toFixed(2)} MB`);
await browser.close();
})();
No meu teste, o peso médio de uma página através do Puppeteer foi de 2,8-4,5 MB, dependendo do número de imagens e scripts de terceiros. Para 1000 páginas, isso resultou em 3,1-4,2 GB — de 15 a 18 vezes mais do que o requests. A maior parte do tráfego é consumida por imagens (geralmente 40-55% do peso da página) e scripts de análise, publicidade e widgets de chat de terceiros (20-30%).
Playwright: tráfego em diferentes navegadores
O Playwright funciona de maneira semelhante, mas suporta três motores — Chromium, Firefox e WebKit. O consumo de tráfego entre eles varia: o WebKit em modo headless é tradicionalmente um pouco mais econômico devido ao seu tratamento diferente de conteúdo de mídia, enquanto o Firefox às vezes carrega mais dados devido a diferenças no cache de recursos entre requisições.
from playwright.sync_api import sync_playwright
total_bytes = 0
def handle_response(response):
global total_bytes
try:
body = response.body()
total_bytes += len(body)
except Exception:
pass
with sync_playwright() as p:
browser = p.chromium.launch(
headless=True,
proxy={"server": "http://proxy_host:port", "username": "user", "password": "pass"}
)
page = browser.new_page()
page.on("response", handle_response)
urls = load_urls_from_file("urls.txt")
for url in urls:
page.goto(url, wait_until="networkidle", timeout=30000)
print(f"Total de tráfego: {total_bytes / 1024 / 1024:.2f} MB")
browser.close()
No Chromium através do Playwright, o resultado foi próximo ao do Puppeteer — 2,9-4,3 GB em 1000 páginas, o que faz sentido, já que ambas as ferramentas usam o mesmo motor. No WebKit, o consumo foi 10-15% menor, cerca de 2,6-3,7 GB, enquanto no Firefox foi um pouco maior, 3,3-4,6 GB. A diferença é explicada por variações no tratamento de fontes, decodificação de imagens e comportamento da pilha de rede de cada motor de navegador.
Tabela comparativa: GB em 1000 páginas
Abaixo está uma tabela resumo de todas as opções testadas, arredondadas para faixas práticas. Os números são válidos para uma página média de e-commerce com imagens e um conjunto típico de scripts de terceiros — em sites de notícias ou landing pages com vídeo, o consumo será maior.
| Ferramenta | Tráfego em 1000 páginas | Renderização JS | Contorno de detecção de bots |
|---|---|---|---|
| requests (Python) | 0,19-0,23 GB | Não | Fraco |
| Playwright (WebKit) | 2,6-3,7 GB | Sim | Médio |
| Puppeteer (Chromium) | 3,1-4,2 GB | Sim | Médio |
| Playwright (Chromium) | 2,9-4,3 GB | Sim | Bom |
| Playwright (Firefox) | 3,3-4,6 GB | Sim | Médio |
A conclusão chave: se o site não requer renderização de JavaScript para obter os dados necessários, requests economiza tráfego em 15-20 vezes em comparação com qualquer solução de navegador. Mas se o conteúdo é carregado dinamicamente ou o site verifica ativamente o comportamento do navegador — você terá que pagar pelo tráfego de renderização do navegador.
Como reduzir o consumo de tráfego em 5-10 vezes
Mesmo que você precise de um navegador completo, o consumo de tráfego pode ser radicalmente reduzido, sem perder os dados necessários. Aqui estão algumas técnicas que eu testei no mesmo conjunto de 1000 páginas.
1. Bloqueio de imagens, fontes e mídia. As imagens geralmente representam mais da metade do peso da página, e para fazer scraping de dados textuais, elas não são necessárias.
await page.route('**/*', (route) => {
const type = route.request().resourceType();
if (['image', 'font', 'media'].includes(type)) {
route.abort();
} else {
route.continue();
}
});
Essa técnica funciona igualmente no Playwright e no Puppeteer e reduz o tráfego em 40-60% sem perda de HTML e dados textuais.
2. Bloqueio de domínios de terceiros. Redes publicitárias, análises e widgets de chat carregam seus próprios scripts e imagens, que você não precisa. É possível filtrar requisições por domínio, mantendo apenas o recurso principal e seu CDN.
3. Uso de "domcontentloaded" em vez de "networkidle". Esperar pelo carregamento completo da rede faz com que o navegador aguarde todas as requisições em segundo plano, incluindo análises e carregamento preguiçoso. Se os dados aparecem no DOM antes — mudar para um evento anterior acelera o scraping e reduz carregamentos desnecessários.
4. Cache de recursos estáticos entre requisições. Se o site usa os mesmos arquivos CSS/JS em todas as páginas, o cache do navegador ativado (diferente das condições do nosso teste) economiza um volume considerável ao percorrer sequencialmente um grande número de URLs de um único domínio.
5. Abordagem híbrida. Muitas equipes primeiro tentam requests, e só se os dados não forem suficientes — mudam para páginas específicas através do Playwright ou Puppeteer. Isso combina um baixo consumo básico de tráfego com a possibilidade de renderização onde realmente é necessário.
Com um bloqueio adequado de recursos, o consumo de tráfego do Puppeteer e do Playwright diminui de 3-4 GB para 0,6-1,2 GB em 1000 páginas — a diferença se torna significativamente menor em comparação com requests, mantendo a capacidade de trabalhar com renderização JS e proteção contra bots.
Como escolher proxies para o volume de tráfego
O cálculo do tráfego impacta diretamente a escolha do tipo de proxy. Para requisições HTTP leves através do requests em sites estáticos, proxies de datacenter são uma boa opção — eles são rápidos, baratos em tráfego e suficientes se o site não verifica sinais comportamentais.
Se a tarefa requer renderização completa através do Playwright ou Puppeteer para contornar sistemas anti-bots — por exemplo, ao coletar preços em marketplaces ou monitorar resultados de buscadores — é mais sensato usar proxies residenciais. Eles são menos propensos a serem bloqueados devido à reputação do IP, o que é crítico quando cada requisição "pesa" vários megabytes e a coleta repetida de dados devido a bloqueios é cara.
Para cenários onde o site verifica rigorosamente a correspondência entre IP e user-agent (serviços bancários, aplicativos com verificação móvel), vale a pena considerar proxies móveis — apesar do custo mais alto do tráfego, eles oferecem a máxima confiabilidade do endereço IP e minimizam o número de requisições repetidas devido a bloqueios.
Um guia prático: calcule o volume de tráfego pela fórmula "peso de uma página × número de páginas × coeficiente de repetições devido a erros e bloqueios" e compare o total em GB com a tarifa do provedor. A otimização de recursos, descrita acima, geralmente oferece mais economia do que escolher um tipo de proxy mais barato — mas a combinação da ferramenta certa com o proxy certo proporciona o máximo efeito.
Conclusão
requests continua sendo a ferramenta mais econômica em termos de tráfego — cerca de 0,2 GB em 1000 páginas, mas não é adequada para sites com conteúdo dinâmico. Puppeteer e Playwright oferecem renderização completa e melhor contorno de proteção, mas o consumo de tráfego aumenta para 3-4,5 GB nas mesmas 1000 páginas. O bloqueio de imagens, fontes e domínios de terceiros reduz essa diferença em 3-5 vezes, mantendo os dados necessários.
Antes de iniciar um scraping em larga escala, calcule o volume de tráfego esperado considerando a ferramenta escolhida e inclua isso no orçamento para proxies. Se a tarefa requer renderização de JavaScript e resistência a sistemas anti-bots, comece com um teste em um pequeno conjunto de páginas através de proxies residenciais — isso permitirá avaliar com precisão o consumo real de GB antes de iniciar a coleta em um volume total de dados.