Como reduzir o tráfego do parser em 5 vezes sem perda de dados: 7 dicas para engenheiros de dados

Cada megabyte extra de tráfego do parser representa ou o pagamento a um provedor de proxies, ou o risco de atingir limites e receber um banimento por IP. Se você está coletando preços do Wildberries, Ozon ou monitorando anúncios no Avito através de centenas de endereços proxy, a economia de tráfego impacta diretamente o orçamento do projeto. Neste artigo, apresentamos técnicas técnicas específicas que permitem reduzir o volume de dados transmitidos em 4-5 vezes, mantendo a integridade e precisão das informações extraídas.

Por que o tráfego do parser afeta o orçamento

A maioria dos provedores de proxies cobra proxies residenciais e móveis com base no volume de gigabytes transmitidos, e não pelo tempo de uso. Se seu parser carrega a página do produto Wildberries completamente — com imagens, scripts de recomendações, rastreadores de análise e fontes — você paga por 2-3 MB por cartão, embora realmente precise de 15-20 KB de texto: nome, preço, classificação, disponibilidade.

Ao escalar para 50.000-100.000 cartões por dia, a diferença entre "carregar tudo" e "carregar apenas o necessário" se transforma em dezenas de gigabytes de tráfego extra diariamente. Isso não apenas gera custos com proxies, mas também aumenta a carga no site-alvo, o que aumenta a chance de ser atingido pela proteção anti-bot e receber um captcha ou banimento temporário de IP. A otimização do tráfego é ao mesmo tempo uma economia de dinheiro e uma redução do risco de bloqueios.

Há um terceiro efeito: quanto menos dados são transmitidos por requisição, mais rápido a própria requisição é executada. Isso permite aumentar o paralelismo — executar mais threads na mesma quantidade de proxies sem exceder os limites de velocidade impostos por navegadores anti-detectores como Dolphin Anty ou AdsPower ao trabalhar com sessões.

Técnica 1: Bloqueio de imagens, CSS e fontes

Se o parser funciona através de um navegador headless (Playwright, Puppeteer, Selenium) — a maneira mais rápida de reduzir o tráfego em 2-3 vezes é bloquear o carregamento de recursos estáticos que não afetam os dados no DOM. Imagens de produtos, fontes do site, vídeos e estilos CSS ocupam até 70% do peso da página, mas não participam da extração de texto e atributos.

from playwright.sync_api import sync_playwright

def block_heavy_resources(route, request):
    if request.resource_type in ["image", "media", "font", "stylesheet"]:
        route.abort()
    else:
        route.continue_()

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.route("**/*", block_heavy_resources)
    page.goto("https://example.com/product/123")
    html = page.content()
    browser.close()

A lógica semelhante é implementada no Puppeteer através de page.setRequestInterception(true) e no Selenium através da configuração do perfil do Chrome com o parâmetro profile.managed_default_content_settings.images: 2. Na prática, essa única configuração corta de 50% a 70% do tráfego ao fazer scraping de marketplaces, onde as páginas estão sobrecarregadas de conteúdo visual e banners publicitários.

Técnica 2: Requisições HTTP em vez de um navegador completo

Muitos usam Selenium ou Playwright onde não é necessário. Se a página não requer a execução de JavaScript para renderizar os dados (isso pode ser facilmente verificado ao abrir "Ver código da página" em vez de DevTools), é muito mais vantajoso pegar o HTML diretamente através das bibliotecas requests ou httpx em Python. Essa requisição pesa kilobytes, e não megabytes, porque não envolve a renderização do motor do navegador, chamadas de rede para rastreadores e recursos secundários.

import httpx

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
    "Accept-Encoding": "gzip, br",
    "Accept": "text/html,application/xhtml+xml"
}

proxies = {"http://": "http://user:pass@proxy_host:port",
           "https://": "http://user:pass@proxy_host:port"}

with httpx.Client(headers=headers, proxies=proxies, http2=True) as client:
    response = client.get("https://example.com/catalog/item/456")
    print(len(response.content), "bytes recebidos")

