Quand vous payez le trafic proxy au gigaoctet, chaque octet d’une page coûte le même prix : le paragraphe que vous cherchiez, le menu autour, le script d’analyse, l’image principale et le fichier de police. La plupart des équipes savent que les pages sont lourdes. Peu savent quelle part de ce qu’elles téléchargent correspond aux données qu’elles conservent réellement.
Nous l’avons mesuré. Le 8 octobre 2026, nous avons récupéré les pages d’accueil des 1 000 premiers domaines du classement Tranco, suivi un lien de type article depuis chacune, et mesuré où vont les octets : sur le fil, dans le HTML, et dans tout ce qu’un navigateur télécharge. Cette étude présente les résultats, le code que nous avons utilisé, et ce que cela signifie pour les budgets de scraping.
Points clés
- Le contenu principal d’une page typique représente environ 1 % de son HTML. Sur la page de contenu médiane, 3,2 Ko de texte principal se trouvaient dans 260 KiB de HTML.
- La compression réalise gratuitement l’essentiel de l’économie. Le même HTML arrivait en 46 KiB sur le fil, soit environ 5,4 fois plus petit, de sorte que le texte principal représentait environ 6 % des octets réellement transférés.
- Les scripts intégrés constituent la plus grosse part individuelle du HTML. Sur l’ensemble des pages de contenu, le JavaScript intégré représentait 38 % des octets du HTML, le CSS intégré 15 % et le SVG intégré 10 %. Le texte principal représentait 1,3 %.
- Un navigateur multiplie la facture. La page de contenu médiane chargeait 2,6 Mo et 81 requêtes dans un navigateur headless. Le document HTML lui-même représentait environ 3 % de cela.
- Bloquer les images, les médias et les polices réduit de moitié le trafic du navigateur. Sur l’ensemble des pages, cela supprimait 48 % des octets ; sur la page médiane, un chargement allégé représentait 71 % d’un chargement complet.
Comment nous avons mesuré
- Échantillon. Les 1 000 premiers domaines de la liste Tranco (liste Q2K34). Beaucoup sont des hôtes API, CDN ou de tracking sans site web, de sorte que 431 sites distincts ont renvoyé une page d’accueil exploitable. Depuis chaque page d’accueil, nous avons suivi le premier lien du même site ressemblant à une page de contenu (un chemin se terminant par un slug de quatre mots ou plus, excluant les pages de connexion, légales et d’aide), ce qui a donné 278 pages de contenu exploitables.
- Couche HTML. Une requête par page avec un User-Agent de navigateur de bureau classique et la compression activée. Nous avons enregistré les octets reçus, les avons décompressés, et avons découpé le HTML en scripts intégrés, styles intégrés (y compris les attributs
style), SVG intégré et JSON-LD. Nous avons extrait le contenu principal avec trafilatura, une bibliothèque d’extraction open-source, et compté ses octets comme texte normalisé. - Couche navigateur. Nous avons chargé chaque page de contenu dans Chromium headless, attendu l’événement de chargement plus trois secondes, et additionné les octets transférés pour chaque réponse par type de ressource. Puis nous l’avons chargée à nouveau avec les images, les médias et les polices bloqués.
- Exclusions. Les réponses d’erreur, les réponses non-HTML et les pages de blocage (pages de challenge, pages « accès refusé » et réponses quasi vides) ont été exclues avant l’analyse, de sorte que les résultats décrivent des pages ayant effectivement servi du contenu.
La couche HTML
| Mesure (médiane par page) | Pages de contenu | Pages d’accueil |
|---|---|---|
| Pages mesurées | 278 | 431 |
| Octets sur le fil | 46 KiB | 51 KiB |
| HTML après décompression | 260 KiB | 270 KiB |
| Texte du contenu principal | 3,2 Ko | 1,4 Ko |
| Contenu principal en part du HTML | 1,2 % | 0,6 % |
| Contenu principal en part des octets transférés | 6,2 % | 3,1 % |
| Tout le texte visible en part du HTML | 3,6 % | 2,4 % |
Les pages de contenu portent plus de texte que les pages d’accueil, comme attendu, mais la forme générale est la même : le texte qu’un scraper conserve est une infime fraction du document qu’il télécharge. Même en comptant chaque mot visible de la page, y compris les menus, les pieds de page et les bandeaux de cookies, le texte représentait moins de 4 % du HTML.
Où va le reste ? Sur l’ensemble des 278 pages de contenu :
| Partie du HTML | Part des octets HTML |
|---|---|
| JavaScript intégré | 37,5 % |
| CSS intégré et attributs style | 15,4 % |
| SVG intégré | 9,8 % |
| Données structurées JSON-LD | 0,9 % |
| Texte du contenu principal | 1,3 % |
| Balisage, attributs et tout le reste | 35,1 % |
Le JavaScript intégré est le plus gros bloc individuel : état de framework, configuration et code de tracking intégrés directement dans la page. Les sites modernes expédient souvent toutes les données de la page sous forme de blob JSON dans une balise script et les affichent côté client, ce qui explique pourquoi les scripts dépassent en poids le texte qu’ils finissent par afficher.
C’est aussi une opportunité. Le JSON-LD de ces pages représentait en moyenne moins de 1 % du HTML, et là où une page intègre ses données sous forme de JSON, ce blob est généralement beaucoup plus propre à analyser que le balisage rendu. Nos guides sur l’extraction du JSON-LD plutôt que l’analyse du HTML et sur la recherche de l’API derrière la page couvrent les deux approches.
La compression compte plus que tout le reste à ce niveau. La page médiane rétrécissait 5,4 fois pendant le transit. Seulement 10 des 278 pages de contenu étaient servies non compressées, mais un scraper qui ne demande pas la compression reçoit les 260 KiB complets à chaque fois. Si votre client HTTP envoie Accept-Encoding: gzip, deflate, br, vous payez déjà pour 46 KiB, pas pour 260.
La couche navigateur
Rendre une page dans un navigateur télécharge tout ce que la page demande, pas seulement le document.
| Mesure (par page de contenu) | Valeur |
|---|---|
| Pages mesurées dans le navigateur | 274 |
| Octets transférés médians, chargement complet | 2,6 Mo |
| Moitié médiane des pages | 1,2 à 4,3 Mo |
| Requêtes médianes, chargement complet | 81 |
| Document HTML en part du chargement complet (médiane) | 3 % |
| Texte du contenu principal en part du chargement complet (médiane) | 0,13 % |
Par type de ressource, sur l’ensemble des chargements complets :
| Type de ressource | Part des octets |
|---|---|
| Images | 38,1 % |
| Scripts | 35,9 % |
| Médias (vidéo et audio) | 7,4 % |
| Polices | 6,6 % |
| Feuilles de style | 2,8 % |
| Documents HTML | 2,4 % |
| Appels API (fetch et XHR) | 4,9 % |
| Autre | 1,9 % |
Bloquer les images, les médias et les polices, dont un scraper n’a presque jamais besoin, ramenait la page médiane à 1,5 Mo et 55 requêtes. Sur l’ensemble des pages, le chargement bloqué transférait 52 % des octets du chargement complet. Les scripts sont plus difficiles à bloquer sans risque, car la page a souvent besoin d’eux pour afficher le contenu que vous recherchiez.
Ce que cela signifie pour un budget de scraping
Prenez une tâche qui collecte un million de pages de contenu par mois et ne conserve que leur texte principal. En utilisant les médianes ci-dessus :
| Comment les pages sont récupérées | Trafic par million de pages |
|---|---|
| Texte principal seul, si on pouvait ne récupérer que cela | environ 3,2 Go |
| HTML seul, compressé | environ 47 Go |
| HTML seul, non compressé | environ 265 Go |
| Navigateur, images, médias et polices bloqués | environ 1,5 To |
| Navigateur, chargement complet | environ 2,6 To |
L’écart entre la première ligne et la dernière est d’environ 800 fois. L’ordre pratique des économies en découle :
- Récupérer le HTML sans navigateur chaque fois que les données se trouvent dans le HTML. Cela seul fait la différence entre gigaoctets et téraoctets.
- Toujours demander la compression. Elle réduit le trafic HTML d’environ cinq fois sans aucun coût.
- Quand le rendu est nécessaire, bloquer les images, les médias et les polices. Cela réduit à peu près de moitié le trafic du navigateur.
- Chercher une source plus légère des mêmes données : JSON-LD, un blob JSON intégré ou l’API que la page elle-même appelle.
Notre guide sur la réduction des coûts de bande passante proxy couvre chacune de ces techniques en pratique, et l’estimation de votre bande passante mensuelle montre comment transformer les poids de page en un plan.
Mesurez vos propres pages
Les médianes sur les principaux sites sont un point de départ ; ce sont vos cibles qui comptent. La fonction ci-dessous récupère une page et indique où vont ses octets, en utilisant la même méthode que l’étude :
import gzip
import re
import zlib
import brotli
import requests
import trafilatura
from lxml import html as lxml_html
def decode(raw, content_encoding):
"""Undo Content-Encoding by hand, so we can count the compressed bytes first."""
for coding in reversed([c.strip() for c in content_encoding.lower().split(",") if c.strip()]):
if coding == "gzip":
raw = gzip.decompress(raw)
elif coding == "br":
raw = brotli.decompress(raw)
elif coding == "deflate":
raw = zlib.decompress(raw)
return raw
def size(text):
return len(text.encode("utf-8"))
def payload_breakdown(url, session=None):
"""Where the bytes of one HTML page go, from the wire down to the main content."""
session = session or requests.Session()
response = session.get(url, timeout=30, stream=True,
headers={"Accept-Encoding": "gzip, deflate, br"})
wire = response.raw.read(decode_content=False)
page = decode(wire, response.headers.get("Content-Encoding", "")).decode(
response.encoding or "utf-8", errors="replace")
doc = lxml_html.document_fromstring(page)
scripts = doc.xpath("//script")
json_ld = sum(size(s.text or "") for s in scripts if s.get("type") == "application/ld+json")
inline_js = sum(size(s.text or "") for s in scripts
if not s.get("src") and s.get("type") != "application/ld+json")
inline_css = sum(size(s.text or "") for s in doc.xpath("//style")) + sum(size(v) for v in doc.xpath("//@style"))
inline_svg = sum(size(lxml_html.tostring(s, encoding="unicode"))
for s in doc.xpath("//*[local-name()='svg'][not(ancestor::*[local-name()='svg'])]"))
main_text = trafilatura.extract(page, include_tables=True) or ""
return {
"status": response.status_code,
"wire_bytes": len(wire),
"html_bytes": size(page),
"inline_js": inline_js,
"inline_css": inline_css,
"inline_svg": inline_svg,
"json_ld": json_ld,
"main_text": size(re.sub(r"\s+", " ", main_text).strip()),
}Elle lit le corps de la réponse avant décompression, de sorte que wire_bytes correspond à ce que vous avez réellement transféré, puis la décode manuellement. Exécutez-la sur quelques pages de chacune de vos cibles :
from payload import payload_breakdown
import requests
session = requests.Session()
session.headers["User-Agent"] = "ExampleStudy/1.0 (+https://example.com/bot)"
b = payload_breakdown("https://en.wikipedia.org/wiki/Web_scraping", session)
print(b)
print(f"main content: {b['main_text'] / b['html_bytes']:.1%} of the HTML, "
f"{b['main_text'] / b['wire_bytes']:.1%} of the bytes transferred"){'status': 200, 'wire_bytes': 46860, 'html_bytes': 236286, 'inline_js': 6964, 'inline_css': 6303, 'inline_svg': 0, 'json_ld': 640, 'main_text': 26979}
main content: 11.4% of the HTML, 57.6% of the bytes transferredWikipedia est une page efficace selon ces standards : son texte principal représente plus de 11 % du HTML, soit près de dix fois la médiane que nous avons mesurée. Vos cibles se situeront quelque part sur cette plage, et savoir où vous indique si la collecte HTML seule, la compression ou une autre source de données permettra d’économiser le plus.
Limites de la mesure
- Uniquement les principaux sites. Les 1 000 premiers domaines sont des sites volumineux et bien conçus techniquement. Les sites plus petits peuvent être plus légers ou bien plus lourds.
- Une seule page de contenu par site. Nous avons suivi le premier lien de type article sur chaque page d’accueil. Les pages produit, les résultats de recherche et les pages de listing peuvent différer.
- Le contenu principal est une estimation. Les bibliothèques d’extraction peuvent manquer ou inclure trop de contenu, particulièrement sur des pages majoritairement composées de navigation. Traitez les chiffres de texte principal comme approximatifs ; les mesures d’octets sont exactes.
- Un seul instantané, un seul réseau. Les pages ont été récupérées une fois, le 8 octobre 2026, depuis un seul réseau en Europe. Les sites servent des pages, publicités et médias différents selon la localisation et dans le temps.
- Les chargements navigateur étaient plafonnés. Nous avons arrêté de mesurer trois secondes après l’événement de chargement. Les pages qui continuent à charger du contenu par la suite auraient transféré plus que ce que nous avons enregistré.
FAQ
Quelle part d’une page web correspond au contenu réel ?
Sur la page de contenu médiane parmi les 1 000 principaux sites, le texte principal représentait environ 1,2 % du HTML et environ 6 % des octets compressés transférés. Dans un chargement navigateur complet, il représentait environ 0,13 % des octets.
Bloquer les images réduit-il la bande passante proxy ?
Oui. Bloquer les images, les médias et les polices dans un navigateur headless a supprimé 48 % des octets sur notre échantillon. Les images à elles seules représentaient 38 % du trafic navigateur.
Est-il moins cher de scraper sans navigateur ?
Généralement par une large marge. La page de contenu médiane pesait 46 KiB en HTML compressé et 2,6 Mo en chargement navigateur complet, soit une différence de plus de 50 fois.
Faut-il demander des réponses compressées lors du scraping ?
Oui. La page médiane était 5,4 fois plus petite compressée. La plupart des clients HTTP demandent la compression par défaut, mais vérifiez-le, car un client qui ne le fait pas paie la taille complète de chaque page.
L’essentiel à retenir
Les données qu’un scraper conserve représentent une part infime de ce qu’il télécharge : environ 1 % du HTML d’une page typique et une fraction de pour cent de ce qu’un navigateur récupère. La majeure partie de cette surcharge est évitable. Récupérez le HTML plutôt que de faire le rendu quand c’est possible, gardez la compression active, bloquez les ressources lourdes quand le rendu est nécessaire, et cherchez des données structurées ou des API qui transportent la même information en bien moins d’octets.
Sources et références
- Tranco, liste Q2K34, le classement des principaux sites orienté recherche utilisé pour l’échantillon.
- Barbaresi, A. (2021). Trafilatura: A Web Scraping Library and Command-Line Tool for Text Discovery and Extraction. ACL 2021 System Demonstrations.
- Pages mesurées par Shifter le 8 octobre 2026 à l’aide du code ci-dessus et de Chromium headless.