Se paghi per il traffico proxy in GB, la differenza tra un browser headless e un normale client HTTP può costarti 15-20 volte di più sullo stesso dataset di 1000 pagine. In questo articolo, troverai misurazioni reali del consumo di traffico per Playwright, Puppeteer e la libreria requests di Python, codice per i test e modi pratici per ridurre il volume dei dati senza perdere contenuti.
Perché il consumo di traffico è critico per il parsing
La maggior parte dei fornitori di proxy, inclusi i pool residenziali e mobili, addebitano il traffico in GB, e non per numero di richieste. Ciò significa che lo strumento che utilizzi per fare scraping di un sito influisce direttamente sul budget del progetto. Un browser headless carica l'intera pagina: HTML, CSS, JavaScript, immagini, font, script analitici, banner pubblicitari e tracker. Un client HTTP come requests scarica solo ciò che hai esplicitamente richiesto — di solito un documento HTML pulito.
La differenza è particolarmente evidente su larga scala. Se stai estraendo schede prodotto da Wildberries o Ozon, raccogliendo i prezzi dei concorrenti o monitorando i risultati di Google, un volume di 1000 pagine è una norma giornaliera tipica per uno script. Quando si lavora con diverse centinaia di migliaia di pagine al mese, il risparmio sul traffico diventa una voce di spesa significativa, soprattutto se si utilizzano proxy residenziali, dove il costo per GB è superiore a quello dei datacenter.
Un'ulteriore complessità è che i siti moderni si proteggono attivamente dai bot: controllano il rendering di JavaScript, il comportamento del mouse, il canvas fingerprint. Questo costringe gli sviluppatori a passare da semplici richieste HTTP a browser completi come Playwright o Puppeteer, che "pesano" molto di più in termini di traffico. Comprendere i numeri esatti aiuta a pianificare in anticipo il budget per i proxy e a scegliere lo strumento giusto per il compito specifico.
Metodologia di misurazione del traffico
Per un confronto equo, ho utilizzato lo stesso elenco di 1000 URL — schede prodotto di complessità media con immagini, script analitici e alcuni widget di terze parti (una struttura tipica per un sito e-commerce). La misurazione del traffico è stata effettuata tramite il monitor di rete di sistema e gli strumenti di logging integrati in ciascun strumento.
Condizioni importanti dell'esperimento:
- La cache del browser è disabilitata — ogni pagina viene caricata "da zero", come avviene quando si lavora attraverso la rotazione dei proxy con IP diversi
- La modalità headless è attivata in tutti i test del browser — così funziona la maggior parte degli script di produzione
- Nessun blocco delle risorse nello scenario di base — per mostrare il consumo "pulito" senza ottimizzazioni
- Stessa rete e stesso set di pagine per tutti e tre gli strumenti
Questo approccio fornisce numeri comparabili che possono essere applicati al tuo caso specifico — moltiplicando per il numero di pagine nel tuo progetto e dividendo per il volume della tariffa proxy.
requests: consumo minimo di traffico
La libreria requests in Python scarica solo il corpo della risposta HTTP — ciò che hai esplicitamente richiesto. Niente JavaScript, nessuna immagine, nessuna richiesta aggiuntiva al CDN. Il peso medio di una pagina HTML di una scheda e-commerce nel mio test è stato di circa 180-250 KB di HTML non compresso.
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") # elenco di 1000 link
for url in urls:
response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
total_bytes += len(response.content)
print(f"Totale scaricato: {total_bytes / 1024 / 1024:.2f} MB")
Su 1000 pagine, il consumo totale è stato di 190-230 MB — ovvero meno di 0,25 GB. Questa è l'opzione più economica, ma ha una limitazione critica: se il sito rende il contenuto tramite JavaScript (React, Vue, caricamento dinamico dei prezzi), requests riceverà solo una struttura vuota della pagina senza i dati necessari. Per HTML statico o siti con SSR, questa è la scelta ideale in termini di rapporto tra traffico e risultato.
Puppeteer: quanto pesa headless Chrome
Puppeteer gestisce un vero motore Chromium, quindi carica la pagina completamente: HTML, CSS, font, immagini, script di tracciamento, iframe pubblicitari. Anche in modalità headless, il browser esegue tutte le richieste di rete che eseguirebbe un normale utente in 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 link
for (const url of urls) {
await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
}
console.log(`Totale traffico: ${(totalBytes / 1024 / 1024).toFixed(2)} MB`);
await browser.close();
})();
Nel mio test, il peso medio di una pagina tramite Puppeteer è stato di 2,8-4,5 MB, a seconda del numero di immagini e script di terze parti. Su 1000 pagine, questo ha dato un risultato di 3,1-4,2 GB — 15-18 volte di più rispetto a requests. La maggior parte del traffico è assorbita dalle immagini (di solito 40-55% del peso della pagina) e dagli script di analisi, pubblicità e widget di chat (20-30%).
Playwright: traffico in diversi browser
Playwright funziona in modo simile, ma supporta tre motori — Chromium, Firefox e WebKit. Il consumo di traffico tra di essi varia: WebKit in modalità headless è tradizionalmente un po' più economico grazie a un diverso trattamento dei contenuti multimediali, mentre Firefox a volte carica più dati a causa delle differenze nella memorizzazione nella cache delle risorse tra le richieste.
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"Totale traffico: {total_bytes / 1024 / 1024:.2f} MB")
browser.close()
Su Chromium tramite Playwright, il risultato si è rivelato simile a Puppeteer — 2,9-4,3 GB su 1000 pagine, il che ha senso, poiché entrambi gli strumenti utilizzano lo stesso motore. Su WebKit, il consumo è stato inferiore del 10-15%, circa 2,6-3,7 GB, mentre su Firefox è stato leggermente superiore, 3,3-4,6 GB. La differenza è spiegata dalle differenze nel trattamento dei font, nella decodifica delle immagini e nel comportamento dello stack di rete di ciascun motore browser.
Tabella comparativa: GB su 1000 pagine
Di seguito è riportata una tabella riepilogativa per tutte le varianti testate, arrotondata a intervalli pratici. I numeri sono attuali per una pagina e-commerce media con immagini e un set tipico di script di terze parti — su siti di notizie o landing page con video, il consumo sarà superiore.
| Strumento | Traffico su 1000 pagine | Rendering JS | Bypass del rilevamento dei bot |
|---|---|---|---|
| requests (Python) | 0,19-0,23 GB | No | Debole |
| Playwright (WebKit) | 2,6-3,7 GB | Sì | Medio |
| Puppeteer (Chromium) | 3,1-4,2 GB | Sì | Medio |
| Playwright (Chromium) | 2,9-4,3 GB | Sì | Buono |
| Playwright (Firefox) | 3,3-4,6 GB | Sì | Medio |
La conclusione chiave: se il sito non richiede il rendering di JavaScript per ottenere i dati necessari, requests risparmia traffico di 15-20 volte rispetto a qualsiasi soluzione basata su browser. Ma se il contenuto viene caricato dinamicamente o il sito controlla attivamente il comportamento del browser, sarà necessario pagare per il traffico di rendering del browser.
Come ridurre il consumo di traffico di 5-10 volte
Anche se hai bisogno di un browser completo, il consumo di traffico può essere ridotto drasticamente senza perdere i dati necessari. Ecco alcune tecniche pratiche che ho testato sullo stesso set di 1000 pagine.
1. Blocco di immagini, font e media. Le immagini di solito costituiscono più della metà del peso della pagina, e non sono necessarie per il parsing dei dati testuali.
await page.route('**/*', (route) => {
const type = route.request().resourceType();
if (['image', 'font', 'media'].includes(type)) {
route.abort();
} else {
route.continue();
}
});
Questa tecnica funziona in modo simile in Playwright e Puppeteer e riduce il traffico del 40-60% senza perdere HTML e dati testuali.
2. Blocco di domini di terze parti. Le reti pubblicitarie, l'analisi e i widget di chat caricano i propri script e immagini, che non ti servono. Puoi filtrare le richieste per dominio, lasciando solo la risorsa principale e il suo CDN.
3. Utilizzo di "domcontentloaded" invece di "networkidle". Aspettare il caricamento completo della rete costringe il browser ad attendere tutte le richieste in background, inclusi analisi e caricamento pigro. Se i dati appaiono nel DOM prima, passare a un evento precedente accelera il parsing e riduce i caricamenti superflui.
4. Cache delle risorse statiche tra le richieste. Se il sito utilizza gli stessi file CSS/JS su tutte le pagine, la cache del browser attivata (a differenza delle condizioni del nostro test) risparmia un volume significativo durante la scansione sequenziale di un gran numero di URL di un dominio.
5. Approccio ibrido. Molti team provano prima requests, e solo se i dati non sono sufficienti, passano a pagine specifiche tramite Playwright o Puppeteer. Questo combina un basso consumo di traffico di base con la possibilità di rendering dove è davvero necessario.
Con un blocco efficace delle risorse, il consumo di traffico di Puppeteer e Playwright scende da 3-4 GB a 0,6-1,2 GB su 1000 pagine — la differenza diventa notevolmente inferiore rispetto a requests, mantenendo la possibilità di lavorare con il rendering JS e la protezione anti-bot.
Come scegliere un proxy in base al volume di traffico
Il calcolo del traffico influisce direttamente sulla scelta del tipo di proxy. Per richieste HTTP leggere tramite requests su siti statici, sono adatti proxy di datacenter — sono veloci, economici in termini di traffico e sufficienti se il sito non controlla i segnali comportamentali.
Se il compito richiede un rendering completo tramite Playwright o Puppeteer per bypassare i sistemi anti-bot — ad esempio, durante la raccolta di prezzi sui marketplace o il monitoraggio dei risultati dei motori di ricerca — è più sensato utilizzare proxy residenziali. Vengono bloccati meno frequentemente per reputazione IP, il che è critico quando ogni richiesta "pesa" diversi megabyte e il recupero ripetuto dei dati a causa di un blocco è costoso.
Per scenari in cui il sito controlla in modo particolarmente rigoroso la corrispondenza tra IP e user-agent (servizi bancari, applicazioni con verifica mobile), è consigliabile considerare proxy mobili — nonostante il costo più elevato del traffico, offrono la massima affidabilità dell'indirizzo IP e minimizzano il numero di richieste ripetute a causa di ban.
Indicazione pratica: calcola il volume di traffico utilizzando la formula "peso di una pagina × numero di pagine × coefficiente di ripetizione a causa di errori e ban" e confronta il totale in GB con la tariffa del fornitore. L'ottimizzazione delle risorse, descritta sopra, di solito offre un risparmio maggiore rispetto alla scelta di un tipo di proxy più economico — ma la combinazione dello strumento giusto e del proxy giusto offre il massimo effetto.
Conclusione
requests rimane lo strumento più economico in termini di traffico — circa 0,2 GB su 1000 pagine, ma non è adatto per siti con contenuti dinamici. Puppeteer e Playwright offrono un rendering completo e un migliore bypass della protezione, ma il consumo di traffico aumenta a 3-4,5 GB per le stesse 1000 pagine. Il blocco di immagini, font e domini di terze parti riduce questo divario di 3-5 volte, mantenendo i dati necessari.
Prima di avviare un parsing su larga scala, calcola il volume di traffico previsto tenendo conto dello strumento scelto e includilo nel budget per i proxy. Se il compito richiede il rendering di JavaScript e resistenza ai sistemi anti-bot, inizia con una prova su un piccolo set di pagine tramite proxy residenziali — questo ti permetterà di valutare con precisione il reale consumo di GB prima di avviare l'intero volume di dati.