A transição da emulação de navegador para requisições HTTP diretas onde o site fornece HTML pronto sem renderização do cliente reduz o tráfego em 3-8 vezes. O único detalhe é que tais requisições são mais fáceis de diferenciar de um usuário real, portanto, para sites com proteção anti-bot rigorosa, é recomendável combinar esse método com proxies residenciais de qualidade, que fornecem IPs de provedores domésticos reais e reduzem a probabilidade de bloqueio da requisição.

Técnica 3: Parsing através de APIs JSON ocultas

Praticamente todos os marketplaces modernos — incluindo Wildberries, Ozon e Yandex.Market — renderizam cartões de produtos e listas através de APIs JSON internas, que são chamadas pelo frontend. Encontrar esses endpoints pode ser feito através da aba Network no DevTools, filtrando as requisições pelo tipo XHR/Fetch. Geralmente, uma dessas requisições retorna um JSON de 5-30 KB com dados limpos: id do produto, preço, desconto, estoque, classificação — sem um único byte de marcação HTML ou CSS.

A diferença no volume de dados transmitidos entre uma página HTML completa e uma chamada direta para a API JSON pode chegar a 10-15 vezes. Um adicional positivo — JSON é mais fácil de fazer parsing programaticamente: não são necessários seletores XPath, basta acessar o campo desejado pela chave do dicionário. A desvantagem — tais endpoints frequentemente requerem cabeçalhos específicos, tokens de sessão ou parâmetros de assinatura da requisição, que precisam ser extraídos previamente da página principal ou do aplicativo móvel.

Técnica 4: Compressão Gzip e Brotli

Mesmo que você precise pegar o HTML completo, a inclusão da compressão correta pode reduzir o tamanho da transmissão em 60-80%. Muitos parsers feitos à mão não enviam o cabeçalho Accept-Encoding: gzip, br, fazendo com que o servidor retorne uma resposta não compactada. As bibliotecas requests e httpx descompactam Gzip e Brotli automaticamente — é importante apenas indicar claramente o suporte à compressão nos cabeçalhos da requisição.

Brotli, em média, comprime HTML textual mais do que Gzip, em 15-20%, mas nem todos os servidores suportam esse algoritmo — é recomendável solicitar ambas as opções e permitir que o servidor escolha a melhor. Para APIs JSON, o efeito da compressão é ainda mais notável: chaves de dicionário repetidas ("price", "name", "rating") são comprimidas praticamente de forma ideal, reduzindo o peso da resposta em várias vezes.

Técnica 5: Requisições condicionais e cache

Se você monitora preços dos mesmos produtos várias vezes ao dia, a maior parte dos cartões entre as verificações não muda. Use os cabeçalhos If-Modified-Since e If-None-Match com o valor ETag obtido na primeira requisição. Se o conteúdo não mudou, o servidor retorna o status 304 Not Modified praticamente sem corpo de resposta — a economia de tráfego pode chegar a 95% em páginas que não mudaram.

import httpx

etag_store = {}

def fetch_with_cache(url, client):
    headers = {}
    if url in etag_store:
        headers["If-None-Match"] = etag_store[url]
    resp = client.get(url, headers=headers)
    if resp.status_code == 304:
        return None  # dados não mudaram
    etag_store[url] = resp.headers.get("ETag", "")
    return resp.content

Nem todos os sites suportam ETag corretamente, mas para aqueles que suportam, essa técnica se torna a forma mais eficaz de reduzir o tráfego durante monitoramentos regulares — você efetivamente paga apenas por mudanças reais nos dados, e não pelo recarregamento de conteúdo inalterado.

Técnica 6: Parsing seletivo de campos necessários

Às vezes, não é possível reduzir o tráfego de entrada do servidor — o site fornece a página completa independentemente da requisição. Nesse caso, a otimização ocorre na fase de processamento: não carregue a página novamente apenas para extrair mais um campo. Projete seletores XPath ou CSS de forma que, em uma única passagem pelo DOM, você extraia todos os atributos necessários — preço, nome, artigo, disponibilidade, classificação — em vez de fazer requisições repetidas para a mesma URL com diferentes parsers para diferentes tarefas.

Também é útil limitar a profundidade de navegação em páginas aninhadas. Se para monitorar preços são suficientes os dados da página da categoria (lista de produtos), não acesse a página de cada produto individualmente — isso gera tráfego duplicado, que muitas vezes não fornece novas informações, além de descrições e avaliações que não afetam o preço e a disponibilidade.

