Proxy-Bandbreitenkosten beim Scrapen im großen Maßstab senken

Residential Proxies werden pro Gigabyte abgerechnet, also ist Ihre Bandbreite auf einem Pro-GB-Tarif Ihre Rechnung. Der Haken: Ein naiver Scraper verschwendet die meisten Bytes, für die er zahlt, lädt Bilder, Schriften, Videos und Tracking-Skripte herunter, die er nie ansieht, holt Seiten erneut, die sich nicht geändert haben, und rendert vollständige Browser, wo eine schlichte HTTP-Anfrage genügt hätte. Die gute Nachricht: Fast diese ganze Verschwendung lässt sich leicht senken, und ein gut abgestimmter Scraper nutzt routinemäßig weniger als die Hälfte der Bandbreite eines nicht abgestimmten für dieselben Daten.

Dies ist eine praktische Anleitung, genau das zu tun. Neun Taktiken, grob nach Wirkung geordnet, um dieselben Daten über Ihre Residential Proxies zu erfassen, während Sie für einen Bruchteil der Bytes zahlen. Es ist der Kosteneffizienz-Begleiter zur Pro-GB-Verschiebung, die in nach Bandbreite abgerechnete Residential Proxies behandelt wird.

1. Rendern Sie keinen Browser, wenn Sie nicht müssen

Das ist der größte einzelne Hebel. Ein Headless-Browser lädt alles herunter, worauf die Seite verweist: Bilder, CSS, Web-Schriften, Video, Analytics, Anzeigenskripte. Für das meiste Scraping brauchen Sie davon nichts. Wenn die gewünschten Daten im initialen HTML stehen oder über eine API erreichbar sind (nächster Abschnitt), überspringen Sie den Browser ganz und nutzen einen schlichten HTTP-Client, requests, httpx oder Scrapy. Ein einzelnes HTTP-GET kann ein winziger Bruchteil der Bytes sein, die ein vollständiger Browser-Render zieht.

Reservieren Sie den Browser für Seiten, die JavaScript-Ausführung wirklich brauchen, um die Daten zu erzeugen. Im Zweifel holen Sie zuerst das rohe HTML und prüfen, ob Ihre Zielwerte bereits darin stehen.

2. Treffen Sie die JSON-API, nicht das HTML

Viele Seiten rendern ihren Inhalt aus einem Backend-JSON-Endpunkt, den die Seite nach dem Laden aufruft. Diesen Endpunkt direkt zu holen, statt der vollständigen HTML-Seite und ihrer Assets, ist oft ein Bruchteil der Bytes und gibt Ihnen saubere, strukturierte Daten ohne Parsing. Öffnen Sie den Netzwerk-Tab Ihres Browsers, finden Sie die Anfrage, die die Daten zurückgibt (meist ein XHR/fetch, das JSON liefert), und rufen Sie sie direkt über den Proxy auf. Eine schlanke JSON-Antwort kann eine schwere Seite plus einen Browser-Render ersetzen.

3. Blockieren Sie schwere Ressourcentypen, wenn Sie einen Browser nutzen müssen

Wenn eine Seite wirklich Rendering braucht, lassen Sie den Browser nicht herunterladen, was Sie nicht nutzen. Sowohl Playwright als auch Puppeteer lassen Sie Anfragen abfangen und Bilder, Media, Schriften und oft Stylesheets abbrechen, bevor sie den Proxy erreichen, was die Bandbreite typischerweise um weit mehr als die Hälfte senkt. In Playwright:

await context.route("**/*", (route) => {
  const type = route.request().resourceType();
  if (["image", "media", "font"].includes(type)) {
    return route.abort();          // nie heruntergeladen, nie abgerechnet
  }
  return route.continue();
});

Behalten Sie document, script, xhr und fetch; verwerfen Sie den Rest. Dasselbe Muster und die Chromium-Besonderheiten stehen in Residential Proxies mit Playwright verwenden.

4. Lassen Sie die Komprimierung an

