Como calcular e reduzir o consumo de tráfego ao usar proxy com pagamento por gigabyte

Quando você paga por cada gigabyte transferido, o tráfego deixa de ser algo abstrato e se transforma em dinheiro vivo. Um script descuidado que puxa imagens pesadas e vídeos pode consumir o orçamento do mês em uma noite. A boa notícia é que dá para controlar o gasto, e não é difícil fazer isso depois que você entende a mecânica.

Este guia vai ensinar você a calcular o tráfego antes de começar a tarefa, medir o consumo real e reduzi-lo drasticamente com técnicas simples. Falamos apenas da economia de tráfego que se aplica a qualquer plano com cobrança por volume, independentemente do tipo de proxy.

Introdução: por que o tráfego precisa ser calculado com antecedência

Com cobrança por gigabyte, cada requisição tem um preço. O problema é que esse preço fica invisível até chegar a fatura ou o saldo zerar. A maioria dos iniciantes calcula o gasto depois que acontece, mas o certo é o contrário: estimar o orçamento antes de começar e incluir uma margem.

O que você vai conseguir no final

Depois de ler o guia, você vai conseguir analisar qualquer página web pelo peso dos componentes, escrever um contador de tráfego simples em Python ou Node, aplicar técnicas de economia que reduzem o consumo de 70% a 95% e calcular o orçamento do projeto com inteligência. Você também vai entender quando compensa pagar por volume e quando escolher um plano ilimitado.

Para quem é este guia

• Para quem faz scraping e coleta de dados através de proxy.
• Para profissionais de automação que disparam requisições em lote.
• Para marketers e analistas que trabalham com fontes externas.
• Para todos que querem pagar menos pelo mesmo resultado.

O que você precisa saber antes

Ter uma noção básica de requisições HTTP é um diferencial, mas não é obrigatório. Vamos explicar os principais termos de forma simples. Para a parte prática, é útil ter um pouco de experiência com scripts em Python ou Node.js, mas entregamos o código pronto com comentários.

Quanto tempo você vai precisar

Ler e entender a teoria leva cerca de 30 minutos. Configurar o contador de tráfego leva de 15 a 20 minutos. Colocar as técnicas de economia em prática no seu projeto depende da complexidade, mas o básico você aplica em uma hora.

Preparação inicial: ferramentas e acessos

Antes de calcular e economizar tráfego, vamos montar um conjunto de ferramentas. Tudo é gratuito e funciona em Windows, macOS e Linux.

Ferramentas necessárias

• Python 3.10 ou mais recente - para os scripts de medição de tráfego.
• Node.js 18 ou mais recente - alternativa para quem tem afinidade com JavaScript.
• Biblioteca requests para Python - instalada com o comando pip install requests.
• Biblioteca Playwright - para trabalhar com navegador headless, instalada via pip install playwright e playwright install.
• Navegador com ferramentas do desenvolvedor - qualquer navegador moderno serve; o painel Network integrado é necessário para analisar páginas manualmente.
• Acesso ao painel de controle do seu serviço de proxy - é lá que você vê as estatísticas reais de tráfego.

Requisitos do sistema

Qualquer computador lançado nos últimos dez anos serve. 4 gigabytes de RAM são suficientes, mas para o navegador headless é mais confortável ter 8. Você vai precisar de cerca de 2 gigabytes de espaço em disco para os motores de navegador do Playwright.

O que instalar e configurar

1. Baixe e instale o Python no site oficial; durante a instalação, marque a opção de adicionar ao PATH.
2. Abra o terminal e confira a instalação com o comando python --version.
3. Instale a biblioteca de requisições com o comando pip install requests.
4. Se for trabalhar com navegador, instale o Playwright com pip install playwright e depois execute playwright install chromium.
5. Tenha em mãos os parâmetros de conexão do proxy: endereço, porta, login e senha.

Dica: Crie uma pasta separada para os experimentos com tráfego. Assim você não se perde nos arquivos e consegue reverter mudanças facilmente se algo der errado.

⚠️ Atenção: Nunca guarde login e senha do proxy diretamente no código que você vai enviar para algum lugar. Use variáveis de ambiente ou um arquivo de configuração separado que não caia em mãos erradas.

✅ Verificação: Se os comandos python --version e pip --version retornam os números de versão sem erros, a preparação foi concluída com sucesso.

Conceitos básicos em linguagem simples

Antes de contar bytes, vamos entender os termos. Sem jargão, de forma bem didática.

O que é tráfego

