Sur un forfait de proxy résidentiel au Go, la bande passante est l’unité que vous achetez, donc choisir le bon forfait se résume à une question : combien de gigaoctets utiliserez-vous réellement en un mois ? Estimez trop bas et vous heurtez le dépassement ou le throttling en milieu de mois ; estimez trop haut et vous surpayez pour une marge que vous ne touchez jamais. La bonne nouvelle, c’est que la bande passante est estimable, pas un mystère. Avec une formule, quelques tailles de page réalistes, et une mesure de cinq minutes, vous pouvez dimensionner un forfait en confiance.
Ce guide est pour les équipes qui planifient l’usage de proxys. Nous construirons l’estimation étape par étape, l’ancrerons dans une mesure réelle, et parcourrons des exemples chiffrés pour des charges de travail courantes.
La formule
Tout se réduit à ceci :
Go mensuels ≈ (requêtes par mois × taille moyenne de réponse × facteur de surcoût) / octets par GoQuatre entrées, et l’une d’elles domine. Prenons-les dans l’ordre de l’impact.
Étape 1 : taille moyenne de réponse (le grand moteur)
Combien d’octets reviennent par requête est là où les estimations vivent ou meurent, et cela varie de plus de 10x selon comment vous récupérez. Fourchettes typiques :
| Ce que vous récupérez | Taille typique par requête |
|---|---|
| Réponse JSON d’API épurée | 5 à 50 Ko |
| Page HTML seule (sans assets) | 100 à 500 Ko |
| Page complète dans un navigateur headless (images, CSS, JS, polices) | 1 à 5 Mo+ |
Le facteur individuel le plus grand de votre facture est de savoir si vous rendez un navigateur complet ou récupérez le HTML/JSON directement. Un navigateur télécharge tout sur la page ; une requête HTTP simple en tire une fraction. Si vous pouvez tirer vos données du HTML ou d’une API, votre taille par requête, et votre bande passante, chutent d’un ordre de grandeur. (Cela, plus le blocage d’assets, est le cœur de comment réduire les coûts de bande passante proxy.)
Ne devinez pas ce chiffre si vous pouvez le mesurer, voir l’Étape 4.
Étape 2 : requêtes par mois
C’est généralement des pages (ou enregistrements) fois la fréquence :
requêtes par mois = éléments × vérifications par jour × 30Un moniteur de prix qui suit 10 000 produits une fois par jour, ce sont 10 000 × 1 × 30 = 300 000 requêtes par mois. Une construction de jeu de données ponctuelle n’est que le nombre total de pages, sans multiplicateur de fréquence. Incluez la pagination : si chaque « élément » s’étend sur trois pages de résultats, multipliez en conséquence.
Étape 3 : le facteur de surcoût
Les crawls réels ne sont pas efficaces à 100%. Les réessais, redirections, et tentatives échouées traversent tous le proxy et coûtent tous de la bande passante, une requête bloquée ou expirée a quand même dépensé des octets. Ajoutez un facteur de surcoût par-dessus votre estimation propre :
- Cibles faciles et ouvertes : ~1,1 (10% de surcoût)
- Sites typiques : ~1,2 (20%)
- Cibles bien défendues (blocages/réessais fréquents) : ~1,3 ou plus
Plus la cible est dure, plus il y a de réessais, donc plus le facteur est élevé. Réduire votre taux de blocage (meilleure qualité d’IP, rythme sensé) le rétrécit directement, voir comment éviter de se faire bloquer.
Étape 4 : mesurez votre taille réelle par page (ne devinez pas)
Le chemin le plus rapide vers une estimation fiable est de récupérer un échantillon représentatif de votre cible réelle à travers le proxy et de mesurer les octets. La taille de réponse en octets est len(response.content) :
import os, requests, statistics
USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]proxy_url = f"http://{USER}-country-us:{PASS}@p.shifter.io:443"proxies = {"http": proxy_url, "https": proxy_url}
sample_urls = [ ... ] # 20-50 URL cibles représentativessizes_kb = []for url in sample_urls: r = requests.get(url, proxies=proxies, timeout=30) sizes_kb.append(len(r.content) / 1024)
avg_kb = statistics.mean(sizes_kb)print(f"avg {avg_kb:.0f} KB/request (n={len(sizes_kb)})")Lancez-le contre 20 à 50 URL réelles et vous avez une taille moyenne fondée au lieu d’une supposition. Notez que cela mesure les octets compressés qui traversent réellement le proxy (gardez Accept-Encoding actif), ce qui vous est facturé. La configuration complète du client est dans proxys résidentiels avec Python.
Exemples chiffrés
En utilisant Go mensuels = requêtes × taille_moy × surcoût / 1 000 000 (Ko vers Go, décimal) :
Surveillance des prix, HTML seul. 10 000 produits, quotidien, ~200 Ko/page, surcoût 1,15.
300 000 × 200 Ko × 1,15 = 69 000 000 Ko ≈ 69 Go/mois.
Le même travail, mais avec rendu de navigateur complet. ~2 Mo/page au lieu de 200 Ko.
300 000 × 2 000 Ko × 1,15 = 690 000 000 Ko ≈ 690 Go/mois.
Les mêmes données, 10x la bande passante, c’est le coût du rendu quand vous n’en aviez pas besoin (voir avec Playwright pour bloquer les assets si vous devez rendre).
Surveillance de recherche/classement, réponses épurées. 500 requêtes, 4x/jour, ~30 Ko chacune, surcoût 1,2.
500 × 4 × 30 × 30 Ko × 1,2 = 2 160 000 Ko ≈ 2,2 Go/mois. Petit et bon marché.
Construction de jeu de données ponctuelle. 2 000 000 de pages, ~300 Ko HTML, surcoût 1,2.
2 000 000 × 300 Ko × 1,2 = 720 000 000 Ko ≈ 720 Go, une fois, pas mensuel.
Le motif est clair : la taille de réponse et le choix de rendu dominent ; le nombre de requêtes évolue linéairement ; le surcoût est un multiplicateur modeste.
De l’estimation au forfait
Transformez le chiffre en forfait avec un peu de discipline :
- Ajoutez une marge. Dimensionnez le forfait à votre estimation plus 20 à 30%, pour la croissance dans le mois et l’erreur d’estimation. Être à court en milieu de cycle est plus perturbant qu’un peu de marge.
- Connaissez les conditions de dépassement. Vérifiez comment votre fournisseur gère le dépassement, par-Go supplémentaire, throttling, ou un arrêt net, pour qu’un mois chargé ne vous surprenne pas.
- Rapprochez chaque semaine. Comparez l’usage réel à votre estimation tôt dans le cycle et ajustez. L’usage réel vous enseigne votre vraie taille par page et taux de blocage plus vite que n’importe quelle supposition.
- Rétrécissez le chiffre avant d’acheter plus. Souvent le gigaoctet le moins cher est celui que vous ne dépensez pas, sautez le rendu, bloquez les assets, et ne re-téléchargez pas les pages inchangées (réduire les coûts de bande passante proxy) avant d’agrandir le forfait. C’est le modèle au Go qui fait que l’efficacité paie (l’ère du par-port est révolue).
FAQ
Comment estimer la bande passante si je n’ai jamais lancé le travail ? Mesurez un échantillon représentatif de vos pages cibles à travers le proxy (Étape 4) pour obtenir une taille réelle par requête, puis branchez-la dans la formule avec votre nombre de requêtes et un facteur de surcoût. Un échantillon mesuré bat toute estimation générique.
Qu’est-ce qui utilise le plus de bande passante ? Le rendu de navigateur complet, de loin, il télécharge chaque image, police, et script. Récupérer le HTML ou une API JSON directement peut réduire la taille par requête de 10x. Le choix de rendu est le plus gros levier sur votre facture.
Les requêtes échouées et réessayées comptent-elles dans ma bande passante ? Oui. Toute requête qui traverse le proxy utilise de la bande passante, y compris les blocages, redirections, et réessais. C’est pourquoi l’estimation inclut un facteur de surcoût, et pourquoi réduire votre taux de blocage baisse le coût.
1 Go, est-ce 1 000 Mo ou 1 024 Mo ? Cela dépend de la définition de facturation du fournisseur, décimale (1 000) ou binaire (1 024). La différence est d’environ 7%, correcte pour estimer, mais confirmez laquelle utilise votre fournisseur quand vous dimensionnez près d’une limite de forfait.
Combien de marge devrais-je ajouter ? Prévoyez votre estimation plus 20 à 30%, pour absorber la croissance et l’erreur d’estimation dans le mois. Puis rapprochez de l’usage réel et ajustez, plutôt que de suracheter d’avance.
En résumé
Estimer la bande passante d’un proxy résidentiel n’est pas deviner : multipliez les requêtes par une taille moyenne de réponse mesurée et un facteur de surcoût, convertissez en Go, et ajoutez une marge. Les deux choses qui bougent le plus le chiffre sont comment vous récupérez (HTML/JSON bat le navigateur complet d’environ 10x) et à quelle fréquence vous réessayez (une meilleure qualité d’IP signifie moins d’octets gaspillés), alors mesurez un échantillon réel avant de vous engager, et réduisez le chiffre avant d’acheter plus.
Une fois que vous avez une estimation, la page tarifs présente les forfaits au Go pour que vous puissiez faire correspondre un palier à votre chiffre plus la marge, et pointez un scraper bien réglé vers le gateway résidentiel pour garder l’usage réel proche du forfait.