Wenn Sie Proxy-Traffic nach Gigabyte bezahlen, kostet jedes Byte einer Seite gleich viel: der Absatz, wegen dem Sie gekommen sind, das Menü drumherum, das Analytics-Skript, das Hero-Bild und die Schriftdatei. Die meisten Teams wissen, dass Seiten schwer sind. Nur wenige wissen, wie viel von dem, was sie herunterladen, tatsächlich die Daten sind, die sie behalten.
Wir haben es gemessen. Am 8. Oktober 2026 haben wir die Startseiten der Top-1.000-Domains im Tranco-Ranking abgerufen, von jeder einen Link im Artikelstil verfolgt und gemessen, wohin die Bytes gehen: auf der Leitung, im HTML und in allem, was ein Browser herunterlädt. Diese Studie teilt die Ergebnisse, den von uns verwendeten Code und was sie für Scraping-Budgets bedeuten.
Wichtigste Erkenntnisse
- Der Hauptinhalt einer typischen Seite macht etwa 1% ihres HTML aus. Auf der Content-Seite im Median befanden sich 3.2 KB Haupttext innerhalb von 260 KiB HTML.
- Komprimierung erledigt den größten Teil der Einsparung kostenlos. Dasselbe HTML kam auf der Leitung als 46 KiB an, etwa 5.4-mal kleiner, sodass der Haupttext etwa 6% der tatsächlich übertragenen Bytes ausmachte.
- Inline-Skripte sind der größte einzelne Anteil am HTML. Über alle Content-Seiten hinweg machte Inline-JavaScript 38% der HTML-Bytes aus, Inline-CSS 15% und Inline-SVG 10%. Der Haupttext betrug 1.3%.
- Ein Browser vervielfacht die Rechnung. Die Content-Seite im Median lud 2.6 MB bei 81 Requests in einem Headless-Browser. Das HTML-Dokument selbst machte davon etwa 3% aus.
- Das Blockieren von Bildern, Medien und Schriftarten halbiert den Browser-Traffic. Über alle Seiten hinweg entfielen dadurch 48% der Bytes; bei der Seite im Median betrug ein schlanker Ladevorgang 71% eines vollständigen.
Wie wir gemessen haben
- Stichprobe. Die Top-1.000-Domains der Tranco-Liste (Liste Q2K34). Viele davon sind API-, CDN- und Tracking-Hosts ohne eigene Website, sodass 431 unterschiedliche Websites eine verwendbare Startseite lieferten. Von jeder Startseite folgten wir dem ersten Link auf derselben Domain, der wie eine Content-Seite aussah (ein Pfad, der mit einem Slug aus vier oder mehr Wörtern endet, ausgenommen Login-, rechtliche und Hilfeseiten), was 278 verwendbare Content-Seiten ergab.
- HTML-Ebene. Ein Request pro Seite mit einem regulären Desktop-Browser-User-Agent und aktivierter Komprimierung. Wir erfassten die empfangenen Bytes, dekomprimierten sie und teilten das HTML in Inline-Skripte, Inline-Styles (einschließlich
style-Attribute), Inline-SVG und JSON-LD auf. Wir extrahierten den Hauptinhalt mit trafilatura, einer Open-Source-Extraktionsbibliothek, und zählten dessen Bytes als normalisierten Text. - Browser-Ebene. Wir luden jede Content-Seite in einem Headless-Chromium, warteten auf das Load-Event plus drei Sekunden und summierten die übertragenen Bytes jeder Antwort nach Ressourcentyp. Anschließend luden wir sie erneut, wobei Bilder, Medien und Schriftarten blockiert wurden.
- Ausschlüsse. Fehlerantworten, Nicht-HTML-Antworten und Blockseiten (Challenge-Seiten, „Zugriff verweigert”-Seiten und nahezu leere Antworten) wurden vor der Analyse ausgeschlossen, sodass die Ergebnisse Seiten beschreiben, die tatsächlich Inhalte ausgeliefert haben.
Die HTML-Ebene
| Messgröße (Median pro Seite) | Content-Seiten | Startseiten |
|---|---|---|
| Gemessene Seiten | 278 | 431 |
| Bytes auf der Leitung | 46 KiB | 51 KiB |
| HTML nach Dekomprimierung | 260 KiB | 270 KiB |
| Haupttext | 3.2 KB | 1.4 KB |
| Hauptinhalt als Anteil am HTML | 1.2% | 0.6% |
| Hauptinhalt als Anteil der übertragenen Bytes | 6.2% | 3.1% |
| Gesamter sichtbarer Text als Anteil am HTML | 3.6% | 2.4% |
Content-Seiten enthalten erwartungsgemäß mehr Text als Startseiten, aber das Gesamtbild ist dasselbe: Der Text, den ein Scraper behält, ist nur ein Bruchteil des Dokuments, das er herunterlädt. Selbst wenn man jedes sichtbare Wort auf der Seite zählt, einschließlich Menüs, Footer und Cookie-Hinweise, lag der Text bei unter 4% des HTML.
Wohin geht der Rest? Über alle 278 Content-Seiten hinweg:
| Teil des HTML | Anteil an den HTML-Bytes |
|---|---|
| Inline-JavaScript | 37.5% |
| Inline-CSS und Style-Attribute | 15.4% |
| Inline-SVG | 9.8% |
| JSON-LD-Strukturdaten | 0.9% |
| Haupttext | 1.3% |
| Markup, Attribute und alles Übrige | 35.1% |
Inline-JavaScript ist der größte einzelne Block: Framework-Status, Konfiguration und Tracking-Code, die direkt in die Seite eingebettet sind. Moderne Websites liefern ihre gesamten Seitendaten oft als JSON-Blob in einem Script-Tag aus und rendern sie clientseitig, weshalb Skripte den Text, den sie letztlich anzeigen, an Umfang übertreffen.
Das ist auch eine Chance. Das JSON-LD auf diesen Seiten machte im Durchschnitt unter 1% des HTML aus, und wo eine Seite ihre Daten als JSON einbettet, lässt sich dieser Blob meist deutlich sauberer parsen als das gerenderte Markup. Unsere Anleitungen zum Extrahieren von JSON-LD statt HTML-Parsing und zum Finden der API hinter der Seite behandeln beides.
Komprimierung ist auf dieser Ebene wichtiger als alles andere. Die Seite im Median schrumpfte beim Transport um das 5.4-Fache. Nur 10 der 278 Content-Seiten wurden unkomprimiert ausgeliefert, aber ein Scraper, der keine Komprimierung anfordert, erhält jedes Mal die vollen 260 KiB. Wenn Ihr HTTP-Client Accept-Encoding: gzip, deflate, br sendet, zahlen Sie bereits für 46 KiB, nicht für 260.
Die Browser-Ebene
Das Rendern einer Seite in einem Browser lädt alles herunter, was die Seite anfordert, nicht nur das Dokument.
| Messgröße (pro Content-Seite) | Wert |
|---|---|
| Im Browser gemessene Seiten | 274 |
| Übertragene Bytes im Median, vollständiges Laden | 2.6 MB |
| Mittlere Hälfte der Seiten | 1.2 to 4.3 MB |
| Requests im Median, vollständiges Laden | 81 |
| HTML-Dokument als Anteil am vollständigen Laden (Median) | 3% |
| Haupttext als Anteil am vollständigen Laden (Median) | 0.13% |
Nach Ressourcentyp, über alle vollständigen Ladevorgänge hinweg:
| Ressourcentyp | Anteil an den Bytes |
|---|---|
| Bilder | 38.1% |
| Skripte | 35.9% |
| Medien (Video und Audio) | 7.4% |
| Schriftarten | 6.6% |
| Stylesheets | 2.8% |
| HTML-Dokumente | 2.4% |
| API-Aufrufe (fetch und XHR) | 4.9% |
| Sonstiges | 1.9% |
Das Blockieren von Bildern, Medien und Schriftarten, die ein Scraper fast nie benötigt, reduzierte die Seite im Median auf 1.5 MB und 55 Requests. Über alle Seiten hinweg übertrug der blockierte Ladevorgang 52% der Bytes des vollständigen. Skripte lassen sich schwerer sicher blockieren, weil die Seite sie oft braucht, um den Inhalt zu rendern, wegen dem Sie gekommen sind.
Was das für ein Scraping-Budget bedeutet
Nehmen wir einen Job, der eine Million Content-Seiten pro Monat sammelt und nur deren Haupttext behält. Mit den obigen Medianwerten:
| Wie die Seiten abgerufen werden | Traffic pro Million Seiten |
|---|---|
| Nur der Haupttext, wenn man nur diesen abrufen könnte | about 3.2 GB |
| Nur HTML, komprimiert | about 47 GB |
| Nur HTML, unkomprimiert | about 265 GB |
| Browser, Bilder, Medien und Schriftarten blockiert | about 1.5 TB |
| Browser, vollständiges Laden | about 2.6 TB |
Die Lücke zwischen der ersten und der letzten Zeile beträgt etwa das 800-Fache. Daraus ergibt sich die praktische Reihenfolge der Einsparungen:
- HTML ohne Browser abrufen, wann immer die Daten im HTML stecken. Das allein macht den Unterschied zwischen Gigabyte und Terabyte aus.
- Immer Komprimierung anfordern. Das reduziert den HTML-Traffic ohne Kosten um etwa das Fünffache.
- Wenn gerendert werden muss, Bilder, Medien und Schriftarten blockieren. Das halbiert den Browser-Traffic ungefähr.
- Nach einer kleineren Quelle derselben Daten suchen: JSON-LD, einem eingebetteten JSON-Blob oder der API, die die Seite selbst aufruft.
Unsere Anleitung zum Senken der Proxy-Bandbreitenkosten behandelt jede dieser Techniken in der Praxis, und Schätzen Ihrer monatlichen Bandbreite zeigt, wie man Seitengewichte in einen Plan umsetzt.
Messen Sie Ihre eigenen Seiten
Medianwerte über die Top-Websites sind ein Ausgangspunkt; entscheidend sind Ihre eigenen Ziele. Die folgende Funktion ruft eine Seite ab und berichtet, wohin ihre Bytes gehen, nach derselben Methode wie die Studie:
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()),
}Sie liest den Response-Body vor der Dekomprimierung, sodass wire_bytes das ist, was tatsächlich übertragen wurde, und dekodiert ihn dann manuell. Führen Sie sie auf einigen Seiten jedes Ihrer Ziele aus:
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 ist nach diesen Maßstäben eine effiziente Seite: Ihr Haupttext macht über 11% des HTML aus, fast das Zehnfache des von uns gemessenen Medians. Ihre Ziele werden irgendwo in diesem Bereich liegen, und zu wissen, wo, sagt Ihnen, ob reine HTML-Erfassung, Komprimierung oder eine andere Datenquelle am meisten einspart.
Grenzen der Messung
- Nur Top-Websites. Die Top-1.000-Domains sind große, gut konstruierte Websites. Kleinere Websites können leichter oder viel schwerer sein.
- Eine Content-Seite pro Website. Wir folgten dem ersten Link im Artikelstil auf jeder Startseite. Produktseiten, Suchergebnisse und Listing-Seiten können abweichen.
- Der Hauptinhalt ist eine Schätzung. Extraktionsbibliotheken können Inhalte übersehen oder zu viel einbeziehen, insbesondere bei Seiten, die größtenteils aus Navigation bestehen. Betrachten Sie die Haupttext-Zahlen als ungefähr; die Byte-Messungen sind exakt.
- Eine Momentaufnahme, ein Netzwerk. Die Seiten wurden einmalig, am 8. Oktober 2026, von einem einzelnen Netzwerk in Europa abgerufen. Websites liefern je nach Standort und im Zeitverlauf unterschiedliche Seiten, Werbung und Medien aus.
- Browser-Ladevorgänge waren begrenzt. Wir stoppten die Messung drei Sekunden nach dem Load-Event. Seiten, die danach weiterhin Inhalte laden, würden mehr übertragen, als wir erfasst haben.
FAQ
Welcher Anteil einer Webseite ist der eigentliche Inhalt?
Auf der Content-Seite im Median unter den Top-1.000-Websites machte der Haupttext etwa 1.2% des HTML und etwa 6% der übertragenen komprimierten Bytes aus. Bei einem vollständigen Browser-Ladevorgang waren es etwa 0.13% der Bytes.
Reduziert das Blockieren von Bildern den Proxy-Bandbreitenverbrauch?
Ja. Das Blockieren von Bildern, Medien und Schriftarten in einem Headless-Browser entfernte 48% der Bytes in unserer Stichprobe. Bilder allein machten 38% des Browser-Traffics aus.
Ist es günstiger, ohne Browser zu scrapen?
Meist mit großem Abstand. Die Content-Seite im Median war 46 KiB als komprimiertes HTML und 2.6 MB bei vollständigem Browser-Laden, ein Unterschied von mehr als dem 50-Fachen.
Sollte ich beim Scraping komprimierte Antworten anfordern?
Ja. Die Seite im Median war komprimiert 5.4-mal kleiner. Die meisten HTTP-Clients fordern standardmäßig Komprimierung an, aber prüfen Sie das, denn ein Client, der es nicht tut, zahlt für die volle Größe jeder Seite.
Fazit
Die Daten, die ein Scraper behält, sind nur ein winziger Anteil dessen, was er herunterlädt: etwa 1% des HTML einer typischen Seite und ein Bruchteil eines Prozents dessen, was ein Browser lädt. Der größte Teil dieses Overheads ist vermeidbar. Rufen Sie HTML ab, statt zu rendern, wo immer es möglich ist, lassen Sie die Komprimierung aktiviert, blockieren Sie schwere Ressourcen, wenn Sie rendern müssen, und suchen Sie nach Strukturdaten oder APIs, die dieselben Informationen in deutlich weniger Bytes liefern.
Quellen und Referenzen
- Tranco, Liste Q2K34, das forschungsorientierte Ranking der Top-Websites, das für die Stichprobe verwendet wurde.
- Barbaresi, A. (2021). Trafilatura: A Web Scraping Library and Command-Line Tool for Text Discovery and Extraction. ACL 2021 System Demonstrations.
- Seiten gemessen von Shifter am 8. Oktober 2026 mit dem obigen Code und Headless-Chromium.