Tráfego é o volume de dados que passou pela sua conexão. Ele é composto pelo que você enviou ao servidor e pelo que o servidor respondeu. Na cobrança por gigabyte, as duas direções são contabilizadas, mas o tráfego de entrada (respostas do servidor) costuma ser várias vezes maior que o de saída.

Do que uma requisição é feita

Quando você abre uma página, o navegador envia uma requisição e recebe uma resposta. A resposta é composta por cabeçalhos (informações de serviço sobre tamanho, tipo, codificação) e corpo (o conteúdo em si: HTML, imagem, script). O corpo quase sempre pesa muito mais que os cabeçalhos.

Termos-chave

• Requisição GET - requisição comum para obter conteúdo. Retorna tanto os cabeçalhos quanto o corpo.
• Requisição HEAD - requisição apenas de cabeçalhos, sem corpo. Economiza tráfego quando você não precisa do corpo.
• Content-Length - cabeçalho que informa o tamanho do corpo da resposta em bytes.
• Accept-Encoding - cabeçalho em que você pede para o servidor comprimir a resposta.
• gzip e brotli - algoritmos de compressão que reduzem o peso de dados textuais em várias vezes.
• Redirecionamento - transferência de um endereço para outro. Cada redirecionamento é uma requisição extra e tráfego adicional.
• Navegador headless - navegador sem janela gráfica, controlado por código. Carrega tudo o que um navegador comum carrega, incluindo recursos pesados.

O princípio principal da economia

Não carregar o que não é necessário para a tarefa. Parece óbvio, mas é justamente a quebra dessa regra que consome dinheiro. Se você precisa do texto de uma ficha de produto, não precisa das fotos, dos vídeos de review, dos banners publicitários e dos rastreadores de analytics.

Como o peso de uma página é composto: uma análise real

O objetivo desta seção é mostrar com um exemplo concreto que a maior parte do peso de uma página normalmente não é necessária. Vamos pegar uma página típica de loja virtual.

Componentes do peso e a participação de cada um

Uma página moderna média pesa de 2 a 5 megabytes. O peso é distribuído mais ou menos assim:

• Imagens - 50 a 70 por cento do peso. Fotos de produtos, banners e ícones em alta resolução.
• Scripts JavaScript - 15 a 25 por cento. Lógica de interface, widgets, chats, contadores.
• Fontes - 5 a 10 por cento. Fontes personalizadas são carregadas em arquivos separados.
• Analytics e rastreadores - 5 a 15 por cento. Pixels, sistemas de estatística, scripts de publicidade.
• Vídeos e mídias - de zero a valores enormes. Vídeos que tocam automaticamente destroem o orçamento.
• Documento HTML - apenas 1 a 5 por cento. É aí que, na maioria das vezes, estão os dados que você precisa.

Conclusão prática

Se você precisa dos dados textuais do HTML, pode abrir mão de 90 a 95 por cento do peso da página. Uma página de cinco megabytes vira 100 a 200 kilobytes de HTML útil. Isso não é exagero, é o cenário típico.

Como analisar uma página manualmente

1. Abra a página no navegador.
2. Pressione F12 para abrir as ferramentas do desenvolvedor.
3. Vá para a aba Network.
4. Atualize a página pressionando F5.
5. Na parte inferior do painel, você verá o tamanho total dos dados carregados e o número de requisições.
6. Ordene as requisições pela coluna Size para ver os recursos mais pesados.
7. Fique de olho na coluna Type: img são imagens, script são scripts, font são fontes.

Dica: No painel Network existem filtros por tipo de recurso. Clique no botão Img para ver o peso total de todas as imagens. Normalmente esse número choca.

✅ Verificação: Você deve ver que o documento HTML pesa dezenas de vezes menos que a soma das imagens e scripts. Isso confirma que o principal potencial de economia está em abrir mão das mídias.

Etapa 1: Medindo o consumo real da sua tarefa

Objetivo desta etapa: aprender a calcular com precisão quanto tráfego o seu script consome, para gerenciar o gasto de forma consciente.

Medindo o tráfego em Python

A biblioteca requests permite saber o tamanho de cada resposta. Vamos somar o comprimento do corpo e o tamanho aproximado dos cabeçalhos.

1. Crie um arquivo traffic_counter.py na sua pasta de trabalho.
2. Inclua a importação da biblioteca: import requests.
3. Defina as configurações do proxy em um dicionário com as chaves http e https.
4. Antes do loop de requisições, crie uma variável total_bytes igual a zero.
5. Após cada requisição, adicione a ela o tamanho do conteúdo response.content.
6. Para precisão, adicione o tamanho dos cabeçalhos calculando o comprimento da representação em string deles.
7. No final, divida total_bytes por 1048576 para obter os megabytes.

