Comment réduire le trafic du parseur par 5 sans perte de données : 7 astuces pour les data engineers

Chaque mégaoctet de trafic du parseur supplémentaire représente soit un coût pour le fournisseur de proxy, soit un risque de dépasser les limites et d'être banni par IP. Si vous collectez des prix sur Wildberries, Ozon ou surveillez des annonces sur Avito via des centaines d'adresses proxy, l'économie de trafic influence directement le budget du projet. Dans cet article, nous vous proposons des techniques techniques concrètes qui permettent de réduire le volume de données transférées de 4 à 5 fois, tout en préservant la complétude et la précision des informations extraites.

Pourquoi le trafic du parseur impacte le budget

La plupart des fournisseurs de proxy facturent les proxies résidentiels et mobiles en fonction du volume de gigaoctets transférés, et non du temps d'utilisation. Si votre parseur charge complètement la page d'un produit Wildberries — avec des images, des scripts de recommandations, des trackers d'analyse et des polices — vous payez pour 2 à 3 Mo par carte, alors que vous avez réellement besoin de 15 à 20 Ko de texte : nom, prix, note, disponibilité.

Lors de l'échelle jusqu'à 50 000-100 000 cartes par jour, la différence entre « tout charger » et « charger uniquement ce qui est nécessaire » se transforme en dizaines de gigaoctets de trafic superflu chaque jour. Ce ne sont pas seulement des coûts pour les proxies, mais aussi une charge accrue sur le site cible, ce qui augmente le risque de déclencher une protection anti-bot et d'obtenir un captcha ou un bannissement temporaire de l'IP. L'optimisation du trafic est à la fois une économie d'argent et une réduction du risque de blocages.

Il y a aussi un troisième effet : moins de données sont transférées par requête, plus la requête elle-même est exécutée rapidement. Cela permet d'augmenter le parallélisme — de lancer plus de flux avec le même nombre de proxies sans dépasser les limites de vitesse imposées par les navigateurs anti-détection comme Dolphin Anty ou AdsPower lors de l'utilisation de sessions.

Technique 1 : Blocage des images, CSS et polices

Si le parseur fonctionne via un navigateur sans tête (Playwright, Puppeteer, Selenium) — le moyen le plus rapide de réduire le trafic de 2 à 3 fois est de bloquer le chargement des ressources statiques qui n'affectent pas les données dans le DOM. Les images des produits, les polices du site web, les vidéos et les styles CSS représentent jusqu'à 70 % du poids de la page, mais ne participent en rien à l'extraction de texte et d'attributs.

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

Une logique similaire est mise en œuvre dans Puppeteer via page.setRequestInterception(true) et dans Selenium via la configuration du profil Chrome avec le paramètre profile.managed_default_content_settings.images: 2. En pratique, ce seul paramètre réduit immédiatement de 50 % à 70 % le trafic lors du parsing des marketplaces, où les pages sont surchargées de contenu visuel et de bannières publicitaires.

Technique 2 : Requêtes HTTP au lieu d'un navigateur complet

Beaucoup utilisent Selenium ou Playwright là où ce n'est pas nécessaire. Si la page ne nécessite pas l'exécution de JavaScript pour rendre les données (ce qui est facile à vérifier en ouvrant « Afficher le code de la page » au lieu des DevTools), il est beaucoup plus avantageux de récupérer le HTML directement via les bibliothèques requests ou httpx en Python. Une telle requête pèse des kilooctets, et non des mégaoctets, car elle n'entraîne pas le rendu du moteur du navigateur, les appels réseau pour les trackers et les ressources secondaires.

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), "octets reçus")

Passer de l'émulation de navigateur à des requêtes HTTP directes là où le site fournit du HTML prêt sans rendu client réduit le trafic de 3 à 8 fois. Le seul inconvénient est que ces requêtes sont plus faciles à distinguer de celles d'un véritable utilisateur, donc pour les sites avec une protection anti-bot stricte, il est préférable de combiner cette méthode avec des proxies résidentiels de qualité, qui fournissent des IP de véritables fournisseurs domestiques et réduisent la probabilité de blocage de la requête.

Technique 3 : Parsing via des API JSON cachées

