Wie man den Parser-Traffic ohne Datenverlust um das Fünffache reduziert: 7 Techniken für Data Engineers

Jedes zusätzliche Megabyte Parser-Traffic bedeutet entweder Kosten für den Proxy-Anbieter oder das Risiko, unter Limits zu fallen und eine IP-Sperre zu erhalten. Wenn Sie Preise von Wildberries, Ozon sammeln oder Anzeigen auf Avito über Hunderte von Proxy-Adressen überwachen, hat die Einsparung von Traffic direkte Auswirkungen auf das Budget des Projekts. In diesem Artikel finden Sie spezifische technische Methoden, die es ermöglichen, das Volumen der übertragenen Daten um das 4- bis 5-Fache zu reduzieren, während die Vollständigkeit und Genauigkeit der extrahierten Informationen erhalten bleibt.

Warum Parser-Traffic das Budget belastet

Die meisten Proxy-Anbieter berechnen residentielle und mobile Proxys nach dem Volumen der übertragenen Gigabytes und nicht nach der Nutzungsdauer. Wenn Ihr Parser die Produktseite von Wildberries vollständig lädt — mit Bildern, Empfehlungsskripten, Analyse-Trackern und Schriftarten — zahlen Sie für 2-3 MB pro Produktkarte, obwohl Sie tatsächlich nur 15-20 KB Text benötigen: Titel, Preis, Bewertung, Verfügbarkeit.

Bei einer Skalierung auf 50.000-100.000 Karten pro Tag verwandelt sich der Unterschied zwischen „alles laden“ und „nur das Notwendige laden“ in Dutzende von Gigabytes überflüssigen Traffics täglich. Dies sind nicht nur Kosten für Proxys, sondern auch eine erhöhte Belastung der Zielwebsite, was die Wahrscheinlichkeit erhöht, unter die Anti-Bot-Schutzmaßnahmen zu fallen und eine CAPTCHA oder eine vorübergehende IP-Sperre zu erhalten. Die Optimierung des Traffics bedeutet gleichzeitig eine Kostenersparnis und ein geringeres Risiko von Sperrungen.

Es gibt auch einen dritten Effekt: Je weniger Daten bei einer Anfrage übertragen werden, desto schneller wird die Anfrage selbst ausgeführt. Dies ermöglicht eine Erhöhung des Parallelismus — mehr Threads mit der gleichen Anzahl von Proxys zu starten, ohne die Geschwindigkeitslimits zu überschreiten, die Anti-Detection-Browser wie Dolphin Anty oder AdsPower bei der Arbeit mit Sitzungen festlegen.

Methode 1: Blockierung von Bildern, CSS und Schriftarten

Wenn der Parser über einen Headless-Browser (Playwright, Puppeteer, Selenium) arbeitet, ist der schnellste Weg, den Traffic um 2-3 Mal zu reduzieren, die Blockierung des Ladens statischer Ressourcen, die keinen Einfluss auf die Daten im DOM haben. Produktbilder, Schriftarten der Website, Videos und CSS-Stile machen bis zu 70% des Seitengewichts aus, nehmen jedoch nicht an der Extraktion von Text und Attributen teil.

from playwright.sync_api import sync_playwright

def block_heavy_resources(route, request):
    if request.resource_type in ["image", "media", "font", "stylesheet"]:
        route.abort()
    else:
        route.continue_()

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.route("**/*", block_heavy_resources)
    page.goto("https://example.com/product/123")
    html = page.content()
    browser.close()

Eine ähnliche Logik wird in Puppeteer über page.setRequestInterception(true) und in Selenium über die Konfiguration des Chrome-Profils mit dem Parameter profile.managed_default_content_settings.images: 2 implementiert. In der Praxis reduziert diese eine Einstellung sofort 50% bis 70% des Traffics beim Parsen von Marktplätzen, wo die Seiten mit visuellem Inhalt und Werbebannern überladen sind.

Methode 2: HTTP-Anfragen anstelle eines vollständigen Browsers