A lógica é simples: len(response.content) retorna o número de bytes no corpo da resposta. Os cabeçalhos são calculados como a soma dos comprimentos das chaves e valores. Para a maioria das tarefas, o corpo da resposta é a parte principal do tráfego, então até um cálculo simples com content já oferece cerca de 95 por cento de precisão.

Ponto importante: response.content retorna os dados já descompactados se o servidor enviou uma resposta comprimida. O tráfego real na rede pode ter sido menor por causa da compressão. Para medir exatamente os bytes transmitidos, olhe o cabeçalho Content-Length da resposta, que mostra o tamanho do corpo como ele trafegou pela rede.

Cálculo preciso dos bytes transmitidos

1. Após a requisição, use response.headers.get('Content-Length').
2. Se o valor existir, use-o como o peso real do corpo em bytes.
3. Se o cabeçalho não existir (por exemplo, em transmissão por streaming), use o comprimento de content, lembrando que é o tamanho descompactado.

Medindo o tráfego em Node.js

Em Node, você pode usar o módulo https nativo ou a biblioteca axios. O princípio é o mesmo: somamos o tamanho dos dados recebidos.

1. Crie um arquivo traffic_counter.js.
2. Importe a biblioteca para as requisições.
3. Defina uma variável totalBytes com valor zero.
4. Para cada resposta, use o cabeçalho content-length ou calcule o tamanho do buffer de dados.
5. Adicione esse valor a totalBytes.
6. No final, exiba totalBytes dividido por 1048576 para obter os megabytes.

Dica: Registre o peso de cada requisição separadamente, não só o total. Assim você verá imediatamente qual URL consome mais e poderá otimizá-lo de forma direcionada.

Conferindo com as estatísticas do painel de controle

O seu contador e as estatísticas do serviço de proxy podem divergir um pouco. Isso é normal. Os motivos da divergência:

• O serviço considera todo o tráfego da conexão, incluindo pacotes de serviço e o estabelecimento do canal seguro.
• O seu contador considera apenas a carga útil das respostas.
• Cabeçalhos das requisições, trocas de DNS e novas conexões adicionam um pequeno overhead.

1. Execute seu script com 100 requisições e anote o resultado do seu contador.
2. Acesse o painel do serviço de proxy antes e depois da execução.
3. Anote a diferença nas leituras do painel.
4. Compare com o seu contador. Uma divergência de 10 a 20 por cento é normal; são os custos adicionais da conexão.

⚠️ Atenção: Sempre inclua o overhead da conexão no orçamento. O consumo real quase sempre é 10 a 20 por cento maior do que o cálculo da carga útil no lado do cliente.

✅ Verificação: Se o seu contador mostra um número próximo à diferença no painel de controle, com a correção do overhead, o cálculo está configurado corretamente e você pode confiar nas suas medições.

Etapa 2: Técnicas básicas para reduzir o tráfego

Objetivo desta etapa: aplicar técnicas simples que cortam o gasto sem código complexo. Vamos começar pelas mais acessíveis.

Técnica 1: ativar a compressão com Accept-Encoding

Dados textuais (HTML, JSON, scripts) comprimem muito bem. Ao pedir que o servidor envie uma resposta comprimida, você reduz o tráfego de 3 a 5 vezes.

1. Nos cabeçalhos da requisição, adicione Accept-Encoding com o valor gzip, br, deflate.
2. A biblioteca requests em Python faz isso automaticamente e descompacta a resposta sozinha.
3. Confirme que você não desativou essa opção manualmente.
4. Verifique o cabeçalho da resposta Content-Encoding: se estiver gzip ou br, a compressão está funcionando.

Aqui, br significa brotli, um algoritmo mais moderno que comprime melhor que o gzip. A maioria dos servidores oferece suporte a ele. Para usar brotli no Python, instale o pacote brotli com o comando pip install brotli.

Dica: A compressão é gratuita em termos de tráfego e quase gratuita em termos de processamento. Mantenha-a sempre ativada. É a primeira coisa a verificar quando o consumo está alto.

Técnica 2: usar HEAD em vez de GET

Quando você precisa apenas dos cabeçalhos - por exemplo, para verificar se uma página existe, descobrir o tamanho dela ou a data de modificação - use uma requisição HEAD. Ela retorna os cabeçalhos sem o corpo.

