Come ridurre i costi di larghezza di banda dei proxy: taglia il tuo conto GB del 60-90%

Nei proxy a pagamento per GB, il tuo conto è in byte, non in richieste — e la maggior parte di quei byte sono immagini e font che non analizzi mai. Ecco come eliminarli e ridurre il conto GB residenziale di oltre la metà.

Nei proxy a pagamento per GB, il tuo conto è in byte, non in richieste — e la scomoda verità è che la maggior parte di quei byte sono immagini, font e fogli di stile che non analizzi mai. Una singola foto di prodotto ad alta risoluzione può essere di 2,2 MB; un rendering completo di una pagina su un browser va da 2 a 5 MB. L'HTML snello da cui effettivamente estrai è spesso sotto i 150 KB. Elimina il resto e un conto GB residenziale cala del 60-90%. Questa guida è il manuale pratico: blocca le risorse, salta le pagine invariate, comprimi e indirizza verso JSON invece che HTML.

Per prima cosa, sappi per cosa vieni fatturato

La larghezza di banda residenziale è misurata sulla somma dei dati trasmessi in entrambe le direzioni: intestazioni della richiesta più corpo della richiesta, e intestazioni della risposta più corpo della risposta. Ciò significa che ogni risorsa che una pagina carica — ogni immagine, font e script di tracciamento — finisce sulla tua fattura anche se nulla di ciò alimenta il tuo parser. L'obiettivo di ottimizzazione è semplice: scaricare solo i byte da cui estrai. Tutto il resto è spreco che stai pagando.

Blocca le risorse in un browser headless

Se stai guidando un browser, questo è il singolo più grande leva. Playwright e Puppeteer ti permettono entrambi di intercettare le richieste e abortire i tipi di risorse di cui non hai bisogno. Bloccare immagini, media, font e fogli di stile tipicamente riduce il peso della pagina per la maggior parte — il DOM si costruisce ancora, quindi i tuoi selettori e qualsiasi JSON di idratazione sopravvivono:

// Playwright: abort the resource types you never parse
await page.route('**/*', (route) => {
  const type = route.request().resourceType();
  if (['image', 'media', 'font', 'stylesheet'].includes(type)) {
    return route.abort();
  }
  return route.continue();
});
await page.goto(url, { waitUntil: 'domcontentloaded' });

Due avvertenze: non bloccare le chiamate XHR/fetch che trasportano i dati che cerchi, e testa che la pagina renda ancora ciò di cui hai bisogno — un blocco eccessivo può rompere la logica del sito stesso. Se stai valutando un browser rispetto alle semplici richieste, il nostro confronto sul costo del rendering rispetto alle richieste HTTP mostra il divario di 10-50x che rende questa decisione importante.

Salta le pagine che non sono cambiate

Il byte più economico è quello che non scarichi. Due tecniche riducono lo spreco di ri-fetch nei lavori di monitoraggio. Una richiesta HEAD tira solo le intestazioni per controllare Content-Length o Last-Modified prima di impegnarti al GET completo. Meglio ancora, un GET condizionale invia l'ETag o il timestamp dell'ultima volta e il server risponde con 304 Not Modified con un corpo vuoto quando nulla è cambiato — paghi per pochi byte di intestazione invece che per l'intera pagina:

import requests

# conditional GET: 304 = near-zero bytes when unchanged
headers = {"If-None-Match": last_etag,
           "If-Modified-Since": last_seen}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)

if r.status_code == 304:
    pass  # unchanged, no body downloaded, no GB spent
else:
    process(r.content)
    last_etag = r.headers.get("ETag")

Per uno scraper che ricontrolla le stesse pagine quotidianamente, i GET condizionali da soli possono ridurre drasticamente la larghezza di banda, perché la maggior parte delle pagine non cambia tra le esecuzioni.

Accetta sempre la compressione

Il testo si comprime bene — HTML, JSON e CSS si riducono del 70-90% con gzip o brotli — e vieni fatturato sulla dimensione compressa che effettivamente attraversa il filo. Invia un'intestazione Accept-Encoding e lascia che il server comprima. In requests di Python questo è attivo per impostazione predefinita quando non lo contrasti; in un client grezzo, chiedilo esplicitamente:

