I pacchetti di proxy residential e mobile sono prezzati per lo più Per GB . Questo trasforma la domanda "5 GB bastano?" direttamente in una questione di budget. Purtroppo la maggior parte degli utenti stima il consumo molto al di sotto della realtà e si ritrova a metà mese senza quota.
In questo articolo vediamo da cosa è realmente composto il consumo di GB, quali voci vengono trascurate e quali sono i modi misurabili per ridurlo.
Cosa conta esattamente il contatore?
I provider in genere contano i byte totali che passano attraverso il proxy: sia la richiesta (upload) sia la risposta (download). Sono inclusi:
In una pagina, l'HTML di cui hai davvero bisogno è spesso un decimo del traffico totale. Tutto il risparmio deriva dal gestire questo rapporto.
Alcuni provider contano solo i byte scaricati, altri il traffico totale. Se svolgi attività prevalentemente di upload (invio di file, corpi POST di grandi dimensioni), questa distinzione cambia sensibilmente la fattura. Verifica nel contratto quale dei due viene conteggiato.
Un esempio di calcolo realistico
Supponiamo di dover estrarre 10.000 pagine prodotto al giorno da un marketplace. Il costo di tre approcci diversi è del tutto differente:
| Approccio | Per pagina | Al giorno | Al mese (30 giorni) |
|---|---|---|---|
| Caricamento completo con browser | ~2,2 MB | 22 GB | 660 GB |
| Browser + immagini/media bloccati | ~0,6 MB | 6 GB | 180 GB |
| Richiesta HTTP semplice (solo HTML) | ~0,12 MB | 1,2 GB | 36 GB |
La differenza è di 18 volte. Raccogli gli stessi dati, ma il costo è completamente diverso. Per questo la prima ottimizzazione è sempre "ho davvero bisogno di un browser?" "è sufficiente per questo target?"
Se nella scheda Rete vedi che una chiamata XHR/fetch restituisce il dato già pronto in JSON, non è necessario caricare l'intera pagina.
Se devi usare un browser: blocco delle risorse
Se lavori con Playwright, Puppeteer o Selenium, puoi ridurre il consumo del 60–80% bloccando le risorse superflue a livello di rete:
Poiché ogni richiesta bloccata non raggiunge mai il proxy, non viene nemmeno conteggiata dal contatore. Il layout della pagina si rompe, ma il contenuto testuale arriva quasi sempre completo.
Per le impostazioni pratiche di automazione del browser puoi dare un'occhiata al nostro articolo proxy per automazione e gli scenari di proxy per il web scraping .
Compressione: il 70% di risparmio, gratis
I server possono inviare HTML, CSS e JSON compressi con gzip o Brotli — ma solo se il client dichiara di volerlo. Aggiungere alla tua richiesta l'header Accept-Encoding: gzip, br garantisce tipicamente un risparmio del 65–80% sui contenuti testuali.
La maggior parte delle librerie HTTP invia questo header per impostazione predefinita, ma quando si impostano gli header manualmente è molto facile cancellarlo per errore. Se personalizzi la tua lista di header, conserva sempre Accept-Encoding.
Le voci trascurate
Voci spesso dimenticate nei calcoli che nel totale pesano parecchio:
- Redirect: Ogni 301/302 significa un giro in più. Le lunghe catene di redirect bruciano byte e tempo.
- Richieste fallite: Anche una richiesta che va in timeout consuma dati. Un tasso di fallimento del 20% significa una fattura più alta del 20%.
- Nuovi tentativi: Una logica di retry automatico può scaricare la stessa pagina 3 volte.
- Handshake TLS: Ogni nuova connessione comporta un overhead di ~5–7 KB. Usare un pool di connessioni lo riduce sensibilmente.
- Health check: Un controllo eseguito una volta al minuto fa migliaia di richieste al mese.
- Pagine CAPTCHA: Anche le richieste bloccate vengono scaricate e conteggiate.
Una richiesta bloccata non è "gratis": handshake, pagina di blocco e nuovo tentativo insieme costano quanto due pagine intere. Aumentare il tasso di successo è il metodo di risparmio più efficace.
Non ottimizzare senza misurare
Misura invece di stimare. Nell'automazione del browser, sommare le dimensioni delle risposte richiede poche righe:
La media ricavata da qualche centinaio di richieste è abbastanza accurata per una proiezione mensile. Dopo le modifiche di risparmio, ripeti la stessa misurazione e verifica la differenza.
Il tipo di proxy giusto in base al tipo di traffico
Se la banda è costosa, far passare ogni richiesta dal pool più costoso non ha senso. Scegliere la fonte in base al tipo di traffico riduce sensibilmente i costi:
| Tipo di attività | Volume tipico | Fonte adatta | Perché |
|---|---|---|---|
| Raccolta di pagine statiche | Alto | Datacenter | Costo al GB minimo, velocità elevata |
| Marketplace protetto | Media | Residential | Punteggio di affidabilità alto, pochi blocchi |
| Operazioni su account con sessioni lunghe | Bassa | ISP | IP statico, opzioni di traffico illimitato |
| Le piattaforme più severe | Molto basso | Mobile | Massima affidabilità, GB costosi |
I pacchetti con IP fisso e traffico illimitato possono risultare molto più economici di quelli a consumo in GB nelle attività ad alto volume e di lunga durata. Per decidere al nostro confronto tra ISP e residential puoi consultarlo.
Imposta un avviso prima di esaurire la quota
Quando la quota finisce l'operazione si ferma; questo può avere conseguenze peggiori di dati incompleti. Un semplice livello di protezione:
- Fissa un obiettivo di consumo giornaliero (quota mensile ÷ 30).
- Conta i byte scaricati dalla tua parte e genera un avviso quando ti avvicini alla soglia.
- All'80% passa automaticamente al pool economico, al 95% esegui solo le attività critiche.
- Se il provider offre un'API, sincronizza la quota reale alcune volte al giorno.
Riepilogo
Il consumo di GB è determinato per lo più non da "quante pagine ho estratto", ma da "cosa ho scaricato in ogni pagina". Bloccare le immagini e gli script di tracciamento, preservare la compressione, evitare l'uso superfluo del browser e aumentare il tasso di successo: questi quattro elementi insieme riducono a un terzo la fattura di una tipica operazione. Se prima di iniziare a misurare il tuo consumo vuoi chiarire quale tipo di proxy fa al caso tuo le nostre pagine di località e prodotto .