1. Em vez de requests.get, use requests.head.
2. Verifique os cabeçalhos necessários em response.headers.
3. O corpo não é transmitido, e a economia chega a 99 por cento nessas verificações.

Cenários típicos para HEAD: verificar o status de links, saber o tamanho de um arquivo antes de baixar e conferir a data da última modificação para o cache.

Técnica 3: eliminar redirecionamentos desnecessários

Cada redirecionamento é uma requisição-resposta completa extra. Se o site fica redirecionando de http para https ou de um endereço para outro, você paga por voltas desnecessárias.

1. Use direto o endereço final: com https e sem barras extras.
2. Se você sabe que o endereço redireciona para www, acesse direto a versão www.
3. Na biblioteca, você pode desativar o redirecionamento automático com o parâmetro allow_redirects igual a False para controlar o processo manualmente.
4. Monte um mapa de redirecionamentos uma vez e, a partir daí, acesse diretamente os endereços finais.

Técnica 4: desativar o carregamento de imagens e mídias em requisições simples

Quando você trabalha com a biblioteca requests, e não com um navegador, você já não carrega imagens automaticamente. O requests puxa apenas a URL que você indicou. Essa é uma vantagem enorme em relação ao navegador.

Se você precisa apenas do HTML, o requests.get retorna o HTML sem imagens, porque as imagens são carregadas pelo navegador em requisições separadas, seguindo os links dentro do HTML. A biblioteca não faz isso, a menos que você peça.

Dica: Para tarefas de coleta de dados textuais, prefira bibliotecas HTTP simples ao navegador. A economia de tráfego acontece automaticamente, porque você não carrega mídias, fontes e rastreadores.

✅ Verificação: Compare o peso da mesma página carregada via requests e via navegador. A diferença normalmente é de 10 a 30 vezes a favor da requisição simples.

Etapa 3: Trabalhando com navegador headless e bloqueio de recursos

Objetivo desta etapa: aprender a bloquear tipos de recursos pesados no navegador. É a maior economia de tráfego quando o navegador ainda é necessário.

Quando o navegador é necessário

Às vezes não tem como evitar o navegador: os dados são carregados por scripts depois que a página abre, existe proteção contra requisições simples ou o conteúdo é gerado dinamicamente. Nesse caso, o navegador carrega tudo o que aparece e o tráfego dispara. A solução é interceptar e bloquear os tipos de recursos desnecessários.

Bloqueio de recursos no Playwright

O Playwright permite interceptar cada requisição do navegador e decidir se ela deve ser liberada ou cancelada. Vamos cancelar imagens, fontes, mídias e estilos.

1. Crie um arquivo browser_saver.py.
2. Importe sync_playwright de playwright.sync_api.
3. Inicie o navegador no modo headless.
4. Crie um contexto com as configurações de proxy pelo parâmetro proxy.
5. Defina um manipulador de rotas com page.route para todas as URLs.
6. Dentro do manipulador, verifique o tipo do recurso com request.resource_type.
7. Se o tipo estiver na lista de bloqueio, chame route.abort.
8. Caso contrário, chame route.continue_.

A lista de tipos para bloquear em uma tarefa típica de coleta de texto: image, media, font, stylesheet. Às vezes você também pode bloquear parte dos scripts, mas com cuidado - sem eles, o conteúdo pode não carregar.

Exemplo de lógica do manipulador

O manipulador recebe o objeto da requisição. Você pega request.resource_type e compara com a lista de bloqueados. Se o recurso é uma imagem ou fonte, você o cancela e o navegador não gasta tráfego com ele. Se é um documento ou um script necessário, você o deixa passar.

Ponto importante: O bloqueio de image, media e font quase nunca quebra a coleta de dados textuais, mas economiza a maior parte do tráfego. Comece por eles e adicione o bloqueio de scripts e estilos somente depois de confirmar que a página ainda entrega os dados necessários.

Bloqueio de recursos no Puppeteer em Node

1. Ative a interceptação de requisições com page.setRequestInterception com o valor true.
2. Inscreva-se no evento request.
3. No manipulador, verifique request.resourceType.
4. Para imagens, fontes e mídias, chame request.abort.
5. Para o restante, chame request.continue.

⚠️ Atenção: O bloqueio de estilos às vezes atrapalha conteúdo dinâmico que depende da visibilidade dos elementos. Se os dados sumirem após o bloqueio de estilos, coloque stylesheet de volta na lista de permitidos.

Dica: Adicione um contador de requisições bloqueadas e liberadas. Você vai ver nos números que 80 a 90 por cento das requisições são bloqueadas, e isso é economia direta de dinheiro.

