Comment réduire les coûts de bande passante proxy lors du scraping à grande échelle

Les proxys résidentiels sont facturés au gigaoctet, donc sur un forfait au Go votre bande passante est votre facture. Le piège, c’est qu’un scraper naïf gaspille la plupart des octets qu’il paie, en téléchargeant des images, polices, vidéos, et scripts de tracking qu’il ne regarde jamais, en re-téléchargeant des pages qui n’ont pas changé, et en rendant des navigateurs complets là où une simple requête HTTP suffirait. La bonne nouvelle : presque tout ce gaspillage est facile à réduire, et un scraper bien réglé utilise couramment moins de la moitié de la bande passante d’un scraper non réglé pour les mêmes données.

Ceci est un guide pratique pour faire exactement cela. Neuf tactiques, grossièrement ordonnées par impact, pour collecter les mêmes données à travers vos proxys résidentiels tout en payant pour une fraction des octets. C’est le compagnon d’efficacité de coûts du virage au Go couvert dans proxys résidentiels facturés à la bande passante.

1. Ne rendez pas un navigateur si vous n’êtes pas obligé

C’est le plus gros levier à lui seul. Un navigateur headless télécharge tout ce que la page référence : images, CSS, polices web, vidéo, analytique, scripts publicitaires. Pour la plupart du scraping, vous n’avez besoin de rien de tout ça. Si les données que vous voulez sont dans le HTML initial ou joignables via une API (section suivante), sautez le navigateur entièrement et utilisez un client HTTP simple, requests, httpx, ou Scrapy. Un seul GET HTTP peut être une fraction minuscule des octets qu’un rendu de navigateur complet tire.

Réservez le navigateur aux pages qui exigent véritablement l’exécution de JavaScript pour produire les données. Dans le doute, récupérez d’abord le HTML brut et vérifiez si vos valeurs cibles y sont déjà.

2. Frappez l’API JSON, pas le HTML

Beaucoup de sites rendent leur contenu depuis un endpoint JSON de backend que la page appelle après le chargement. Récupérer cet endpoint directement, au lieu de la page HTML complète et de ses assets, est souvent une fraction des octets et vous donne des données propres et structurées sans parsing. Ouvrez l’onglet réseau de votre navigateur, trouvez la requête qui renvoie les données (généralement un XHR/fetch renvoyant du JSON), et appelez-la directement à travers le proxy. Une réponse JSON épurée peut remplacer une page lourde plus un rendu de navigateur.

3. Bloquez les types de ressources lourds quand vous devez utiliser un navigateur

Quand une page a vraiment besoin d’un rendu, ne laissez pas le navigateur télécharger ce que vous n’utiliserez pas. Playwright et Puppeteer vous laissent tous deux intercepter les requêtes et abandonner images, médias, polices, et souvent feuilles de style avant qu’elles n’atteignent le proxy, ce qui réduit typiquement la bande passante de bien plus de la moitié. Dans Playwright :

await context.route("**/*", (route) => {
  const type = route.request().resourceType();
  if (["image", "media", "font"].includes(type)) {
    return route.abort();          // jamais téléchargé, jamais facturé
  }
  return route.continue();
});

Gardez document, script, xhr, et fetch ; jetez le reste. Le même motif et les particularités de Chromium sont dans comment utiliser des proxys résidentiels avec Playwright.

4. Gardez la compression active

Le texte se compresse environ de 5 à 10x, donc une réponse HTML encodée en gzip ou brotli est une fraction de la taille brute. La plupart des clients HTTP envoient Accept-Encoding: gzip, deflate, br et décompressent de façon transparente par défaut, mais vérifiez que vous ne l’avez pas désactivé, et ne retirez jamais l’en-tête. Si vous posez les en-têtes manuellement, incluez-le :

headers = {"Accept-Encoding": "gzip, br", "User-Agent": "..."}

Les octets qui traversent le proxy sont les octets compressés, donc c’est une réduction directe et gratuite de ce qui vous est facturé.

5. Utilisez des requêtes conditionnelles pour que les pages inchangées ne coûtent presque rien

Pour tout crawl récurrent, ne re-téléchargez pas les pages aveuglément. Les requêtes conditionnelles HTTP laissent le serveur vous dire « rien n’a changé » dans une réponse 304 minuscule au lieu de renvoyer le corps entier. Stockez l’ETag ou le Last-Modified de chaque fetch et renvoyez-le :

# Au re-fetch, envoyer le validateur stocké
headers = {"If-None-Match": stored_etag}      # ou If-Modified-Since
r = client.get(url, headers=headers)
if r.status_code == 304:
    pass   # inchangé : quelques octets au lieu de la page complète

Un 304 ne coûte presque rien comparé à une page complète, et sur un travail de surveillance où la plupart des pages changent rarement, cela seul peut réduire drastiquement la bande passante.

6. Ne re-téléchargez pas ce qui n’a pas changé

Lié, mais plus large que les validateurs HTTP : suivez ce que vous avez déjà collecté et sautez-le. Utilisez les horodatages lastmod du sitemap pour trouver les URL changées, gardez un hash de contenu par page et sautez le re-traitement de contenu identique, et dédupliquez votre frontière de crawl pour ne pas récupérer la même URL deux fois dans une exécution. Le gigaoctet le moins cher est celui que vous ne téléchargez jamais.