Viele verwenden Selenium oder Playwright dort, wo es nicht notwendig ist. Wenn die Seite keine Ausführung von JavaScript zur Darstellung der Daten erfordert (das lässt sich leicht überprüfen, indem Sie „Seitenquelltext anzeigen“ anstelle von DevTools öffnen), ist es viel vorteilhafter, das HTML direkt über die Bibliotheken requests oder httpx in Python abzurufen. Eine solche Anfrage wiegt Kilobyte und nicht Megabyte, da sie nicht das Rendering-Engine des Browsers, Netzwerkaufrufe für Tracker und sekundäre Ressourcen mit sich zieht.

import httpx

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
    "Accept-Encoding": "gzip, br",
    "Accept": "text/html,application/xhtml+xml"
}

proxies = {"http://": "http://user:pass@proxy_host:port",
           "https://": "http://user:pass@proxy_host:port"}

with httpx.Client(headers=headers, proxies=proxies, http2=True) as client:
    response = client.get("https://example.com/catalog/item/456")
    print(len(response.content), "Bytes erhalten")

Der Wechsel von Browseremulation zu direkten HTTP-Anfragen, wo die Website fertiges HTML ohne clientseitiges Rendering bereitstellt, reduziert den Traffic um das 3- bis 8-Fache. Der einzige Nachteil ist, dass solche Anfragen leichter von echten Benutzern unterschieden werden können. Daher sollte man für Websites mit strengen Anti-Bot-Schutzmaßnahmen diese Methode mit qualitativ hochwertigen residential Proxys kombinieren, die IPs von echten Heim-Anbietern bereitstellen und die Wahrscheinlichkeit einer Anfrageblockierung verringern.

Methode 3: Parsing über versteckte JSON-APIs

Praktisch alle modernen Marktplätze — einschließlich Wildberries, Ozon und Yandex.Market — rendern Produktkarten und Listen über interne JSON-APIs, die vom Frontend aufgerufen werden. Diese Endpunkte können über den Reiter Netzwerk in DevTools gefunden werden, indem die Anfragen nach dem Typ XHR/Fetch gefiltert werden. In der Regel gibt eine solche Anfrage JSON von 5-30 KB mit reinen Daten zurück: Produkt-ID, Preis, Rabatt, Bestände, Bewertung — ohne einen einzigen Byte HTML-Markup oder CSS.

Der Unterschied im Volumen der übertragenen Daten zwischen einer vollständigen HTML-Seite und dem direkten Zugriff auf die JSON-API kann bis zu 10-15 Mal betragen. Ein zusätzlicher Vorteil — JSON ist einfacher programmatisch zu parsen: Es sind keine XPath-Selektoren erforderlich, es genügt, auf das benötigte Feld über den Schlüssel des Dictionaries zuzugreifen. Nachteil — solche Endpunkte erfordern oft spezifische Header, Sitzungstoken oder Anfrage-Signaturparameter, die zuvor von der Hauptseite oder der mobilen Anwendung extrahiert werden müssen.

Methode 4: Gzip- und Brotli-Kompression

Selbst wenn Sie gezwungen sind, das vollständige HTML abzurufen, kann die Aktivierung der richtigen Kompression die Übertragungsgröße um 60-80% reduzieren. Viele selbstgeschriebene Parser senden den Header Accept-Encoding: gzip, br nicht, weshalb der Server eine unkomprimierte Antwort zurückgibt. Die Bibliotheken requests und httpx entpacken Gzip und Brotli automatisch — es ist nur wichtig, die Unterstützung für Kompression in den Anfrage-Headern deutlich anzugeben.

Brotli komprimiert im Durchschnitt textuelles HTML stärker als Gzip um 15-20%, aber nicht alle Server unterstützen diesen Algorithmus — es ist ratsam, beide Varianten anzufordern und dem Server die Wahl des optimalen zu überlassen. Für JSON-APIs ist der Effekt der Kompression noch deutlicher: Wiederholte Schlüssel in Dictionaries („price“, „name“, „rating“) werden praktisch perfekt komprimiert, wodurch das Gewicht der Antwort erheblich reduziert wird.