Economia extra no navegador

• Desative o carregamento de imagens nas configurações do contexto, se o motor suportar.
• Não abra abas extras; cada uma carrega seu próprio conjunto de recursos.
• Feche a página assim que obtiver os dados, não deixe ela aberta.
• Reutilize um mesmo contexto do navegador para uma série de páginas em vez de reiniciar.

✅ Verificação: Execute o navegador com e sem o bloqueio na mesma página e compare o tráfego usando seu contador. A economia deve ser de 70 a 90 por cento. Se for menor, verifique se o manipulador de rotas está realmente funcionando.

Etapa 4: Cache e deduplicação de requisições

Objetivo desta etapa: parar de buscar duas vezes a mesma coisa. Requisições repetidas por dados que não mudaram é dinheiro jogado fora.

Por que as repetições acontecem

Em tarefas grandes, o mesmo recurso é solicitado várias vezes: um script comum em todas as páginas, links repetidos ou a reinicialização de um script que falhou do zero. Cada repetição é tráfego pelo qual você paga de novo.

Cache simples de respostas

1. Crie um dicionário ou um banco local onde a chave é a URL e o valor é a resposta.
2. Antes da requisição, verifique se a URL está no cache.
3. Se estiver, use os dados do cache sem fazer uma requisição pela rede.
4. Se não estiver, faça a requisição e salve a resposta no cache.
5. Para um cache persistente entre execuções, salve as respostas em arquivos ou em um banco local.

Esse cache é especialmente eficiente quando você está depurando um script e o executa várias vezes seguidas. A segunda execução e as seguintes pegam os dados do disco e não gastam nenhum byte de tráfego de rede.

Deduplicação da lista de URLs

1. Antes de começar, reúna todas as URLs em uma única lista.
2. Converta a lista em um conjunto (set) para remover duplicatas.
3. Normalize os endereços: remova parâmetros desnecessários e deixe todos no mesmo formato, com as barras.
4. Processe apenas os endereços únicos.

Dica: Muitas vezes as duplicatas estão disfarçadas por parâmetros diferentes no final do endereço, que não mudam o conteúdo. Corte as tags de rastreamento e de ordenação antes de comparar, e o número de URLs únicas vai cair bastante.

Requisições condicionais para economizar

Se você verifica as mesmas páginas periodicamente, use requisições condicionais. O servidor vai enviar a resposta completa somente se os dados mudaram.

1. Na primeira requisição, salve os cabeçalhos ETag e Last-Modified da resposta.
2. Na requisição seguinte, envie-os de volta nos cabeçalhos If-None-Match e If-Modified-Since.
3. Se os dados não mudaram, o servidor retorna uma resposta curta com status 304, sem corpo.
4. Você economiza o peso do corpo inteiro pagando apenas por um cabeçalho minúsculo.

✅ Verificação: Depois de implementar o cache, uma nova execução do script com os mesmos dados deve mostrar tráfego próximo de zero. Se o tráfego ainda estiver alto, confira se a verificação do cache está antes da requisição de rede, e não depois.

Etapa 5: Calculando o orçamento de tráfego

Objetivo desta etapa: aprender a prever o consumo e incluir uma margem para não ficar sem saldo no meio da tarefa.

Fórmula básica

A fórmula básica é simples: o tráfego total é igual ao número de páginas multiplicado pelo peso médio de uma página. Mas o diabo mora nos detalhes, e vamos levá-los em conta.

1. Defina o peso médio de uma página processada depois de todas as otimizações.
2. Multiplique pela quantidade planejada de páginas.
3. Adicione o overhead da conexão - cerca de 15 por cento por cima.
4. Adicione uma margem para repetições e erros - mais 20 por cento.
5. O número final é o seu orçamento realista de tráfego.

Como medir o peso médio

1. Execute seu script otimizado em uma amostra de 50 a 100 páginas.
2. Calcule o tráfego total com seu contador.
3. Divida pelo número de páginas - você terá o peso médio de uma página.
4. Use exatamente esse número na fórmula, e não suposições teóricas.

Exemplo de cálculo

Digamos que, após o bloqueio de mídias, o peso médio da página ficou em 150 kilobytes. Você precisa processar 100 000 páginas. Vamos calcular: 150 kilobytes multiplicado por 100 000 resulta em 15 000 000 kilobytes, ou seja, cerca de 14,3 gigabytes. Somamos 15 por cento de overhead e 20 por cento de margem - total de cerca de 19,5 gigabytes. É nesse volume que você deve se basear ao escolher o plano.