Pratiquement toutes les marketplaces modernes — y compris Wildberries, Ozon et Yandex.Market — rendent les cartes de produits et les listes via des API JSON internes appelées par le frontend. Ces points de terminaison peuvent être trouvés via l'onglet Réseau dans les DevTools, en filtrant les requêtes par type XHR/Fetch. En général, une telle requête renvoie un JSON de 5 à 30 Ko avec des données brutes : id du produit, prix, remise, stocks, note — sans un seul octet de balisage HTML ou de CSS.

La différence de volume de données transférées entre une page HTML complète et un accès direct à l'API JSON peut atteindre 10 à 15 fois. Un autre avantage — le JSON est plus facile à parser par programme : il n'est pas nécessaire d'utiliser des sélecteurs XPath, il suffit d'accéder au champ souhaité par la clé du dictionnaire. Le désavantage est que ces points de terminaison nécessitent souvent des en-têtes spécifiques, des tokens de session ou des paramètres de signature de requête, qui doivent être extraits au préalable de la page principale ou de l'application mobile.

Technique 4 : Compression Gzip et Brotli

Même si vous devez récupérer le HTML complet, l'activation d'une compression appropriée peut réduire la taille de transmission de 60 à 80 %. De nombreux parseurs faits maison n'envoient pas l'en-tête Accept-Encoding: gzip, br, ce qui fait que le serveur renvoie une réponse non compressée. Les bibliothèques requests et httpx décompressent automatiquement Gzip et Brotli — il suffit de spécifier clairement le support de la compression dans les en-têtes de la requête.

Brotli compresse en moyenne le HTML textuel plus fortement que Gzip, de 15 à 20 %, mais tous les serveurs ne prennent pas en charge cet algorithme — il est préférable de demander les deux options et de laisser le serveur choisir la meilleure. Pour les API JSON, l'effet de la compression est encore plus marqué : les clés répétées des dictionnaires (« price », « name », « rating ») se compressent presque parfaitement, réduisant le poids de la réponse de plusieurs fois.

Technique 5 : Requêtes conditionnelles et mise en cache

Si vous surveillez les prix des mêmes produits plusieurs fois par jour, la plupart des cartes entre les vérifications ne changent pas. Utilisez les en-têtes If-Modified-Since et If-None-Match avec la valeur ETag obtenue lors de la première requête. Si le contenu n'a pas changé, le serveur renvoie le statut 304 Not Modified pratiquement sans corps de réponse — l'économie de trafic peut atteindre 95 % sur les pages inchangées.

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  # les données n'ont pas changé
    etag_store[url] = resp.headers.get("ETag", "")
    return resp.content

Tous les sites ne prennent pas correctement en charge ETag, mais pour ceux qui le font, cette technique devient le moyen le plus efficace de réduire le trafic lors de la surveillance régulière — vous ne payez en fait que pour les changements réels de données, et non pour le rechargement de contenu inchangé.

Technique 6 : Parsing sélectif des champs nécessaires

Parfois, il est impossible de réduire le trafic entrant du serveur — le site renvoie la page entière indépendamment de la requête. Dans ce cas, l'optimisation se produit au stade du traitement : ne rechargez pas la page simplement pour extraire un autre champ. Concevez vos sélecteurs XPath ou CSS de manière à extraire tous les attributs nécessaires en une seule passe dans le DOM — prix, nom, référence, disponibilité, note — au lieu de faire des requêtes répétées à la même URL avec différents parseurs pour différentes tâches.

Il est également utile de limiter la profondeur de crawl des pages imbriquées. Si les données de la page de catégorie (liste de produits) suffisent pour surveiller les prix, ne passez pas à la carte de chaque produit séparément — cela génère un trafic redondant qui n'apporte souvent aucune nouvelle information, à part des descriptions et des avis, qui n'influencent pas le prix et la disponibilité.

Technique 7 : Optimisation du modèle de crawl

La dé-duplication des URL est une technique basique mais souvent ignorée. Les catalogues des marketplaces génèrent de nombreux liens avec un contenu identique, mais avec différents paramètres de tri, balises UTM ou ID de session. La normalisation des URL avant de les mettre en file d'attente (suppression des paramètres de suivi, tri des paramètres de requête) élimine 10 à 30 % des requêtes redondantes lors du crawl de grands catalogues.

