Come ridurre il traffico del parser di 5 volte senza perdita di dati: 7 tecniche per data engineer

Ogni megabyte di traffico del parser in più significa pagare il fornitore di proxy o rischiare di superare i limiti e ricevere un ban per IP. Se raccogli i prezzi da Wildberries, Ozon o monitori gli annunci su Avito attraverso centinaia di indirizzi proxy, il risparmio sul traffico influisce direttamente sul budget del progetto. In questo articolo, troverai tecniche specifiche che consentono di ridurre il volume dei dati trasmessi di 4-5 volte, mantenendo la completezza e l'accuratezza delle informazioni estratte.

Perché il traffico del parser colpisce il budget

La maggior parte dei fornitori di proxy addebita i proxy residenziali e mobili in base al volume di gigabyte trasmessi, e non in base al tempo di utilizzo. Se il tuo parser carica completamente la pagina del prodotto Wildberries — con immagini, script di raccomandazione, tracker analitici e font — paghi per 2-3 MB per ogni scheda, mentre in realtà hai bisogno solo di 15-20 KB di testo: nome, prezzo, valutazione, disponibilità.

Quando si scala fino a 50.000-100.000 schede al giorno, la differenza tra "caricare tutto" e "caricare solo ciò che serve" si traduce in decine di gigabyte di traffico superfluo ogni giorno. Questo non solo comporta costi per i proxy, ma aumenta anche il carico sul sito target, il che aumenta la possibilità di incorrere in protezioni anti-bot e ricevere CAPTCHA o un ban temporaneo dell'IP. L'ottimizzazione del traffico è quindi sia un risparmio di denaro che una riduzione del rischio di blocchi.

C'è anche un terzo effetto: meno dati vengono trasmessi per ogni richiesta, più velocemente viene eseguita la richiesta stessa. Questo consente di aumentare il parallelismo — avviare più flussi con lo stesso numero di proxy senza superare i limiti di velocità imposti dai browser anti-detect come Dolphin Anty o AdsPower durante il lavoro con le sessioni.

Metodo 1: Blocco di immagini, CSS e font

Se il parser funziona tramite un browser headless (Playwright, Puppeteer, Selenium) — il modo più veloce per ridurre il traffico di 2-3 volte è bloccare il caricamento delle risorse statiche che non influenzano i dati nel DOM. Le immagini dei prodotti, i font del sito web, i video e gli stili CSS occupano fino al 70% del peso della pagina, ma non partecipano affatto all'estrazione di testo e attributi.

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()

Una logica simile viene implementata in Puppeteer tramite page.setRequestInterception(true) e in Selenium tramite la configurazione del profilo Chrome con il parametro profile.managed_default_content_settings.images: 2. Nella pratica, questa singola impostazione riduce immediatamente dal 50% al 70% del traffico durante il parsing dei marketplace, dove le pagine sono sovraccariche di contenuti visivi e banner pubblicitari.

Metodo 2: Richieste HTTP invece di un browser completo

Molti usano Selenium o Playwright dove non è necessario. Se la pagina non richiede l'esecuzione di JavaScript per il rendering dei dati (è facile verificarlo aprendo "Visualizza sorgente pagina" invece di DevTools), è molto più vantaggioso prelevare l'HTML direttamente tramite le librerie requests o httpx in Python. Tale richiesta pesa kilobyte, non megabyte, perché non comporta il rendering del motore del browser, chiamate di rete per tracker e risorse secondarie.

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), "byte ricevuti")

Passare dall'emulazione del browser a richieste HTTP dirette dove il sito restituisce HTML pronto senza rendering client riduce il traffico di 3-8 volte. L'unico aspetto da considerare è che tali richieste sono più facili da distinguere da un vero utente, quindi per i siti con una rigorosa protezione anti-bot è consigliabile combinare questo metodo con proxy residenziali di alta qualità, che forniscono IP di veri fornitori domestici e riducono la probabilità di blocco della richiesta.

Metodo 3: Parsing tramite API JSON nascoste