7. Récupérez seulement les octets dont vous avez besoin

Si vous avez seulement besoin des en-têtes d’un fichier ou de son premier morceau (une vérification de métadonnées, un sniff de content-type), ne téléchargez pas le tout. Une requête HEAD renvoie les en-têtes sans corps, et une requête Range tire seulement les octets que vous spécifiez là où le serveur le supporte :

client.head(url)                                   # en-têtes seulement, pas de corps
client.get(url, headers={"Range": "bytes=0-2047"}) # les 2 premiers Ko seulement

Cela compte le plus quand votre crawl touche de gros médias, des PDF, ou des téléchargements où vous n’avez besoin que d’une petite partie ou seulement de métadonnées.

8. Rendez les réessais et le geo-targeting efficaces

Chaque tentative échouée dépense encore de la bande passante, donc les réessais gaspilleurs gonflent votre facture en silence. Appliquez un backoff et plafonnez les réessais plutôt que de marteler une URL qui échoue, et évitez les filtres géo trop serrés (pays + ville + ASN d’un coup) qui font échouer et réessayer les requêtes quand aucune IP correspondante n’est libre, desserrez plutôt un filtre. Posez des timeouts sensés pour qu’une réponse bloquée ne traîne pas, et accordez votre stratégie de session au travail pour ne pas ré-établir de flux inutilement. Les requêtes efficaces sont des requêtes bon marché.

9. Mesurez les octets par enregistrement

Vous ne pouvez pas réduire ce que vous ne mesurez pas. Suivez la bande passante par travail et, mieux, les octets par enregistrement extrait avec succès, et le gaspillage se révèle de lui-même : une page coûtant des mégaoctets par ligne tire généralement des assets que vous pourriez bloquer ou rend là où vous auriez pu frapper une API. Journalisez-le, observez la tendance, et optimisez d’abord les pires contrevenants.

Une note sur le faire de façon responsable

Réduire la bande passante n’est pas seulement moins cher pour vous, c’est plus léger pour les sites dont vous collectez : moins de requêtes et des requêtes plus petites signifient moins de charge sur leurs serveurs. Cela aligne l’efficacité de coûts avec le bon civisme. Continuez à collecter des données publiques, respectez les conditions et rate limits de chaque site, et laissez l’efficacité réduire votre empreinte. Notre politique d’usage acceptable est la source de vérité pour ce qui est permis sur Shifter.

FAQ

Qu’est-ce qui utilise le plus de bande passante lors du scraping à travers des proxys ? Le rendu de navigateur complet, de loin, parce qu’il télécharge chaque image, police, vidéo, et script de la page. Réduire le rendu (ou bloquer les types de ressources lourds quand vous devez rendre) est le changement à plus fort impact que vous pouvez faire.

Bloquer les images et polices casse-t-il le scraping ? Généralement non, vous en avez rarement besoin pour l’extraction de données. Testez que le site ne charge pas le contenu cible en lazy-load derrière des images ; pour la grande majorité des travaux, bloquer les requêtes d’image, de média, et de police est sûr et réduit la bande passante substantiellement.

Les proxys résidentiels facturent-ils les requêtes échouées ou bloquées ? Les octets qui traversent le proxy sont facturables, donc les tentatives échouées et les réessais coûtent encore de la bande passante. C’est pourquoi les réessais efficaces, les timeouts sensés, et l’évitement des filtres géo trop serrés (qui causent des échecs) comptent pour votre facture.

Est-il permis de frapper l’API JSON d’un site ? Appeler un endpoint public que la page elle-même utilise est une pratique courante et bien plus efficace, mais les conditions et rate limits du site s’appliquent toujours. Collectez de façon responsable et obtenez un conseil juridique pour tout ce qui est incertain.

Combien puis-je réalistement économiser ? Cela varie selon la cible, mais sauter le rendu inutile, bloquer les ressources lourdes, et ne pas re-télécharger les pages inchangées réduisent couramment la bande passante totale de plus de la moitié pour les mêmes données extraites.

En résumé

Sur un forfait au Go, l’efficacité de bande passante est l’efficacité de coûts, et la plupart des scrapers laissent beaucoup sur la table : ils rendent là où ils pourraient récupérer, téléchargent des assets qu’ils ne lisent jamais, et re-tirent des pages qui n’ont jamais changé. Travaillez cette liste, sautez le navigateur quand vous le pouvez, frappez l’API, bloquez les ressources lourdes, gardez la compression active, utilisez des requêtes conditionnelles, ne re-téléchargez pas les pages inchangées, récupérez seulement ce dont vous avez besoin, rendez les réessais efficaces, et mesurez, et les mêmes données reviennent pour une fraction des octets.

Cette efficacité se compose avec la qualité du pool : des IP propres signifient moins de blocages et de réessais, ce qui est moins d’octets gaspillés, alors il vaut la peine de choisir les bons proxys pour le scraping en plus de régler votre client. Voyez les forfaits au Go sur la page tarifs, puis pointez un scraper bien réglé vers le gateway résidentiel et regardez les octets chuter.