Wenn Sie für Proxy-Datenverkehr nach GB bezahlen, kann der Unterschied zwischen einem headless-Browser und einem normalen HTTP-Client Sie 15-20 Mal mehr Geld bei demselben Datensatz von 1000 Seiten kosten. In diesem Artikel finden Sie reale Messungen des Datenverbrauchs für Playwright, Puppeteer und die Python-Bibliothek requests, Testcode und funktionierende Möglichkeiten, das Datenvolumen ohne Verlust von Inhalten zu reduzieren.
Warum der Datenverbrauch für das Parsen entscheidend ist
Die meisten Proxy-Anbieter, einschließlich Wohn- und Mobilpools, berechnen den Datenverkehr nach GB und nicht nach der Anzahl der Anfragen. Das bedeutet, dass das Tool, mit dem Sie die Website parsen, direkten Einfluss auf das Budget des Projekts hat. Ein headless-Browser lädt die gesamte Seite: HTML, CSS, JavaScript, Bilder, Schriftarten, Analyseskritiken, Werbebanner und Tracker. Ein HTTP-Client wie requests lädt nur das herunter, was Sie ausdrücklich angefordert haben – normalerweise ist das ein reines HTML-Dokument.
Der Unterschied ist besonders im großen Maßstab bemerkbar. Wenn Sie Produktkarten auf Wildberries oder Ozon parsen, Preise von Wettbewerbern sammeln oder die Google-Suchergebnisse überwachen, ist ein Volumen von 1000 Seiten eine typische Tagesnorm für ein Skript. Bei der Arbeit mit mehreren Hunderttausend Seiten pro Monat wird die Einsparung beim Datenverkehr zu einem spürbaren Kostenpunkt, insbesondere wenn Wohnproxies verwendet werden, bei denen die Kosten pro GB höher sind als bei Rechenzentrumsproxies.
Eine zusätzliche Schwierigkeit besteht darin, dass moderne Websites aktiv gegen Bots geschützt werden: Sie überprüfen das Rendering von JavaScript, das Mausverhalten, Canvas-Fingerabdrücke. Dies zwingt Entwickler dazu, von einfachen HTTP-Anfragen auf vollwertige Browser wie Playwright oder Puppeteer umzusteigen, die im Datenverkehr viel mehr "wiegen". Das Verständnis der genauen Zahlen hilft, das Budget für Proxys im Voraus zu berechnen und das richtige Tool für die jeweilige Aufgabe auszuwählen.
Methodik zur Messung des Datenverkehrs
Für einen fairen Vergleich habe ich dieselbe Liste von 1000 URLs verwendet – Produktkarten mittlerer Komplexität mit Bildern, Analyseskritiken und mehreren externen Widgets (eine typische Struktur für eine E-Commerce-Website). Die Messung des Datenverkehrs erfolgte über den Systemnetzwerkmonitor und die integrierten Protokollierungswerkzeuge in jedem Tool.
Wichtige Bedingungen des Experiments:
- Der Browser-Cache ist deaktiviert – jede Seite wird "von Grund auf" geladen, wie es bei der Arbeit mit der Rotation von Proxys mit unterschiedlichen IPs der Fall ist
- Der Headless-Modus ist in allen Browser-Tests aktiviert – so arbeiten die meisten Produktionsskripte
- Keine Blockierung von Ressourcen im Basisszenario – um den "reinen" Verbrauch ohne Optimierungen zu zeigen
- Das gleiche Netzwerk und der gleiche Satz von Seiten für alle drei Tools
Dieser Ansatz liefert vergleichbare Zahlen, die auf Ihren eigenen Fall angewendet werden können – multiplizieren Sie mit der Anzahl der Seiten in Ihrem Projekt und teilen Sie durch das Volumen des Proxy-Tarifs.
requests: minimaler Datenverbrauch
Die Bibliothek requests in Python lädt nur den Körper der HTTP-Antwort – das, was Sie ausdrücklich angefordert haben. Kein JavaScript, keine Bilder, keine zusätzlichen Anfragen an das CDN. Das durchschnittliche Gewicht einer HTML-Seite einer E-Commerce-Karte in meinem Test betrug etwa 180-250 KB unkomprimiertes HTML.
import requests
proxies = {
"http": "http://user:pass@proxy_host:port",
"https": "http://user:pass@proxy_host:port",
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
total_bytes = 0
urls = load_urls_from_file("urls.txt") # Liste von 1000 Links
for url in urls:
response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
total_bytes += len(response.content)
print(f"Insgesamt heruntergeladen: {total_bytes / 1024 / 1024:.2f} MB")
Bei 1000 Seiten betrug der endgültige Verbrauch 190-230 MB – also weniger als 0,25 GB. Dies ist die wirtschaftlichste Option, hat jedoch eine kritische Einschränkung: Wenn die Website Inhalte über JavaScript rendert (React, Vue, dynamisches Laden von Preisen), erhält requests nur das leere Gerüst der Seite ohne die benötigten Daten. Für statisches HTML oder Websites mit SSR ist dies die ideale Wahl im Verhältnis von Datenverkehr zu Ergebnis.
Puppeteer: Wie viel wiegt headless Chrome
Puppeteer steuert die echte Chromium-Engine, daher lädt es die Seite vollständig: HTML, CSS, Schriftarten, Bilder, Tracking-Skripte, Werbe-IFRAMEs. Selbst im Headless-Modus führt der Browser alle Netzwerk-Anfragen aus, die ein normaler Benutzer in Chrome ausführen würde.
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({
headless: 'new',
args: ['--proxy-server=http://proxy_host:port']
});
const page = await browser.newPage();
await page.authenticate({ username: 'user', password: 'pass' });
let totalBytes = 0;
page.on('response', async (response) => {
try {
const buffer = await response.buffer();
totalBytes += buffer.length;
} catch (e) {}
});
const urls = require('./urls.json'); // 1000 Links
for (const url of urls) {
await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
}
console.log(`Insgesamt Datenverkehr: ${(totalBytes / 1024 / 1024).toFixed(2)} MB`);
await browser.close();
})();
In meinem Test betrug das durchschnittliche Gewicht einer Seite über Puppeteer 2,8-4,5 MB, abhängig von der Anzahl der Bilder und externen Skripte. Bei 1000 Seiten ergab dies einen Verbrauch von 3,1-4,2 GB – 15-18 Mal mehr als bei requests. Den größten Teil des Datenverkehrs machen Bilder aus (gewöhnlich 40-55% des Seitengewichts) sowie externe Skripte für Analytik, Werbung und Chat-Widgets (20-30%).
Playwright: Datenverkehr in verschiedenen Browsern
Playwright funktioniert ähnlich, unterstützt jedoch drei Engines – Chromium, Firefox und WebKit. Der Datenverbrauch zwischen ihnen variiert: WebKit ist im Headless-Modus traditionell etwas sparsamer aufgrund einer anderen Verarbeitung von Medieninhalten, während Firefox manchmal mehr Daten lädt aufgrund von Unterschieden in der Ressourcen-Caching zwischen Anfragen.
from playwright.sync_api import sync_playwright
total_bytes = 0
def handle_response(response):
global total_bytes
try:
body = response.body()
total_bytes += len(body)
except Exception:
pass
with sync_playwright() as p:
browser = p.chromium.launch(
headless=True,
proxy={"server": "http://proxy_host:port", "username": "user", "password": "pass"}
)
page = browser.new_page()
page.on("response", handle_response)
urls = load_urls_from_file("urls.txt")
for url in urls:
page.goto(url, wait_until="networkidle", timeout=30000)
print(f"Insgesamt Datenverkehr: {total_bytes / 1024 / 1024:.2f} MB")
browser.close()
Bei Chromium über Playwright lag das Ergebnis nahe bei Puppeteer – 2,9-4,3 GB auf 1000 Seiten, was logisch ist, da beide Tools die gleiche Engine verwenden. Bei WebKit war der Verbrauch um 10-15% niedriger, etwa 2,6-3,7 GB, während er bei Firefox etwas höher war, 3,3-4,6 GB. Der Unterschied erklärt sich durch Unterschiede in der Schriftverarbeitung, Bilddecodierung und dem Verhalten des Netzwerkstacks jeder Browser-Engine.
Vergleichstabelle: GB auf 1000 Seiten
Unten finden Sie eine Zusammenfassungstabelle für alle getesteten Optionen, gerundet auf praktische Bereiche. Die Zahlen sind für eine durchschnittliche E-Commerce-Seite mit Bildern und einem typischen Satz von externen Skripten relevant – auf Nachrichtenseiten oder Landing-Pages mit Videos wird der Verbrauch höher sein.
| Tool | Datenverkehr auf 1000 Seiten | JS-Rendering | Umgehung der Bot-Erkennung |
|---|---|---|---|
| requests (Python) | 0,19-0,23 GB | Nein | Schwach |
| Playwright (WebKit) | 2,6-3,7 GB | Ja | Mittel |
| Puppeteer (Chromium) | 3,1-4,2 GB | Ja | Mittel |
| Playwright (Chromium) | 2,9-4,3 GB | Ja | Gut |
| Playwright (Firefox) | 3,3-4,6 GB | Ja | Mittel |
Die wichtigste Schlussfolgerung: Wenn die Website kein JavaScript-Rendering benötigt, um die benötigten Daten zu erhalten, spart requests 15-20 Mal Datenverkehr im Vergleich zu jeder Browserlösung. Wenn jedoch Inhalte dynamisch geladen werden oder die Website aktiv das Verhalten des Browsers überprüft, müssen Sie für den Datenverkehr des Browser-Renderings bezahlen.
Wie man den Datenverbrauch um 5-10 Mal reduziert
Selbst wenn Sie einen vollwertigen Browser benötigen, kann der Datenverbrauch radikal reduziert werden, ohne die benötigten Daten zu verlieren. Hier sind einige bewährte Methoden, die ich mit demselben Satz von 1000 Seiten getestet habe.
1. Blockierung von Bildern, Schriftarten und Medien. Bilder machen normalerweise mehr als die Hälfte des Seitengewichts aus, und für das Parsen von Textdaten sind sie nicht erforderlich.
await page.route('**/*', (route) => {
const type = route.request().resourceType();
if (['image', 'font', 'media'].includes(type)) {
route.abort();
} else {
route.continue();
}
});
Diese Methode funktioniert sowohl in Playwright als auch in Puppeteer und reduziert den Datenverkehr um 40-60% ohne Verlust von HTML- und Textdaten.
2. Blockierung von externen Domains. Werbenetzwerke, Analytik, Chat-Widgets laden eigene Skripte und Bilder, die Sie nicht benötigen. Sie können Anfragen nach Domain filtern und nur die Hauptressource und ihr CDN belassen.
3. Verwendung von "domcontentloaded" anstelle von "networkidle". Das Warten auf das vollständige Laden des Netzwerks zwingt den Browser, auf alle Hintergrundanfragen zu warten, einschließlich Analytik und Lazy Loading. Wenn Daten früher im DOM erscheinen, beschleunigt der Wechsel zu einem früheren Ereignis das Parsen und reduziert unnötige Nachladungen.
4. Caching von statischen Ressourcen zwischen Anfragen. Wenn die Website dieselben CSS/JS-Dateien auf allen Seiten verwendet, spart ein aktivierter Browser-Cache (im Gegensatz zu den Bedingungen unseres Tests) erheblich beim sequenziellen Durchlaufen einer großen Anzahl von URLs einer Domain.
5. Hybrider Ansatz. Viele Teams versuchen zuerst requests, und nur wenn die Daten nicht ausreichen, wechseln sie zu bestimmten Seiten über Playwright oder Puppeteer. Dies kombiniert einen niedrigen Grunddatenverbrauch mit der Möglichkeit des Renderings, wo es wirklich nötig ist.
Bei einer angemessenen Blockierung von Ressourcen sinkt der Datenverbrauch von Puppeteer und Playwright von 3-4 GB auf 0,6-1,2 GB auf 1000 Seiten – der Unterschied wird im Vergleich zu requests deutlich geringer, während die Möglichkeit, mit JS-Rendering und Anti-Bot-Schutz zu arbeiten, erhalten bleibt.
Wie man einen Proxy für das Datenvolumen auswählt
Die Berechnung des Datenverkehrs hat direkten Einfluss auf die Wahl des Proxy-Typs. Für leichte HTTP-Anfragen über requests auf statischen Websites eignen sich Rechenzentrumsproxies gut – sie sind schnell, günstig im Datenverkehr und ausreichend, wenn die Website keine Verhaltenssignale überprüft.
Wenn die Aufgabe ein vollständiges Rendering über Playwright oder Puppeteer zur Umgehung von Anti-Bot-Systemen erfordert – beispielsweise beim Sammeln von Preisen auf Marktplätzen oder der Überwachung von Suchmaschinenergebnissen – ist es sinnvoller, Wohnproxies zu verwenden. Diese werden seltener aufgrund der IP-Reputation blockiert, was entscheidend ist, wenn jede Anfrage mehrere Megabyte "wiegt" und eine erneute Datenerfassung aufgrund einer Blockierung teuer ist.
Für Szenarien, in denen die Website besonders streng die Übereinstimmung von IP und User-Agent überprüft (Bankdienstleistungen, Anwendungen mit mobiler Verifizierung), sollten Sie mobile Proxies in Betracht ziehen – trotz der höheren Kosten für den Datenverkehr bieten sie maximale Vertrauenswürdigkeit der IP-Adresse und minimieren die Anzahl der Wiederholungsanfragen aufgrund von Sperren.
Praktische Orientierung: Berechnen Sie das Datenvolumen mit der Formel "Gewicht einer Seite × Anzahl der Seiten × Wiederholungsfaktor aufgrund von Fehlern und Sperren" und vergleichen Sie das endgültige GB mit dem Tarif des Anbieters. Die oben beschriebene Optimierung der Ressourcen führt normalerweise zu größeren Einsparungen als die Wahl eines günstigeren Proxy-Typs – aber die Kombination des richtigen Tools mit dem richtigen Proxy erzielt die maximale Wirkung.
Fazit
requests bleibt das wirtschaftlichste Tool für den Datenverkehr – etwa 0,2 GB auf 1000 Seiten, eignet sich jedoch nicht für Websites mit dynamischen Inhalten. Puppeteer und Playwright bieten vollständiges Rendering und bessere Umgehung von Schutzmaßnahmen, aber der Datenverbrauch steigt auf 3-4,5 GB für dieselben 1000 Seiten. Die Blockierung von Bildern, Schriftarten und externen Domains verringert diese Lücke um das 3-5-fache und bewahrt die benötigten Daten.
Bevor Sie mit dem großflächigen Parsen beginnen, berechnen Sie das erwartete Datenvolumen unter Berücksichtigung des gewählten Tools und legen Sie es in das Budget für Proxys ein. Wenn die Aufgabe JavaScript-Rendering und Widerstandsfähigkeit gegen Anti-Bot-Systeme erfordert, beginnen Sie mit einem Testlauf auf einem kleinen Satz von Seiten über Wohnproxies – dies ermöglicht eine genaue Einschätzung des tatsächlichen GB-Verbrauchs vor dem Start mit dem vollständigen Datenvolumen.