Praticamente tutti i moderni marketplace — inclusi Wildberries, Ozon e Yandex.Market — rendono le schede dei prodotti e le liste tramite API JSON interne, che vengono chiamate dal frontend. Trovare questi endpoint è possibile tramite la scheda Network in DevTools, filtrando le richieste per tipo XHR/Fetch. Di solito, una di queste richieste restituisce JSON da 5-30 KB con dati puliti: id prodotto, prezzo, sconto, scorte, valutazione — senza un singolo byte di markup HTML o CSS.

La differenza nel volume dei dati trasmessi tra una pagina HTML completa e una chiamata diretta all'API JSON può raggiungere 10-15 volte. Un ulteriore vantaggio è che il JSON è più facile da analizzare programmaticamente: non sono necessari selettori XPath, basta accedere al campo desiderato tramite la chiave del dizionario. Lo svantaggio è che tali endpoint richiedono spesso intestazioni specifiche, token di sessione o parametri di firma della richiesta, che devono essere estratti in anticipo dalla pagina principale o dall'app mobile.

Metodo 4: Compressione Gzip e Brotli

Anche se sei costretto a prelevare l'HTML completo, l'inclusione della giusta compressione può ridurre la dimensione della trasmissione del 60-80%. Molti parser scritti a mano non inviano l'intestazione Accept-Encoding: gzip, br, il che fa sì che il server restituisca una risposta non compressa. Le librerie requests e httpx decomprimono automaticamente Gzip e Brotli — è importante solo specificare esplicitamente il supporto per la compressione nelle intestazioni della richiesta.

Brotli comprime mediamente il testo HTML più efficacemente di Gzip, dal 15 al 20%, ma non tutti i server supportano questo algoritmo — è consigliabile richiedere entrambe le opzioni e consentire al server di scegliere quella ottimale. Per le API JSON, l'effetto della compressione è ancora più evidente: le chiavi ripetute dei dizionari ("price", "name", "rating") vengono compresse praticamente in modo ideale, riducendo il peso della risposta di diversi ordini di grandezza.

Metodo 5: Richieste condizionali e caching

Se monitori i prezzi degli stessi prodotti più volte al giorno, la maggior parte delle schede tra i controlli non cambia. Utilizza le intestazioni If-Modified-Since e If-None-Match con il valore ETag ottenuto alla prima richiesta. Se il contenuto non è cambiato, il server restituisce lo stato 304 Not Modified praticamente senza corpo della risposta — il risparmio sul traffico arriva fino al 95% sulle pagine non modificate.

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  # i dati non sono cambiati
    etag_store[url] = resp.headers.get("ETag", "")
    return resp.content

Non tutti i siti supportano correttamente ETag, ma per quelli che lo fanno, questo metodo diventa il modo più efficace per ridurre il traffico durante il monitoraggio regolare — paghi effettivamente solo per le reali modifiche dei dati, e non per il ricaricamento di contenuti invariati.

Metodo 6: Parsing selettivo dei campi necessari

A volte ridurre il traffico in entrata dal server è impossibile — il sito restituisce l'intera pagina indipendentemente dalla richiesta. In questo caso, l'ottimizzazione avviene nella fase di elaborazione: non ricaricare la pagina solo per estrarre un altro campo. Progetta selettori XPath o CSS in modo da estrarre tutti gli attributi necessari — prezzo, nome, codice articolo, disponibilità, valutazione — in un solo passaggio attraverso il DOM, invece di effettuare richieste ripetute allo stesso URL con parser diversi per compiti diversi.

È anche utile limitare la profondità di scansione delle pagine annidate. Se per monitorare i prezzi sono sufficienti i dati dalla pagina di categoria (elenco dei prodotti), non passare alla scheda di ogni singolo prodotto — questo traffico duplicato spesso non fornisce nuove informazioni, a parte descrizioni e recensioni, che non influenzano il prezzo e la disponibilità.

Metodo 7: Ottimizzazione del pattern di scansione

