Comment réduire les coûts de bande passante des proxies : Réduisez votre facture de GB de 60 à 90 %

Avec les proxies payés au gigaoctet, votre facture est en octets, pas en requêtes — et la plupart de ces octets sont des images et des polices que vous ne parsez jamais. Voici comment les éliminer et réduire une facture résidentielle de GB de plus de moitié.

Avec les proxies payés au gigaoctet, votre facture est en octets, pas en requêtes — et la vérité inconfortable est que la plupart de ces octets sont des images, polices et feuilles de style que vous ne parsez jamais. Une seule photo de produit en pleine résolution peut peser 2,2 Mo ; un rendu complet d'une page dans un navigateur peut atteindre 2 à 5 Mo. Le HTML allégé que vous extrayez réellement est souvent inférieur à 150 Ko. Éliminez le reste et une facture résidentielle de GB chute de 60 à 90 %. Ce guide est le manuel pratique : bloquez les ressources, ignorez les pages inchangées, compressez et orientez-vous vers JSON au lieu de HTML.

Tout d'abord, sachez ce pour quoi vous êtes facturé

La bande passante résidentielle est mesurée sur la somme des données transmises dans les deux sens : en-têtes de requête plus corps de requête, et en-têtes de réponse plus corps de réponse. Cela signifie que chaque ressource qu'une page charge — chaque image, police et script de suivi — apparaît sur votre facture même si rien de tout cela n'alimente votre parseur. L'objectif d'optimisation est simple : téléchargez uniquement les octets que vous extrayez. Tout le reste est du gaspillage que vous payez.

Bloquer les ressources dans un navigateur sans tête

Si vous pilotez un navigateur, c'est le levier le plus important. Playwright et Puppeteer vous permettent tous deux d'intercepter les requêtes et d'annuler les types de ressources dont vous n'avez pas besoin. Bloquer les images, médias, polices et feuilles de style réduit généralement le poids de la page de la majorité — le DOM se construit toujours, donc vos sélecteurs et tout JSON d'hydratation survivent :

// 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' });

Deux précautions : ne bloquez pas les appels XHR/fetch qui transportent les données que vous recherchez, et testez que la page affiche toujours ce dont vous avez besoin — un blocage excessif peut casser la logique propre d'un site. Si vous hésitez entre un navigateur et des requêtes simples, notre analyse du coût du rendu par rapport aux requêtes HTTP montre l'écart de 10 à 50 fois qui rend cette décision importante.

Ignorez les pages qui n'ont pas changé

L'octet le moins cher est celui que vous ne téléchargez pas. Deux techniques réduisent le gaspillage de re-téléchargement sur les tâches de surveillance. Une requête HEAD ne récupère que les en-têtes pour vérifier Content-Length ou Last-Modified avant de vous engager dans le GET complet. Mieux encore, un GET conditionnel envoie l'ETag ou l'horodatage de la dernière fois et le serveur répond 304 Not Modified avec un corps vide lorsque rien n'a changé — vous payez pour quelques octets d'en-tête au lieu de la page entière :

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

Pour un scraper qui vérifie à nouveau les mêmes pages quotidiennement, les GET conditionnels seuls peuvent réduire considérablement la bande passante, car la plupart des pages ne changent pas entre les exécutions.

Acceptez toujours la compression

Le texte se compresse bien — HTML, JSON et CSS rétrécissent de 70 à 90 % avec gzip ou brotli — et vous êtes facturé sur la taille compressée qui traverse réellement le fil. Envoyez un en-tête Accept-Encoding et laissez le serveur compresser. Dans requests de Python, c'est activé par défaut lorsque vous ne vous y opposez pas ; dans un client brut, demandez-le explicitement :

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

Orientez-vous vers JSON, pas HTML

Le plus grand gain structurel est de sauter complètement la page rendue. De nombreux sites s'hydratent à partir d'un point de terminaison JSON qui transporte les mêmes données en une fraction des octets — le prix et le stock d'un produit en tant que réponse API de 10 Ko au lieu d'une page rendue de 3 Mo. Trouvez l'appel XHR dans l'onglet Réseau de votre navigateur et ciblez-le directement. Les boutiques Shopify sont l'exemple classique : le point de terminaison products.json vous fournit tout le catalogue sans aucun HTML. Lorsque vous pouvez lire l'API, faites-le — c'est la différence entre kilooctets et mégaoctets par enregistrement.

Laissez l'API compter les octets pour vous

Si vous préférez ne pas ajuster manuellement les règles de blocage par site, une Scraper API qui rend uniquement lorsque nécessaire et renvoie du markdown ou JSON analysé fait le décapage des ressources pour vous — vous recevez le contenu extrait, pas les mégaoctets d'où il provient. Et sur les proxies résidentiels payés au gigaoctet, les économies sont directes : moins d'octets sur le fil signifie moins de dollars sur la facture, sans rien perdre des données que vous conservez. Pour une vue d'ensemble de ce qu'un gigaoctet achète réellement, consultez notre analyse du prix par gigaoctet.

Scrapez plus léger sur les proxies résidentiels payés au gigaoctet

Questions fréquemment posées

Comment la bande passante des proxies est-elle calculée ?

Par le total des octets transmis dans les deux sens : en-têtes de requête plus corps de requête, et en-têtes de réponse plus corps de réponse. Ainsi, chaque image, police et script qu'une page charge compte pour votre utilisation, pas seulement le HTML que vous parsez. C'est pourquoi bloquer les ressources inutilisées et ignorer les pages inchangées se traduit directement par une facture plus basse sur les plans payés au gigaoctet.

Le blocage des images casse-t-il le scraping ?

Pas si vous êtes prudent. Bloquer les images, médias, polices et feuilles de style laisse le DOM et JavaScript intacts, donc vos sélecteurs et tout JSON d'hydratation fonctionnent toujours — vous ne sautez que la charge visuelle. Le risque est de bloquer excessivement : n'annulez jamais les appels XHR/fetch qui transportent vos données, et testez que la page produit toujours ce dont vous avez besoin avant de passer à l'échelle.

Quelle est la plus grande économie de bande passante ?

S'orienter vers un point de terminaison JSON au lieu de rendre la page complète, là où il en existe un. Une réponse API de 10 Ko peut remplacer un rendu de 3 Mo pour le même enregistrement — une réduction de 99 %. Après cela, bloquer les ressources dans un navigateur sans tête et utiliser les GET conditionnels lors des re-crawls sont les plus grands gains. La compression est presque gratuite et devrait toujours être activée.

Combien puis-je économiser de manière réaliste ?

Bloquer les ressources réduit généralement le poids d'une page rendue de bien plus de la moitié ; les GET conditionnels peuvent réduire la bande passante de re-crawl à presque zéro pour les pages qui ne changent pas ; et passer du HTML à une route JSON est souvent une réduction de plus de 90 % par enregistrement. Combinés, une réduction de 60 à 90 % d'une facture résidentielle de GB est un objectif réaliste pour la plupart des projets.

Rien de tout cela ne change ce que vous extrayez — cela change ce que vous payez pour l'extraire. Bloquez les ressources que vous ne lisez jamais, ignorez les pages qui n'ont pas bougé, acceptez la compression et préférez les routes JSON aux rendus complets. Sur les proxies payés au gigaoctet, ces quatre habitudes réduisent régulièrement une facture de plus de la moitié. Pour l'architecture qui évolue à travers des millions de pages, consultez notre guide sur l'architecture de scraping à grande échelle.

Obtenez du contenu analysé sans les octets gaspillés