Text komprimiert etwa 5- bis 10-fach, also ist eine gzip- oder brotli-kodierte HTML-Antwort ein Bruchteil der Rohgröße. Die meisten HTTP-Clients senden Accept-Encoding: gzip, deflate, br und dekomprimieren standardmäßig transparent, aber prüfen Sie, dass Sie es nicht deaktiviert haben, und entfernen Sie den Header nie. Wenn Sie Header manuell setzen, fügen Sie ihn hinzu:

headers = {"Accept-Encoding": "gzip, br", "User-Agent": "..."}

Die Bytes, die den Proxy überqueren, sind die komprimierten, also ist das eine direkte, kostenlose Reduktion dessen, was Ihnen berechnet wird.

5. Nutzen Sie bedingte Anfragen, damit unveränderte Seiten fast nichts kosten

Bei jedem wiederkehrenden Crawl laden Sie Seiten nicht blind erneut herunter. Bedingte HTTP-Anfragen lassen den Server Ihnen “nichts geändert” in einer winzigen 304-Antwort sagen, statt den ganzen Body erneut zu senden. Speichern Sie das ETag oder Last-Modified jedes Fetchs und senden Sie es zurück:

# Beim erneuten Fetch den gespeicherten Validator senden
headers = {"If-None-Match": stored_etag}      # oder If-Modified-Since
r = client.get(url, headers=headers)
if r.status_code == 304:
    pass   # unverändert: ein paar Bytes statt der vollen Seite

Ein 304 kostet fast nichts im Vergleich zu einer vollen Seite, und bei einem Überwachungsjob, bei dem sich die meisten Seiten selten ändern, kann das allein die Bandbreite drastisch senken.

6. Holen Sie nicht erneut, was sich nicht geändert hat

Verwandt, aber breiter als HTTP-Validatoren: verfolgen Sie, was Sie bereits erfasst haben, und überspringen Sie es. Nutzen Sie Sitemap-lastmod-Zeitstempel, um geänderte URLs zu finden, halten Sie einen Content-Hash pro Seite und überspringen Sie das erneute Verarbeiten identischen Inhalts, und deduplizieren Sie Ihre Crawl-Frontier, damit Sie dieselbe URL nicht zweimal in einem Lauf holen. Das billigste Gigabyte ist das, das Sie nie herunterladen.

7. Holen Sie nur die Bytes, die Sie brauchen

Wenn Sie nur die Header einer Datei oder ihren ersten Chunk brauchen (eine Metadaten-Prüfung, ein Content-Type-Sniff), laden Sie nicht das Ganze herunter. Eine HEAD-Anfrage liefert Header ohne Body, und eine Range-Anfrage zieht nur die von Ihnen angegebenen Bytes, wo der Server es unterstützt:

client.head(url)                                   # nur Header, kein Body
client.get(url, headers={"Range": "bytes=0-2047"}) # nur die ersten 2 KB

Das zählt am meisten, wenn Ihr Crawl große Medien, PDFs oder Downloads berührt, bei denen Sie nur einen kleinen Teil oder nur Metadaten brauchen.

8. Machen Sie Retries und Geo-Targeting effizient

Jeder fehlgeschlagene Versuch verbraucht weiterhin Bandbreite, also blähen verschwenderische Retries Ihre Rechnung leise auf. Machen Sie Backoff und begrenzen Sie Retries, statt eine fehlschlagende URL zu bombardieren, und vermeiden Sie zu enge Geo-Filter (Land + Stadt + ASN auf einmal), die Anfragen fehlschlagen und erneut versuchen lassen, wenn keine passende IP frei ist, lockern Sie stattdessen einen Filter. Setzen Sie sinnvolle Timeouts, damit eine hängende Antwort nicht zieht, und passen Sie Ihre Session-Strategie an den Job an, damit Sie Flows nicht unnötig neu aufbauen. Effiziente Anfragen sind billige Anfragen.

9. Messen Sie Bytes pro Datensatz

Sie können nicht senken, was Sie nicht messen. Verfolgen Sie die Bandbreite pro Job und, besser, die Bytes pro erfolgreich extrahiertem Datensatz, und die Verschwendung offenbart sich: eine Seite, die Megabytes pro Zeile kostet, zieht meist Assets, die Sie blockieren könnten, oder rendert, wo Sie eine API hätten treffen können. Loggen Sie es, beobachten Sie den Trend, und optimieren Sie zuerst die schlimmsten Übeltäter.