headers = {"Accept-Encoding": "gzip, deflate, br"}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)
# requests transparently decompresses; you're billed on the small size

Indirizza verso JSON, non HTML

Il più grande vantaggio strutturale è saltare completamente la pagina renderizzata. Molti siti si idratano da un endpoint JSON che trasporta gli stessi dati in una frazione dei byte — il prezzo e lo stock di un prodotto come una risposta API di 10 KB invece di una pagina renderizzata di 3 MB. Trova la chiamata XHR nella scheda Network del tuo browser e colpiscila direttamente. I negozi Shopify sono l'esempio classico: l'endpoint products.json ti consegna l'intero catalogo senza alcun HTML. Quando puoi leggere l'API, fallo — è la differenza tra kilobyte e megabyte per record.

Lascia che l'API conti i byte per te

Se preferisci non regolare manualmente le regole di blocco per sito, un Scraper API che rende solo quando necessario e restituisce markdown o JSON analizzato fa il lavoro di eliminazione delle risorse per te — ricevi il contenuto estratto, non i megabyte da cui proviene. E su proxy residenziali a pagamento per GB i risparmi sono diretti: meno byte sul filo significa meno dollari sulla fattura, senza perdere nulla dai dati che mantieni. Per il quadro completo di cosa compra effettivamente un gigabyte, vedi il nostro confronto sul prezzo per GB.

Scrape più leggero su proxy residenziali a pagamento per GB

Domande frequenti

Come viene calcolata la larghezza di banda dei proxy?

Dal totale dei byte trasmessi in entrambe le direzioni: intestazioni della richiesta più corpo della richiesta, e intestazioni della risposta più corpo della risposta. Quindi ogni immagine, font e script che una pagina carica conta verso il tuo utilizzo, non solo l'HTML che analizzi. Ecco perché bloccare le risorse inutilizzate e saltare le pagine invariate si traduce direttamente in una fattura più bassa nei piani a pagamento per GB.

Bloccare le immagini interrompe lo scraping?

Non se sei attento. Bloccare immagini, media, font e fogli di stile lascia intatti il DOM e JavaScript, quindi i tuoi selettori e qualsiasi JSON di idratazione funzionano ancora — stai solo saltando il carico visivo. Il rischio è un blocco eccessivo: non abortire mai le chiamate XHR/fetch che trasportano i tuoi dati, e testa che la pagina produca ancora ciò di cui hai bisogno prima di eseguire su larga scala.

Qual è il singolo più grande risparmio di larghezza di banda?

Indirizzare verso un endpoint JSON invece di rendere l'intera pagina, dove esiste. Una risposta API di 10 KB può sostituire un rendering di 3 MB per lo stesso record — un taglio del 99%. Dopo di ciò, bloccare le risorse in un browser headless e usare GET condizionali sui ri-crawl sono le vittorie più grandi. La compressione è quasi gratuita e dovrebbe essere sempre attiva.

Quanto posso realisticamente risparmiare?

Bloccare le risorse tipicamente riduce il peso di una pagina renderizzata di ben oltre la metà; i GET condizionali possono ridurre la larghezza di banda del ri-crawl a quasi zero per le pagine che non cambiano; e passare dall'HTML a un percorso JSON è spesso una riduzione del 90% o più per record. Insieme, un taglio del 60-90% a un conto GB residenziale è un obiettivo realistico per la maggior parte dei progetti.

Niente di questo cambia ciò che estrai — cambia ciò che paghi per estrarlo. Blocca le risorse che non leggi mai, salta le pagine che non si sono mosse, accetta la compressione e preferisci i percorsi JSON rispetto ai rendering completi. Su proxy a pagamento per GB queste quattro abitudini riducono regolarmente una fattura di oltre la metà. Per l'architettura che scala questo su milioni di pagine, vedi la nostra guida sull'architettura di scraping su larga scala.

Ottieni contenuti analizzati senza i byte sprecati