Wie man Proxy-Bandbreitenkosten reduziert: Senken Sie Ihre GB-Rechnung um 60-90 %

Bei Proxies mit Abrechnung pro GB ist Ihre Rechnung in Bytes, nicht in Anfragen — und die meisten dieser Bytes sind Bilder und Schriftarten, die Sie nie analysieren. So entfernen Sie sie und senken eine Wohn-GB-Rechnung um mehr als die Hälfte.

Bei Proxies mit Abrechnung pro GB ist Ihre Rechnung in Bytes, nicht in Anfragen — und die unbequeme Wahrheit ist, dass die meisten dieser Bytes Bilder, Schriftarten und Stylesheets sind, die Sie nie analysieren. Ein einziges Produktfoto in voller Auflösung kann 2,2 MB groß sein; ein vollständiges Browser-Rendering einer Seite liegt bei 2-5 MB. Das schlanke HTML, aus dem Sie tatsächlich extrahieren, ist oft unter 150 KB. Entfernen Sie den Rest und eine Wohn-GB-Rechnung sinkt um 60-90 %. Dieser Leitfaden ist das praktische Handbuch: Assets blockieren, unveränderte Seiten überspringen, komprimieren und zu JSON anstatt HTML routen.

Zuerst wissen, wofür Sie berechnet werden

Wohnbandbreite wird anhand der Summe der in beide Richtungen übertragenen Daten gemessen: Anforderungsheader plus Anforderungskörper und Antwortheader plus Antwortkörper. Das bedeutet, dass jedes Asset, das eine Seite lädt — jedes Bild, jede Schriftart und jedes Tracking-Skript — auf Ihrer Rechnung landet, obwohl nichts davon Ihren Parser speist. Das Optimierungsziel ist einfach: Laden Sie nur die Bytes herunter, die Sie extrahieren. Alles andere ist Verschwendung, für die Sie bezahlen.

Assets in einem Headless-Browser blockieren

Wenn Sie einen Browser steuern, ist dies der größte Hebel. Playwright und Puppeteer ermöglichen es Ihnen, Anfragen abzufangen und die Ressourcentypen abzubrechen, die Sie nicht benötigen. Das Blockieren von Bildern, Medien, Schriftarten und Stylesheets reduziert typischerweise das Seitengewicht erheblich — das DOM wird immer noch aufgebaut, sodass Ihre Selektoren und jedes Hydrations-JSON überleben:

// Playwright: abort the resource types you never parse
await page.route('**/*', (route) => {
  const type = route.request().resourceType();
  if (['image', 'media', 'font', 'stylesheet'].includes(type)) {
    return route.abort();
  }
  return route.continue();
});
await page.goto(url, { waitUntil: 'domcontentloaded' });

Zwei Vorsichtsmaßnahmen: Blockieren Sie nicht die XHR/fetch-Aufrufe, die die Daten tragen, die Sie suchen, und testen Sie, ob die Seite immer noch das rendert, was Sie benötigen — Überblockierung kann die eigene Logik einer Seite brechen. Wenn Sie überhaupt einen Browser gegen einfache Anfragen abwägen, zeigt unser Vergleich der Kosten von Rendering vs. HTTP-Anfragen die 10-50-fache Lücke, die diese Entscheidung wichtig macht.

Seiten überspringen, die sich nicht geändert haben

Das günstigste Byte ist das, das Sie nicht herunterladen. Zwei Techniken reduzieren den Wiederholungsabfall bei Überwachungsaufträgen. Eine HEAD-Anfrage zieht nur Header, um Content-Length oder Last-Modified zu überprüfen, bevor Sie sich zum vollständigen GET verpflichten. Besser noch, ein bedingtes GET sendet den ETag oder Zeitstempel vom letzten Mal und der Server antwortet mit 304 Not Modified mit einem leeren Körper, wenn sich nichts geändert hat — Sie zahlen für ein paar Header-Bytes anstelle der ganzen Seite:

import requests

# conditional GET: 304 = near-zero bytes when unchanged
headers = {"If-None-Match": last_etag,
           "If-Modified-Since": last_seen}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)

if r.status_code == 304:
    pass  # unchanged, no body downloaded, no GB spent
else:
    process(r.content)
    last_etag = r.headers.get("ETag")

Für einen Scraper, der täglich dieselben Seiten erneut überprüft, können bedingte GETs die Bandbreite erheblich reduzieren, da sich die meisten Seiten zwischen den Läufen nicht ändern.

Komprimierung immer akzeptieren

Text komprimiert sich gut — HTML, JSON und CSS schrumpfen mit gzip oder brotli um 70-90 % — und Sie werden auf der komprimierten Größe berechnet, die tatsächlich über die Leitung geht. Senden Sie einen Accept-Encoding-Header und lassen Sie den Server komprimieren. In Pythons requests ist dies standardmäßig aktiviert, wenn Sie es nicht verhindern; in einem rohen Client fordern Sie es explizit an:

headers = {"Accept-Encoding": "gzip, deflate, br"}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)
# requests transparently decompresses; you're billed on the small size

Zu JSON statt HTML routen

Der größte strukturelle Gewinn besteht darin, die gerenderte Seite vollständig zu überspringen. Viele Seiten werden von einem JSON-Endpunkt mit denselben Daten in einem Bruchteil der Bytes geladen — der Preis und der Lagerbestand eines Produkts als 10 KB API-Antwort anstelle einer 3 MB gerenderten Seite. Finden Sie den XHR-Aufruf im Netzwerk-Tab Ihres Browsers und rufen Sie ihn direkt auf. Shopify-Stores sind das klassische Beispiel: der products.json-Endpunkt liefert Ihnen den gesamten Katalog ohne HTML. Wenn Sie die API lesen können, tun Sie es — es ist der Unterschied zwischen Kilobytes und Megabytes pro Datensatz.

Lassen Sie die API die Bytes für Sie zählen

Wenn Sie lieber keine Blockierungsregeln pro Seite manuell einstellen möchten, erledigt eine Scraper-API, die nur bei Bedarf rendert und geparstes Markdown oder JSON zurückgibt, das Asset-Stripping für Sie — Sie erhalten den extrahierten Inhalt, nicht die Megabytes, aus denen er stammt. Und bei Wohnproxies mit Abrechnung pro GB sind die Einsparungen direkt: Weniger Bytes auf der Leitung bedeuten weniger Dollar auf der Rechnung, ohne dass Daten verloren gehen, die Sie behalten. Für das vollständige Bild, was ein Gigabyte tatsächlich kauft, sehen Sie sich unsere Aufschlüsselung der Preisgestaltung pro GB an.

Effizienter scrapen auf Wohnproxies mit Abrechnung pro GB

Häufig gestellte Fragen

Wie wird die Proxy-Bandbreite berechnet?

Durch die Gesamtbytes, die in beide Richtungen übertragen werden: Anforderungsheader plus Anforderungskörper und Antwortheader plus Antwortkörper. Jedes Bild, jede Schriftart und jedes Skript, das eine Seite lädt, zählt zu Ihrem Verbrauch, nicht nur das HTML, das Sie analysieren. Deshalb führt das Blockieren ungenutzter Assets und das Überspringen unveränderter Seiten direkt zu einer niedrigeren Rechnung bei Abrechnungsplänen pro GB.

Bricht das Blockieren von Bildern das Scraping?

Nicht, wenn Sie vorsichtig sind. Das Blockieren von Bildern, Medien, Schriftarten und Stylesheets lässt das DOM und JavaScript intakt, sodass Ihre Selektoren und jedes Hydrations-JSON weiterhin funktionieren — Sie überspringen nur die visuelle Nutzlast. Das Risiko besteht in der Überblockierung: Brechen Sie niemals die XHR/fetch-Aufrufe ab, die Ihre Daten tragen, und testen Sie, ob die Seite immer noch das produziert, was Sie benötigen, bevor Sie im großen Maßstab arbeiten.

Was ist die größte Bandbreiteneinsparung?

Die Umleitung zu einem JSON-Endpunkt anstelle der vollständigen Seitenwiedergabe, wo einer existiert. Eine 10 KB API-Antwort kann eine 3 MB Wiedergabe für denselben Datensatz ersetzen — eine 99%ige Reduzierung. Danach sind das Blockieren von Assets in einem Headless-Browser und die Verwendung von bedingten GETs bei erneuten Crawls die größten Gewinne. Komprimierung ist nahezu kostenlos und sollte immer aktiviert sein.

Wie viel kann ich realistisch sparen?

Das Blockieren von Assets reduziert typischerweise das Gewicht einer gerenderten Seite um weit mehr als die Hälfte; bedingte GETs können die Bandbreite bei erneuten Crawls auf nahezu null reduzieren, wenn sich die Seiten nicht ändern; und der Wechsel von HTML zu einer JSON-Route ist oft eine Reduzierung um über 90 % pro Datensatz. Zusammen genommen ist eine Reduzierung der Wohn-GB-Rechnung um 60-90 % ein realistisches Ziel für die meisten Projekte.

Nichts davon ändert, was Sie extrahieren — es ändert, was Sie dafür bezahlen, es zu extrahieren. Blockieren Sie die Assets, die Sie nie lesen, überspringen Sie die Seiten, die sich nicht bewegt haben, akzeptieren Sie die Komprimierung und bevorzugen Sie JSON-Routen gegenüber vollständigen Wiedergaben. Bei Proxies mit Abrechnung pro GB senken diese vier Gewohnheiten routinemäßig eine Rechnung um mehr als die Hälfte. Für die Architektur, die dies über Millionen von Seiten skaliert, siehe unseren Leitfaden zur großflächigen Scraping-Architektur.

Erhalten Sie geparsten Inhalt ohne die verschwendeten Bytes