Compare com a situação sem otimização: se cada página pesasse 3 megabytes, as mesmas 100 000 páginas dariam 300 gigabytes. Uma diferença de quinze vezes - é literalmente a diferença na fatura.

Dica: Sempre faça uma execução de teste em uma amostra pequena antes da execução grande. O peso médio medido é mais honesto do que qualquer suposição e evita uma surpresa desagradável na fatura.

⚠️ Atenção: Não se esqueça da margem. Tarefas reais sempre trazem surpresas: parte das páginas será mais pesada, parte das requisições precisará ser repetida. O orçamento sem margem acaba no pior momento possível.

Tabela de técnicas de economia

Abaixo está um resumo das principais técnicas: quanto cada uma economiza e o que você paga por isso.

• Compressão gzip e brotli - economiza de 60 a 80 por cento em dados textuais - você paga com um pequeno custo de processamento na descompactação.
• Abandonar o navegador em favor de uma biblioteca HTTP - economiza de 90 a 95 por cento - você paga não conseguindo dados carregados por scripts.
• Bloqueio de imagens e mídias no navegador - economiza de 50 a 70 por cento - você paga configurando a interceptação de requisições, e o risco é mínimo.
• Bloqueio de fontes - economiza de 5 a 10 por cento - você não paga quase nada, já que fontes não são necessárias para os dados.
• Bloqueio de scripts e estilos - economiza de 15 a 25 por cento - você paga com o risco de o conteúdo não carregar; é preciso testar.
• HEAD em vez de GET - economiza até 99 por cento em requisições de verificação - você paga não recebendo o corpo da resposta.
• Eliminação de redirecionamentos - economiza de 10 a 30 por cento em sites com redirecionamentos - você paga com um tempo único para mapear os endereços.
• Cache de respostas - economiza até 100 por cento em repetições - você paga com espaço em disco para o cache.
• Deduplicação de URLs - economiza de 10 a 40 por cento quando existem duplicatas - você paga com uma normalização única da lista.
• Requisições condicionais com ETag - economiza até 99 por cento quando os dados não mudam - você paga armazenando as tags de versão.

✅ Verificação: Calcule o orçamento pela fórmula e compare com o saldo do plano. Se a margem couber, pode começar. Se não, volte às técnicas de economia e reduza o peso médio da página.

Etapa 6: Quando vale mais a pena o ilimitado e quando a cobrança por volume

Objetivo desta etapa: escolher com honestidade o plano para a sua tarefa, em vez de pagar a mais por causa de um modelo de cobrança errado.

Quando a cobrança por gigabyte compensa

• A tarefa é pontual ou rara, com volumes pequenos.
• Você otimizou bem o tráfego e sabe exatamente qual é o consumo.
• O peso médio da página é baixo por causa do bloqueio de mídias.
• Picos de carga são raros; na maior parte do tempo, o tráfego é pequeno.
• Você valoriza transparência: paga exatamente pelo que usou.

Quando o plano ilimitado com preço fixo compensa

• A tarefa é contínua, com volumes grandes e estáveis.
• Você precisa trabalhar com navegador e carrega páginas pesadas.
• Imagens, vídeos ou outras mídias pesadas fazem parte da tarefa.
• O consumo é imprevisível e pode aumentar de repente.
• Você valoriza a tranquilidade: um pagamento fixo sem risco de estourar o orçamento.

Como calcular o ponto de equilíbrio

1. Pegue o preço por gigabyte no plano com cobrança por volume.
2. Pegue o preço do plano ilimitado pelo mesmo período.
3. Divida o preço do ilimitado pelo preço por gigabyte - você terá o volume em gigabytes em que os planos empatam.
4. Se sua previsão de consumo for maior que esse volume, escolha o ilimitado.
5. Se for menor, escolha a cobrança por volume.

Por exemplo, o ilimitado custa o equivalente a 50 gigabytes no plano por volume. Então, se você gasta mais de 50 gigabytes, o ilimitado sai mais barato. Se gasta menos, compensa pagar por volume. O seu orçamento medido na etapa 5 já dá a resposta.

Dica: Primeiro otimize o tráfego e depois escolha o plano. Uma boa otimização muitas vezes tira você da zona do ilimitado e coloca na zona da cobrança por volume, economizando uma quantia significativa.

Estratégia combinada

Às vezes, o ideal é ter duas abordagens: tarefas leves de texto na cobrança por volume e tarefas pesadas com navegador no ilimitado. Separar pelo tipo de tarefa costuma sair mais barato do que usar um único plano para tudo.