La priorisation du crawl en fonction de la fréquence de changement des données permet également d'économiser du trafic : les produits à forte demande et au prix volatile doivent être vérifiés chaque heure, tandis que les articles rares peuvent l'être une fois par jour. Un tel calendrier adaptatif, au lieu d'un crawl uniforme de toutes les cartes à la même fréquence, réduit le volume total des requêtes de 2 à 4 fois sans perdre la pertinence des données critiques.

Comment cela s'intègre à la stratégie de proxy

La réduction du trafic influence directement le choix du type de proxy. Si vous parsez un grand volume de pages via des requêtes HTTP directes sans protection anti-bot complexe, il suffit d'utiliser des proxies de datacenter rapides et bon marché — ils offrent une vitesse de transmission élevée à faible coût par gigaoctet, ce qui est crucial lors du parsing à grande échelle de milliers de cartes par jour.

Pour les sites avec une protection stricte contre les bots, où il est important d'imiter le comportement d'un véritable utilisateur, il est préférable d'utiliser des proxies résidentiels — en les combinant avec des techniques de blocage des ressources superflues, vous obtenez à la fois un faible trafic et un haut degré de confiance du site envers la requête. Et si le parsing se fait via les versions mobiles des API des marketplaces, où les données sont plus compactes et où le système anti-bot se concentre sur les plages IP mobiles, il vaut la peine d'envisager des proxies mobiles pour réduire davantage le risque de blocages.

La combinaison « trafic minimal par requête » + « type de proxy approprié pour la tâche » permet de réduire simultanément les coûts d'infrastructure et d'augmenter la vitesse de collecte des données sans perte de fiabilité.

Tableau comparatif des techniques

Technique	Réduction du trafic	Difficulté d'implémentation
Blocage des images/CSS/polices	50-70%	Faible
Requêtes HTTP au lieu d'un navigateur	3-8 fois	Moyenne
API JSON cachées	10-15 fois	Élevée
Compression Gzip/Brotli	60-80%	Faible
Requêtes conditionnelles (ETag)	jusqu'à 95% sur les pages inchangées	Moyenne
Dé-duplication des URL et priorisation	2-4 fois	Moyenne

Liste de contrôle pour l'implémentation

• Vérifiez si la page cible nécessite un rendu JavaScript, ou si vous pouvez récupérer le HTML directement via httpx/requests
• Configurer le blocage des images/médias/polices/styles CSS dans un navigateur sans tête, si le navigateur est tout de même nécessaire
• Trouver les API JSON internes via DevTools → Réseau → XHR/Fetch
• Ajouter les en-têtes Accept-Encoding: gzip, br à toutes les requêtes
• Implémenter le stockage ETag/Last-Modified pour les requêtes conditionnelles sur les URL répétées
• Normaliser et dédupliquer la file d'attente des URL avant le crawl
• Configurer une fréquence de crawl adaptative en fonction de l'importance et de la volatilité des données
• Choisir le type de proxy en fonction du profil de trafic final — datacenter, résidentiels ou mobiles

Conclusion

Réduire le trafic du parseur par 5 est un objectif réaliste si vous appliquez les techniques de manière séquentielle : éliminer les ressources superflues, passer à des requêtes HTTP directes ou des API JSON là où cela est possible, activer la compression, utiliser des requêtes conditionnelles pour les données inchangées et optimiser le modèle de crawl lui-même. Chacun de ces pas a un effet mesurable, et ensemble, ils changent radicalement l'économie du projet de collecte de données sur les marketplaces et d'autres sites.

Après l'optimisation du trafic, il est important de choisir correctement l'infrastructure de proxy en fonction du nouveau profil de charge. Pour une collecte rapide et bon marché de grands volumes de données, les proxies de datacenter conviennent, tandis que pour travailler avec des sites ayant une protection anti-bot stricte, les proxies résidentiels avec de véritables adresses IP de fournisseurs domestiques réduisent le risque de blocage même lors d'un parsing intensif.