La deduplicazione degli URL è un metodo di base, ma spesso ignorato. I cataloghi dei marketplace generano numerosi link con contenuti identici, ma con parametri di ordinamento diversi, etichette UTM o ID di sessione. La normalizzazione degli URL prima di metterli in coda (rimozione dei parametri di tracciamento, ordinamento dei parametri di query) elimina il 10-30% delle richieste superflue durante la scansione di grandi cataloghi.

Dare priorità alla scansione in base alla frequenza di modifica dei dati consente anche di risparmiare traffico: i prodotti ad alta domanda e con prezzi volatili dovrebbero essere controllati ogni ora, mentre le posizioni rare — una volta al giorno. Questo programma adattivo, invece di una scansione uniforme di tutte le schede con la stessa periodicità, riduce il volume totale delle richieste di 2-4 volte senza perdere l'attualità dei dati critici.

Come si integra con la strategia dei proxy

Ridurre il traffico influisce direttamente sulla scelta del tipo di proxy. Se stai estraendo un grande volume di pagine tramite richieste HTTP dirette senza una complessa protezione anti-bot, bastano proxy di data center veloci e economici — offrono alta velocità di trasmissione a basso costo per gigabyte, il che è critico quando si esegue un parsing su migliaia di schede al giorno.

Per i siti con protezioni rigide contro i bot, dove è importante simulare il comportamento di un vero utente, è meglio utilizzare proxy residenziali — combinandoli con metodi di blocco delle risorse superflue, ottieni sia un basso traffico che un alto grado di fiducia del sito nella richiesta. E se il parsing avviene tramite le versioni mobili delle API dei marketplace, dove i dati sono più compatti e il sistema anti-bot si basa su intervalli di IP mobili, è opportuno considerare proxy mobili per ridurre ulteriormente il rischio di blocchi.

La combinazione di "traffico minimo per richiesta" + "tipo di proxy corretto per il compito" consente di ridurre contemporaneamente i costi per l'infrastruttura e aumentare la velocità di raccolta dei dati senza compromettere l'affidabilità.

Tabella comparativa dei metodi

Metodo	Riduzione del traffico	Difficoltà di implementazione
Blocco di immagini/CSS/font	50-70%	Bassa
Richieste HTTP invece di un browser	3-8 volte	Media
API JSON nascoste	10-15 volte	Alta
Compressione Gzip/Brotli	60-80%	Bassa
Richieste condizionali (ETag)	fino al 95% su pagine non modificate	Media
Deduplicazione URL e priorità	2-4 volte	Media

Checklist di implementazione

• Controllare se la pagina target richiede il rendering JavaScript, o se è possibile prelevare l'HTML direttamente tramite httpx/requests
• Configurare il blocco di image/media/font/stylesheet nel browser headless, se necessario
• Trovare le API JSON interne tramite DevTools → Network → XHR/Fetch
• Aggiungere le intestazioni Accept-Encoding: gzip, br a tutte le richieste
• Implementare la memorizzazione di ETag/Last-Modified per richieste condizionali su URL ripetuti
• Normalizzare e deduplicare la coda degli URL prima della scansione
• Impostare una frequenza di scansione adattiva in base all'importanza e alla volatilità dei dati
• Selezionare il tipo di proxy in base al profilo di traffico finale — data center, residenziali o mobili

Conclusione

Ridurre il traffico del parser di 5 volte è un obiettivo realistico se si applicano i metodi in modo sequenziale: rimuovere le risorse superflue, passare a richieste HTTP dirette o API JSON dove possibile, abilitare la compressione, utilizzare richieste condizionali per dati invariati e ottimizzare il pattern di scansione stesso. Ognuno di questi passaggi offre un effetto misurabile e, insieme, cambiano radicalmente l'economia del progetto di raccolta dati dai marketplace e altri siti.

Dopo aver ottimizzato il traffico, è importante scegliere correttamente l'infrastruttura dei proxy in base al nuovo profilo di carico. Per la raccolta rapida ed economica di grandi volumi di dati, sono adatti i proxy di data center, mentre per lavorare con siti con una rigorosa protezione anti-bot, è meglio utilizzare proxy residenziali con indirizzi IP reali di fornitori domestici, che riducono il rischio di blocchi anche durante un parsing intensivo.