Methode 5: Bedingte Anfragen und Caching

Wenn Sie die Preise für dieselben Produkte mehrmals am Tag überwachen, ändert sich der Großteil der Karten zwischen den Überprüfungen nicht. Verwenden Sie die Header If-Modified-Since und If-None-Match mit dem ETag-Wert, der bei der ersten Anfrage erhalten wurde. Wenn sich der Inhalt nicht geändert hat, gibt der Server den Status 304 Not Modified praktisch ohne Antwortkörper zurück — die Einsparung des Traffics kann bis zu 95% auf unveränderten Seiten betragen.

import httpx

etag_store = {}

def fetch_with_cache(url, client):
    headers = {}
    if url in etag_store:
        headers["If-None-Match"] = etag_store[url]
    resp = client.get(url, headers=headers)
    if resp.status_code == 304:
        return None  # Daten haben sich nicht geändert
    etag_store[url] = resp.headers.get("ETag", "")
    return resp.content

Nicht alle Websites unterstützen ETag korrekt, aber für diejenigen, die dies tun, wird diese Methode zur effektivsten Möglichkeit, den Traffic bei regelmäßiger Überwachung zu reduzieren — Sie zahlen faktisch nur für tatsächliche Änderungen der Daten und nicht für das erneute Laden unveränderter Inhalte.

Methode 6: Selektives Parsing der benötigten Felder

Manchmal ist es unmöglich, den eingehenden Traffic vom Server zu reduzieren — die Website gibt die gesamte Seite unabhängig von der Anfrage zurück. In diesem Fall erfolgt die Optimierung in der Verarbeitungsphase: Laden Sie die Seite nicht erneut nur, um ein weiteres Feld zu extrahieren. Entwerfen Sie XPath oder CSS-Selektoren so, dass Sie in einem Durchgang durch das DOM alle benötigten Attribute — Preis, Titel, Artikelnummer, Verfügbarkeit, Bewertung — extrahieren, anstatt wiederholte Anfragen an dieselbe URL mit verschiedenen Parsern für unterschiedliche Aufgaben zu stellen.

Es ist auch nützlich, die Tiefe des Crawlens von Unterseiten zu begrenzen. Wenn für die Preisüberwachung die Daten von der Kategorieseite (Produktliste) ausreichen, gehen Sie nicht auf die Seite jedes einzelnen Produkts — das ist doppelter Traffic, der oft keine neuen Informationen liefert, außer Beschreibungen und Bewertungen, die keinen Einfluss auf den Preis und die Verfügbarkeit haben.

Methode 7: Optimierung des Crawl-Musters

Die Duplikation von URLs ist eine grundlegende, aber oft ignorierte Methode. Marktplatzkataloge generieren viele Links mit identischem Inhalt, aber unterschiedlichen Sortierparametern, UTM-Tags oder Sitzungs-IDs. Die Normalisierung von URLs vor der Warteschlangenstellung (Entfernung von Tracking-Parametern, Sortierung von Query-Parametern) entfernt 10-30% überflüssige Anfragen beim Crawlen großer Kataloge.

Die Priorisierung des Crawlens nach der Häufigkeit der Datenänderung spart ebenfalls Traffic: Produkte mit hoher Nachfrage und volatilen Preisen sollten stündlich überprüft werden, während seltene Artikel einmal täglich überprüft werden sollten. Ein solcher adaptiver Zeitplan anstelle eines gleichmäßigen Crawlens aller Karten mit der gleichen Häufigkeit reduziert das Gesamtvolumen der Anfragen um das 2- bis 4-Fache, ohne die Aktualität kritischer Daten zu verlieren.

Wie es mit der Proxy-Strategie kombiniert werden kann