✅ Verificação: Calcule os dois cenários em dinheiro para a sua previsão real. Você deve chegar a um valor concreto de economia com a escolha certa. Se a diferença for mínima, escolha o plano que é mais simples de gerenciar.

Verificação do resultado: checklist

Percorra a lista para confirmar que você configurou a medição e a economia de tráfego corretamente.

• O contador de tráfego em Python ou Node executa e mostra os números sem erros.
• As leituras do contador batem com as estatísticas do painel de controle, considerando o overhead.
• A compressão está ativada nas requisições, e as respostas mostram Content-Encoding gzip ou br.
• Para tarefas de verificação, você usa HEAD em vez de GET.
• Você acessa direto os endereços finais, sem redirecionamentos extras.
• Para tarefas com texto, você usa biblioteca HTTP em vez de navegador sempre que possível.
• No navegador, o bloqueio de imagens, mídias e fontes está configurado.
• O cache de respostas está ativo, e uma nova execução quase não gasta tráfego.
• A lista de URLs está livre de duplicatas.
• O orçamento foi calculado pela fórmula com margem de 15 e 20 por cento.
• O plano escolhido corresponde à previsão de consumo.

Como testar

1. Execute o script otimizado em uma amostra de 100 páginas.
2. Anote o tráfego antes e depois no painel de controle.
3. Divida pelo número de páginas e compare com o peso médio do cálculo.
4. Se bater, o sistema está funcionando e você pode escalar.

✅ Verificação: Se a execução de teste ficou dentro do orçamento previsto para 100 páginas, você está pronto para a execução completa. Multiplique o resultado pela escala e confirme que o saldo é suficiente.

Erros comuns e como resolvê-los

Vamos analisar os problemas mais comuns que as pessoas enfrentam ao medir e economizar tráfego.

Erro 1: o contador mostra menos do que o painel

Causa: você conta apenas o corpo das respostas, enquanto o serviço considera toda a troca de rede com overhead. Solução: inclua uma margem de 15 a 20 por cento e trate isso como normal, não como bug.

Erro 2: a compressão não funciona

Causa: o pacote para brotli não está instalado ou o Accept-Encoding foi desativado manualmente. Solução: instale o pacote brotli, verifique os cabeçalhos da requisição e confirme que a resposta tem Content-Encoding.

Erro 3: os dados sumiram após o bloqueio de recursos

Causa: você bloqueou scripts ou estilos dos quais o carregamento do conteúdo depende. Solução: coloque script e stylesheet de volta na lista de permitidos e bloqueie apenas image, media e font.

Erro 4: o tráfego não cai com o cache

Causa: a verificação do cache está depois da requisição de rede, e não antes. Solução: verifique primeiro o cache e só faça a requisição pela rede se os dados não estiverem lá.

Erro 5: o navegador gasta tráfego mesmo com o manipulador

Causa: o manipulador de rotas está ligado a um padrão de URL errado ou foi definido depois do início do carregamento. Solução: configure a interceptação antes de abrir a página e para todas as URLs com o asterisco.

Erro 6: o consumo real é muito maior do que o previsto

Causa: o peso médio foi tirado da teoria, e não medido em uma execução de teste. Solução: sempre meça o peso médio em uma amostra real antes de uma execução grande.

Erro 7: o orçamento acabou no meio da tarefa

Causa: não foi incluída margem para repetições e overhead. Solução: adicione 35 por cento de margem total à previsão e acompanhe o saldo durante o processo.

Erro 8: muitas requisições repetidas para o mesmo endereço

Causa: duplicatas na lista de URLs por causa de tags diferentes no final do endereço. Solução: normalize os endereços, corte os parâmetros de rastreamento e transforme a lista em um conjunto.

Recursos adicionais e otimização

Quando a economia básica está funcionando, dá para extrair ainda mais.

Processamento em streaming de respostas grandes

Se a resposta é grande e você só precisa de uma parte, leia-a em streaming e interrompa a leitura assim que obtiver o que precisa. Assim você não baixa o arquivo inteiro. Isso é útil quando os dados estão no início de um documento grande.

Limite do tamanho da resposta

Defina um tamanho máximo de resposta que você está disposto a aceitar. Se o servidor entregar mais, interrompa o download. Isso protege contra páginas surpreendentemente pesadas, que poderiam consumir muito tráfego de uma vez.

Processamento em lote e paralelismo

Requisições paralelas não economizam tráfego por si só, mas permitem concluir a tarefa mais rápido e perceber antes um problema de consumo. Mantenha um número razoável de conexões simultâneas para não perder o controle do tráfego.