Ein Hinweis zum verantwortungsvollen Vorgehen

Bandbreite zu senken ist nicht nur billiger für Sie, es ist leichter für die Seiten, von denen Sie erfassen: weniger und kleinere Anfragen bedeuten weniger Last auf ihren Servern. Das bringt Kosteneffizienz und guten Umgang in Einklang. Erfassen Sie weiterhin öffentliche Daten, respektieren Sie die Bedingungen und Rate-Limits jeder Seite, und lassen Sie Effizienz Ihren Fußabdruck verringern. Unsere Richtlinie zur akzeptablen Nutzung ist die maßgebliche Quelle dafür, was auf Shifter erlaubt ist.

FAQ

Was verbraucht beim Scrapen über Proxies die meiste Bandbreite? Vollständiges Browser-Rendering, mit weitem Abstand, weil es jedes Bild, jede Schrift, jedes Video und jedes Skript der Seite herunterlädt. Das Rendering zu senken (oder schwere Ressourcentypen zu blockieren, wenn Sie rendern müssen) ist die wirkungsvollste Änderung, die Sie machen können.

Bricht das Blockieren von Bildern und Schriften das Scraping? Meist nicht, Sie brauchen sie selten für die Datenextraktion. Testen Sie, dass die Seite Zielinhalte nicht lazy hinter Bildern nachlädt; für die große Mehrheit der Jobs ist das Blockieren von Bild-, Media- und Schrift-Anfragen sicher und senkt die Bandbreite erheblich.

Berechnen Residential Proxies fehlgeschlagene oder blockierte Anfragen? Die Bytes, die den Proxy überqueren, sind abrechenbar, also kosten fehlgeschlagene Versuche und Retries weiterhin Bandbreite. Deshalb zählen effiziente Retries, sinnvolle Timeouts und das Vermeiden zu enger Geo-Filter (die Fehlschläge verursachen) für Ihre Rechnung.

Ist es erlaubt, die JSON-API einer Seite zu treffen? Einen öffentlichen Endpunkt aufzurufen, den die Seite selbst nutzt, ist gängige Praxis und weit effizienter, aber die Bedingungen und Rate-Limits der Seite gelten weiterhin. Erfassen Sie verantwortungsvoll und holen Sie sich Rechtsberatung für alles Unsichere.

Wie viel kann ich realistisch sparen? Es variiert je Ziel, aber unnötiges Rendering zu überspringen, schwere Ressourcen zu blockieren und unveränderte Seiten nicht erneut zu holen, senken die Gesamtbandbreite für dieselben extrahierten Daten häufig um mehr als die Hälfte.

Fazit

Auf einem Pro-GB-Tarif ist Bandbreiteneffizienz Kosteneffizienz, und die meisten Scraper lassen viel liegen: sie rendern, wo sie holen könnten, laden Assets herunter, die sie nie lesen, und ziehen Seiten erneut, die sich nie geändert haben. Arbeiten Sie diese Liste ab, überspringen Sie den Browser, wenn Sie können, treffen Sie die API, blockieren Sie schwere Ressourcen, lassen Sie die Komprimierung an, nutzen Sie bedingte Anfragen, holen Sie unveränderte Seiten nicht erneut, holen Sie nur, was Sie brauchen, machen Sie Retries effizient, und messen Sie, und dieselben Daten kommen für einen Bruchteil der Bytes zurück.

Diese Effizienz verstärkt sich mit der Poolqualität: saubere IPs bedeuten weniger Blocks und Retries, was weniger verschwendete Bytes bedeutet, also lohnt es sich, die richtigen Proxies fürs Scrapen zu wählen neben dem Abstimmen Ihres Clients. Sehen Sie die Pro-GB-Tarife auf der Preisseite, richten Sie dann einen gut abgestimmten Scraper auf das Residential-Gateway und beobachten Sie, wie die Bytes fallen.