Die Reduzierung des Traffics hat direkte Auswirkungen auf die Wahl des Proxytyps. Wenn Sie eine große Anzahl von Seiten über direkte HTTP-Anfragen ohne komplexen Anti-Bot-Schutz crawlen, sind schnelle und kostengünstige Datacenter-Proxys ausreichend — sie bieten hohe Übertragungsgeschwindigkeiten zu niedrigen Kosten pro Gigabyte, was bei der großflächigen Erfassung von Tausenden von Karten pro Tag entscheidend ist.

Für Websites mit strengen Bot-Schutzmaßnahmen, bei denen es wichtig ist, das Verhalten eines echten Benutzers zu imitieren, ist es besser, residential Proxys zu verwenden — indem Sie diese mit Methoden zur Blockierung unnötiger Ressourcen kombinieren, erhalten Sie sowohl geringen Traffic als auch ein hohes Maß an Vertrauen der Website in die Anfrage. Und wenn das Parsing über mobile Versionen der Marktplatz-APIs erfolgt, wo die Daten kompakter sind und das Anti-Bot-System auf mobile IP-Bereiche ausgerichtet ist, sollten mobile Proxys in Betracht gezogen werden, um das Risiko von Sperrungen weiter zu verringern.

Die Kombination aus „minimalem Traffic pro Anfrage“ + „richtiger Proxytyp für die Aufgabe“ ermöglicht es, die Infrastrukturkosten zu senken und die Geschwindigkeit der Datensammlung zu erhöhen, ohne die Zuverlässigkeit zu beeinträchtigen.

Vergleichstabelle der Methoden

Methode	Traffic-Reduzierung	Implementierungskomplexität
Blockierung von Bildern/CSS/Schriftarten	50-70%	Niedrig
HTTP-Anfragen anstelle eines Browsers	3-8 Mal	Mittel
Versteckte JSON-APIs	10-15 Mal	Hoch
Gzip/Brotli-Kompression	60-80%	Niedrig
Bedingte Anfragen (ETag)	bis zu 95% auf unveränderten Seiten	Mittel
Duplikation von URLs und Priorisierung	2-4 Mal	Mittel

Implementierungs-Checkliste

• Überprüfen, ob die Zielseite JavaScript-Rendering erfordert oder ob HTML direkt über httpx/requests abgerufen werden kann
• Blockierung von image/media/font/stylesheet im Headless-Browser einrichten, falls der Browser dennoch benötigt wird
• Interne JSON-APIs über DevTools → Netzwerk → XHR/Fetch finden
• Header Accept-Encoding: gzip, br in alle Anfragen einfügen
• ETag/Last-Modified für bedingte Anfragen auf wiederholten URLs implementieren
• Warteschlange von URLs vor dem Crawlen normalisieren und deduplizieren
• Adaptive Crawlfrequenz basierend auf Wichtigkeit und Volatilität der Daten einrichten
• Proxytyp entsprechend dem endgültigen Traffic-Profil auswählen — Datacenter, residential oder mobile

Fazit

Die Reduzierung des Parser-Traffics um das Fünffache ist ein realistisches Ziel, wenn die Methoden schrittweise angewendet werden: unnötige Ressourcen entfernen, auf direkte HTTP-Anfragen oder JSON-APIs umsteigen, wo möglich, Kompression aktivieren, bedingte Anfragen für unveränderte Daten verwenden und das Crawl-Muster selbst optimieren. Jeder dieser Schritte hat einen messbaren Effekt, und zusammen verändern sie die Wirtschaftlichkeit des Projekts zur Datensammlung von Marktplätzen und anderen Websites grundlegend.

Nach der Optimierung des Traffics ist es wichtig, die Proxy-Infrastruktur entsprechend dem neuen Lastprofil richtig auszuwählen. Für eine schnelle und kostengünstige Erfassung großer Datenmengen sind Datacenter-Proxys geeignet, während für die Arbeit mit Websites mit strengen Anti-Bot-Schutzmaßnahmen residential Proxys mit echten IP-Adressen von Heim-Anbietern verwendet werden sollten, die das Risiko von Sperrungen selbst bei intensivem Parsing verringern.