Logging e monitoramento em tempo real

1. Mantenha um contador de tráfego ao vivo e exiba-o a cada poucas centenas de requisições.
2. Defina um limite que, ao ser atingido, interrompe o script.
3. Assim você nunca estoura o orçamento sem perceber.

Dica: A parada automática pelo limite de tráfego é o melhor seguro. O script vai parar sozinho no limite definido, e o estouro fica impossível mesmo com um erro de lógica.

Trabalhando apenas com os campos necessários da API

Se os dados estiverem disponíveis por API, solicite apenas os campos necessários, quando houver suporte. Muitas interfaces permitem indicar quais campos retornar, e isso reduz drasticamente o peso da resposta em comparação com o retorno completo.

FAQ: perguntas frequentes sobre economia de tráfego

O tráfego de saída é contabilizado na cobrança por gigabyte?

Geralmente, tanto o de entrada quanto o de saída são contabilizados, mas o de saída (suas requisições) é várias vezes menor que o de entrada (respostas do servidor). A maior economia está sempre no tráfego de entrada.

Quão preciso é o cálculo no lado do cliente?

A precisão fica em torno de 85 a 95 por cento em relação ao tráfego real de rede. A diferença é o overhead da conexão. Para planejar o orçamento, isso é suficiente se você incluir a margem.

Dá para abandonar completamente o navegador?

Para muitas tarefas de coleta de texto, sim, uma biblioteca HTTP simples dá conta do recado e economiza tráfego várias vezes. O navegador só é necessário quando o conteúdo é criado por scripts depois que a página carrega.

A compressão vem ativada por padrão?

Na maioria das bibliotecas modernas, sim, mas vale a pena conferir. Para brotli, pode ser necessário instalar um pacote separado. Sempre verifique o cabeçalho Content-Encoding na resposta.

O que bloquear no navegador primeiro?

Comece por imagens, mídias e fontes - é o maior e mais seguro ganho. Só bloqueie scripts e estilos depois de verificar que os dados ainda carregam.

Como saber se o orçamento vai dar?

Meça o peso médio da página em uma execução de teste, multiplique pelo número de páginas, adicione 35 por cento de margem e compare com o saldo do plano. Se couber, vai dar.

O cache ajuda em uma passagem única?

Em uma passagem única, sem repetições, o cache ajuda pouco, mas ele economiza muito na depuração e em reinicializações. Já as requisições condicionais e a deduplicação ajudam até em uma única passagem.

O que é melhor para volumes grandes e constantes?

Em geral, o plano ilimitado com preço fixo. Calcule o ponto de equilíbrio: divida o preço do ilimitado pelo preço por gigabyte e compare com a previsão de consumo.

O número de redirecionamentos afeta a conta?

Sim, cada redirecionamento é uma requisição-resposta extra. Em sites com cadeias de redirecionamentos, eliminar as passagens desnecessárias economiza uma parte significativa do tráfego.

Como não estourar o orçamento por acidente?

Configure um contador ao vivo e uma parada automática ao atingir o limite de tráfego. O script vai parar sozinho, e o estouro se torna impossível até mesmo com erro.

Conclusão

Você percorreu o caminho de não entender para onde vai o tráfego até ter controle total sobre o consumo. Agora você sabe analisar o peso de uma página por componentes e vê que a maior parte do peso não é necessária. Você configurou o contador de tráfego e o compara com as estatísticas do painel. Você usa compressão, utiliza HEAD em vez de GET, elimina redirecionamentos e prefere bibliotecas HTTP leves ao navegador pesado.

Quando o navegador é necessário, você bloqueia imagens, mídias e fontes e corta o tráfego de 70 a 90 por cento. Você armazena respostas em cache e não busca duas vezes a mesma coisa. E o mais importante: você calcula o orçamento pela fórmula com margem e escolhe o plano com consciência, e não no chute.

O que fazer agora

1. Aplique as técnicas básicas no seu projeto atual ainda hoje.
2. Faça uma execução de teste e meça o peso médio real da página.
3. Recalcule o orçamento e, se necessário, mude de plano.
4. Configure a parada automática por limite como uma proteção.

Economia de tráfego é uma habilidade que se paga em todos os projetos. Depois de investir uma vez na configuração da medição e na otimização, você vai pagar muito menos pelo mesmo resultado. Comece aos poucos, meça o efeito em números e vai se surpreender com o quanto o mesmo trabalho pode ficar mais barato.