Técnica 7: Otimização do padrão de crawling

A deduplicação de URLs é uma técnica básica, mas frequentemente ignorada. Diretórios de marketplaces geram muitos links com conteúdo idêntico, mas com diferentes parâmetros de ordenação, tags UTM ou IDs de sessão. A normalização de URLs antes de colocá-las na fila (remoção de parâmetros de rastreamento, ordenação de parâmetros de consulta) elimina de 10% a 30% de requisições excessivas ao navegar por grandes diretórios.

A priorização da navegação com base na frequência de alteração dos dados também economiza tráfego: produtos com alta demanda e preços voláteis devem ser verificados a cada hora, enquanto itens raros — uma vez por dia. Esse cronograma adaptativo, em vez de um crawling uniforme de todos os cartões com a mesma periodicidade, reduz o volume total de requisições em 2-4 vezes sem perda de atualidade dos dados críticos.

Como isso se encaixa na estratégia de proxies

A redução do tráfego impacta diretamente a escolha do tipo de proxy. Se você está fazendo scraping de um grande volume de páginas com requisições HTTP diretas sem proteção anti-bot complexa, são suficientes proxies de data center rápidos e baratos — eles oferecem alta velocidade de transmissão a um custo baixo por gigabyte, o que é crítico ao fazer scraping em larga escala de milhares de cartões por dia.

Para sites com proteção rigorosa contra bots, onde é importante simular o comportamento de um usuário real, é melhor usar proxies residenciais — combinando-os com técnicas de bloqueio de recursos desnecessários, você obtém tanto baixo tráfego quanto alta confiabilidade do site em relação à requisição. E se o scraping for feito através de versões móveis das APIs dos marketplaces, onde os dados são mais compactos e o sistema anti-bot se concentra em faixas de IP móveis, vale a pena considerar proxies móveis para reduzir ainda mais o risco de bloqueios.

A combinação de "mínimo tráfego por requisição" + "tipo de proxy correto para a tarefa" permite reduzir simultaneamente os custos de infraestrutura e aumentar a velocidade de coleta de dados sem perder confiabilidade.

Tabela comparativa das técnicas

Técnica	Redução de tráfego	Dificuldade de implementação
Bloqueio de imagens/CSS/fontes	50-70%	Baixa
Requisições HTTP em vez de navegador	3-8 vezes	Média
APIs JSON ocultas	10-15 vezes	Alta
Compressão Gzip/Brotli	60-80%	Baixa
Requisições condicionais (ETag)	até 95% em páginas inalteradas	Média
Deduplicação de URL e priorização	2-4 vezes	Média

Checklist de implementação

• Verifique se a página alvo requer renderização JavaScript, ou se é possível pegar o HTML diretamente através de httpx/requests
• Configure o bloqueio de image/media/font/stylesheet em um navegador headless, se o navegador for realmente necessário
• Encontre APIs JSON internas através do DevTools → Network → XHR/Fetch
• Adicione os cabeçalhos Accept-Encoding: gzip, br em todas as requisições
• Implemente o armazenamento de ETag/Last-Modified para requisições condicionais em URLs repetidas
• Normalize e deduplice a fila de URLs antes do crawling
• Configure a frequência de crawling adaptativa com base na importância e volatilidade dos dados
• Escolha o tipo de proxy de acordo com o perfil final de tráfego — data center, residencial ou móvel

Conclusão

Reduzir o tráfego do parser em 5 vezes é um objetivo realista, se as técnicas forem aplicadas de forma sequencial: remover recursos desnecessários, mudar para requisições HTTP diretas ou APIs JSON onde possível, ativar compressão, usar requisições condicionais para dados inalterados e otimizar o próprio padrão de crawling. Cada um desses passos proporciona um efeito mensurável, e em conjunto, eles mudam radicalmente a economia do projeto de coleta de dados de marketplaces e outros sites.

Após a otimização do tráfego, é importante escolher a infraestrutura de proxies correta para o novo perfil de carga. Para coleta rápida e barata de grandes volumes de dados, proxies de data center são adequados, enquanto para trabalhar com sites com proteção rigorosa contra bots, proxies residenciais com IPs reais de provedores domésticos reduzem o risco de bloqueio mesmo durante scraping intenso.