Si vous payez pour le trafic proxy par Go, la différence entre un navigateur sans tête et un client HTTP classique peut vous coûter 15 à 20 fois plus cher pour le même ensemble de données de 1000 pages. Dans cet article, vous trouverez des mesures réelles de la consommation de trafic pour Playwright, Puppeteer et la bibliothèque requests de Python, du code pour les tests et des méthodes efficaces pour réduire le volume de données sans perte de contenu.
Pourquoi la consommation de trafic est critique pour le scraping
La plupart des fournisseurs de proxy, y compris les pools résidentiels et mobiles, facturent le trafic par Go, et non par nombre de requêtes. Cela signifie que l'outil que vous utilisez pour scraper un site a un impact direct sur le budget du projet. Un navigateur sans tête charge la page dans son intégralité : HTML, CSS, JavaScript, images, polices, scripts d'analyse, bannières publicitaires et trackers. Un client HTTP comme requests ne télécharge que ce que vous avez explicitement demandé — généralement, il s'agit d'un document HTML brut.
La différence est particulièrement perceptible à grande échelle. Si vous scrapez des fiches produits sur Wildberries ou Ozon, collectez les prix des concurrents ou surveillez les résultats de Google, un volume de 1000 pages est une norme quotidienne typique pour un script. Lorsque vous traitez plusieurs centaines de milliers de pages par mois, les économies sur le trafic deviennent une dépense significative, surtout si vous utilisez des proxies résidentiels, où le coût par Go est plus élevé que pour les centres de données.
Une complexité supplémentaire réside dans le fait que les sites modernes se protègent activement contre les bots : ils vérifient le rendu JavaScript, le comportement de la souris, le fingerprinting du canvas. Cela pousse les développeurs à passer de simples requêtes HTTP à des navigateurs complets comme Playwright ou Puppeteer, qui "pèsent" beaucoup plus en termes de trafic. Comprendre les chiffres exacts aide à estimer à l'avance le budget pour les proxies et à choisir le bon outil pour une tâche spécifique.
Méthodologie de mesure du trafic
Pour une comparaison équitable, j'ai utilisé la même liste de 1000 URL — des fiches produits de complexité moyenne avec des images, des scripts d'analyse et plusieurs widgets tiers (structure typique pour un site e-commerce). La mesure du trafic a été effectuée via le moniteur réseau système et les outils de journalisation intégrés dans chaque outil.
Conditions importantes de l'expérience :
- Le cache du navigateur est désactivé — chaque page est chargée "à partir de zéro", comme cela se produit lors de l'utilisation d'une rotation de proxies avec des IP différentes
- Le mode sans tête est activé dans tous les tests de navigateur — c'est ainsi que fonctionnent la plupart des scripts de production
- Sans blocage de ressources dans le scénario de base — pour montrer la consommation "pure" sans optimisations
- La même réseau et le même ensemble de pages pour les trois outils
Cette approche fournit des chiffres comparables que vous pouvez appliquer à votre propre cas — en multipliant par le nombre de pages de votre projet et en divisant par le volume du tarif proxy.
requests : consommation minimale de trafic
La bibliothèque requests en Python ne télécharge que le corps de la réponse HTTP — ce que vous avez explicitement demandé. Pas de JavaScript, pas d'images, pas de requêtes supplémentaires vers le CDN. Le poids moyen d'une page HTML d'une fiche produit e-commerce dans mon test était d'environ 180-250 Ko de HTML non compressé.
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") # liste de 1000 liens
for url in urls:
response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
total_bytes += len(response.content)
print(f"Total téléchargé : {total_bytes / 1024 / 1024:.2f} Mo")
Pour 1000 pages, la consommation totale était de 190-230 Mo — soit moins de 0,25 Go. C'est l'option la plus économique, mais elle a une limitation critique : si le site rend le contenu via JavaScript (React, Vue, chargement dynamique des prix), requests obtiendra une structure de page vide sans les données nécessaires. Pour du HTML statique ou des sites avec SSR, c'est le choix idéal en termes de rapport entre le trafic et le résultat.
Puppeteer : combien pèse Chrome sans tête
Puppeteer contrôle un véritable moteur Chromium, donc il charge la page dans son intégralité : HTML, CSS, polices, images, scripts de suivi, iframes publicitaires. Même en mode sans tête, le navigateur exécute toutes les requêtes réseau qu'un utilisateur normal effectuerait dans 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 liens
for (const url of urls) {
await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
}
console.log(`Total trafic : ${(totalBytes / 1024 / 1024).toFixed(2)} Mo`);
await browser.close();
})();
Dans mon test, le poids moyen d'une page via Puppeteer était de 2,8 à 4,5 Mo, selon le nombre d'images et de scripts tiers. Pour 1000 pages, cela a donné un résultat de 3,1-4,2 Go — 15 à 18 fois plus que requests. La majorité du trafic provient des images (généralement 40-55 % du poids de la page) et des scripts tiers d'analyse, de publicité et de widgets de chat (20-30 %).
Playwright : trafic dans différents navigateurs
Playwright fonctionne de manière similaire, mais prend en charge trois moteurs — Chromium, Firefox et WebKit. La consommation de trafic entre eux diffère : WebKit en mode sans tête est traditionnellement un peu plus économe grâce à un traitement différent du contenu multimédia, tandis que Firefox charge parfois plus de données en raison des différences dans la mise en cache des ressources entre les requêtes.
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"Total trafic : {total_bytes / 1024 / 1024:.2f} Mo")
browser.close()
Sur Chromium via Playwright, le résultat était proche de Puppeteer — 2,9-4,3 Go pour 1000 pages, ce qui est logique, car les deux outils utilisent le même moteur. Sur WebKit, la consommation était de 10 à 15 % inférieure, autour de 2,6-3,7 Go, tandis que sur Firefox, elle était légèrement supérieure, 3,3-4,6 Go. La différence s'explique par les variations dans le traitement des polices, le décodage des images et le comportement de la pile réseau de chaque moteur de navigateur.
Tableau comparatif : Go pour 1000 pages
Ci-dessous, un tableau récapitulatif de toutes les options testées, arrondi à des plages pratiques. Les chiffres sont pertinents pour une page e-commerce moyenne avec des images et un ensemble typique de scripts tiers — sur les sites d'actualités ou les pages de destination avec des vidéos, la consommation sera plus élevée.
| Outil | Trafic pour 1000 pages | Rendu JS | Contourner la détection des bots |
|---|---|---|---|
| requests (Python) | 0,19-0,23 Go | Non | Faible |
| Playwright (WebKit) | 2,6-3,7 Go | Oui | Moyen |
| Puppeteer (Chromium) | 3,1-4,2 Go | Oui | Moyen |
| Playwright (Chromium) | 2,9-4,3 Go | Oui | Bon |
| Playwright (Firefox) | 3,3-4,6 Go | Oui | Moyen |
Conclusion clé : si le site ne nécessite pas de rendu JavaScript pour obtenir les données nécessaires, requests économise 15 à 20 fois plus de trafic par rapport à toute solution basée sur un navigateur. Mais si le contenu est chargé dynamiquement ou si le site vérifie activement le comportement du navigateur, il faudra payer pour le trafic de rendu du navigateur.
Comment réduire la consommation de trafic de 5 à 10 fois
Même si vous avez besoin d'un navigateur complet, la consommation de trafic peut être radicalement réduite sans perdre les données nécessaires. Voici des techniques efficaces que j'ai testées sur le même ensemble de 1000 pages.
1. Blocage des images, des polices et des médias. Les images représentent généralement plus de la moitié du poids de la page, et elles ne sont pas nécessaires pour le scraping de données textuelles.
await page.route('**/*', (route) => {
const type = route.request().resourceType();
if (['image', 'font', 'media'].includes(type)) {
route.abort();
} else {
route.continue();
}
});
Cette technique fonctionne de la même manière dans Playwright et Puppeteer et réduit le trafic de 40 à 60 % sans perte de HTML et de données textuelles.
2. Blocage des domaines tiers. Les réseaux publicitaires, l'analyse, les widgets de chat chargent leurs propres scripts et images, qui ne vous sont pas nécessaires. Vous pouvez filtrer les requêtes par domaine, en ne laissant que la ressource principale et son CDN.
3. Utilisation de "domcontentloaded" au lieu de "networkidle". Attendre le chargement complet du réseau oblige le navigateur à attendre toutes les requêtes en arrière-plan, y compris l'analyse et le chargement paresseux. Si les données apparaissent dans le DOM plus tôt, passer à un événement plus précoce accélère le scraping et réduit les chargements superflus.
4. Mise en cache des ressources statiques entre les requêtes. Si le site utilise les mêmes fichiers CSS/JS sur toutes les pages, le cache du navigateur activé (contrairement aux conditions de notre test) permet d'économiser un volume considérable lors du passage en séquentiel d'un grand nombre d'URL d'un même domaine.
5. Approche hybride. De nombreuses équipes essaient d'abord requests, et seulement si les données sont insuffisantes, elles passent à des pages spécifiques via Playwright ou Puppeteer. Cela combine une faible consommation de trafic de base avec la possibilité de rendu là où c'est vraiment nécessaire.
Avec un blocage efficace des ressources, la consommation de trafic de Puppeteer et Playwright est réduite de 3-4 Go à 0,6-1,2 Go pour 1000 pages — la différence devient nettement moins importante par rapport à requests, tout en conservant la possibilité de travailler avec le rendu JS et la protection anti-bot.
Comment choisir un proxy en fonction du volume de trafic
Le calcul du trafic influence directement le choix du type de proxy. Pour des requêtes HTTP légères via requests sur des sites statiques, les proxies de centres de données conviennent bien — ils sont rapides, peu coûteux en trafic et suffisants si le site ne vérifie pas les signaux comportementaux.
Si la tâche nécessite un rendu complet via Playwright ou Puppeteer pour contourner les systèmes anti-bots — par exemple, lors de la collecte de prix sur des marketplaces ou de la surveillance des résultats des moteurs de recherche — il est plus judicieux d'utiliser des proxies résidentiels. Ils sont moins souvent bloqués en raison de la réputation IP, ce qui est critique lorsque chaque requête "pèse" plusieurs mégaoctets et qu'une nouvelle collecte de données à cause d'un blocage coûte cher.
Pour les scénarios où le site vérifie particulièrement strictement la correspondance entre l'IP et l'agent utilisateur (services bancaires, applications avec vérification mobile), il vaut la peine d'envisager des proxies mobiles — malgré un coût de trafic plus élevé, ils offrent une confiance maximale de l'adresse IP et minimisent le nombre de requêtes répétées en raison de bans.
Indication pratique : calculez le volume de trafic selon la formule "poids d'une page × nombre de pages × coefficient de répétitions dues aux erreurs et aux bans" et comparez le Go total avec le tarif du fournisseur. L'optimisation des ressources, décrite ci-dessus, permet généralement d'économiser plus que le choix d'un type de proxy moins cher — mais la combinaison du bon outil et du bon proxy donne le maximum d'effet.
Conclusion
requests reste l'outil le plus économique en termes de trafic — environ 0,2 Go pour 1000 pages, mais il n'est pas adapté aux sites avec contenu dynamique. Puppeteer et Playwright offrent un rendu complet et un meilleur contournement de la protection, mais la consommation de trafic augmente à 3-4,5 Go pour les mêmes 1000 pages. Le blocage des images, des polices et des domaines tiers réduit cet écart de 3 à 5 fois, tout en conservant les données nécessaires.
Avant de lancer un scraping à grande échelle, calculez le volume de trafic attendu en fonction de l'outil choisi et intégrez-le dans le budget pour les proxies. Si la tâche nécessite un rendu JavaScript et une résistance aux systèmes anti-bots, commencez par un test sur un petit ensemble de pages via des proxies résidentiels — cela permettra d'évaluer précisément la consommation réelle de Go avant de lancer l'ensemble des données.