So berechnen und reduzieren Sie den Traffic-Verbrauch bei Proxys mit Gigabyte-Abrechnung

Wenn Sie für jedes übertragene Gigabyte bezahlen, wird Traffic nicht mehr abstrakt, sondern zu echtem Geld. Ein unachtsames Skript, das schwere Bilder und Videos lädt, kann über Nacht das Monatsbudget auffressen. Die gute Nachricht: Sie können den Verbrauch steuern – und das ist gar nicht schwer, sobald Sie die Mechanik einmal verstanden haben.

Dieser Leitfaden zeigt Ihnen, wie Sie den Traffic vor dem Start einer Aufgabe berechnen, den tatsächlichen Verbrauch messen und ihn mit einfachen Methoden um ein Vielfaches reduzieren. Wir sprechen hier ausschließlich über die Traffic-Ökonomie, die für jeden Tarif mit Volumenabrechnung gilt – unabhängig vom Proxy-Typ.

Einführung: Warum Sie Traffic im Voraus berechnen sollten

Bei Gigabyte-Abrechnung hat jede Anfrage ihren Preis. Das Problem: Dieser Preis bleibt unsichtbar, bis die Rechnung kommt oder das Guthaben auf null sinkt. Die meisten Anfänger berechnen den Verbrauch im Nachhinein – dabei sollte man es andersherum machen: das Budget vor dem Start kalkulieren und eine Reserve einplanen.

Das nehmen Sie mit

Nach der Lektüre können Sie jede Webseite nach dem Gewicht ihrer Komponenten zerlegen, einen einfachen Traffic-Zähler in Python oder Node schreiben, Sparmethoden anwenden, die den Verbrauch um 70–95 Prozent senken, und das Projektbudget korrekt kalkulieren. Sie verstehen außerdem, wann die volumenbasierte Abrechnung günstiger ist und wann ein Flatrate-Tarif sich lohnt.

Für wen dieser Leitfaden ist

• Für alle, die Daten per Proxy scrapen und sammeln.
• Für Automatisierungsspezialisten, die massenhaft Anfragen absetzen.
• Für Marketer und Analysten, die mit externen Quellen arbeiten.
• Für alle, die weniger bezahlen möchten – bei gleichem Ergebnis.

Was Sie vorher wissen sollten

Grundkenntnisse über HTTP-Anfragen sind ein Plus, aber keine Pflicht. Wir erklären die wichtigsten Begriffe einfach und verständlich. Für den praktischen Teil brauchen Sie minimale Erfahrung beim Ausführen von Skripten in Python oder Node.js – den Code liefern wir fertig mit Kommentaren.

Wie viel Zeit Sie einplanen sollten

Zum Lesen und Verstehen der Theorie brauchen Sie etwa 30 Minuten. Die Einrichtung des Traffic-Zählers dauert 15–20 Minuten. Die Umsetzung der Sparmethoden in Ihrem Projekt hängt von dessen Komplexität ab, aber die Grundlagen haben Sie in einer Stunde integriert.

Vorbereitung: Werkzeuge und Zugänge

Bevor Sie Traffic zählen und sparen, stellen wir ein Set an Werkzeugen zusammen. Alles ist kostenlos und läuft unter Windows, macOS und Linux.

Benötigte Werkzeuge

• Python 3.10 oder neuer – für Skripte zur Traffic-Berechnung.
• Node.js 18 oder neuer – die Alternative für alle, die mit JavaScript vertraut sind.
• Die requests-Bibliothek für Python – Installation mit dem Befehl pip install requests.
• Die Playwright-Bibliothek – für die Arbeit mit einem Headless-Browser, Installation über pip install playwright und playwright install.
• Ein Browser mit Entwicklertools – jeder moderne Browser ist geeignet; das integrierte Network-Panel benötigen Sie für die manuelle Seitenanalyse.
• Zugang zum Kundenbereich Ihres Proxy-Anbieters – dort sehen Sie die tatsächliche Traffic-Statistik.

Systemanforderungen

Es funktioniert jeder Rechner, der in den letzten zehn Jahren hergestellt wurde. 4 Gigabyte Arbeitsspeicher genügen, für einen Headless-Browser sind 8 aber angenehmer. An Festplattenplatz benötigen Sie etwa 2 Gigabyte für die Browser-Engines von Playwright.

Was Sie installieren und einrichten sollten

1. Laden Sie Python von der offiziellen Website herunter und installieren Sie es; setzen Sie bei der Installation ein Häkchen bei „Zu PATH hinzufügen“.
2. Öffnen Sie das Terminal und prüfen Sie die Installation mit dem Befehl python --version.
3. Installieren Sie die Requests-Bibliothek mit dem Befehl pip install requests.
4. Falls Sie mit dem Browser arbeiten möchten, installieren Sie Playwright mit pip install playwright und führen dann playwright install chromium aus.
5. Halten Sie die Verbindungsdaten für Ihren Proxy bereit: Adresse, Port, Benutzername und Passwort.

Tipp: Legen Sie einen separaten Ordner für Traffic-Experimente an. So verlieren Sie nicht den Überblick über Ihre Dateien und können Änderungen leicht rückgängig machen, wenn etwas schiefgeht.

⚠️ Achtung: Bewahren Sie Login und Passwort Ihres Proxys niemals direkt in Code auf, den Sie irgendwohin senden. Nutzen Sie Umgebungsvariablen oder eine separate Konfigurationsdatei, die nicht in falsche Hände gerät.

✅ Prüfung: Wenn die Befehle python --version und pip --version Versionsnummern ohne Fehler ausgeben, ist die Vorbereitung abgeschlossen.

Grundbegriffe einfach erklärt

Bevor wir Bytes zählen, klären wir die Begriffe – ohne Fachjargon, ganz verständlich.

Was ist Traffic?

Traffic ist die Datenmenge, die über Ihre Verbindung fließt. Sie setzt sich zusammen aus dem, was Sie an den Server senden, und dem, was der Server zurückliefert. Bei Gigabyte-Abrechnung zählen beide Richtungen, aber der eingehende Traffic (Serverantworten) ist in der Regel um ein Vielfaches größer als der ausgehende.

Woraus besteht eine Anfrage?

Wenn Sie eine Seite öffnen, sendet der Browser eine Anfrage und erhält eine Antwort. Die Antwort besteht aus Headern (Metadaten zu Größe, Typ, Kodierung) und dem Body (der eigentliche Inhalt: HTML, Bild, Skript). Der Body ist fast immer deutlich schwerer als die Header.

Wichtige Begriffe

• GET-Anfrage – eine normale Anfrage zum Abrufen von Inhalten. Sie liefert Header und Body.
• HEAD-Anfrage – eine Anfrage nur nach Headern, ohne Body. Spart Traffic, wenn Sie den Body nicht brauchen.
• Content-Length – ein Header, der die Größe des Antwort-Bodys in Bytes angibt.
• Accept-Encoding – ein Header, mit dem Sie den Server bitten, die Antwort zu komprimieren.
• gzip und brotli – Komprimierungsalgorithmen, die das Gewicht von Textdaten um ein Vielfaches reduzieren.
• Redirect – die Weiterleitung von einer Adresse zu einer anderen. Jeder Redirect bedeutet eine zusätzliche Anfrage und zusätzlichen Traffic.
• Headless-Browser – ein Browser ohne grafisches Fenster, der per Code gesteuert wird. Er lädt alles, was auch ein normaler Browser lädt, einschließlich schwerer Ressourcen.

Das wichtigste Sparprinzip

Laden Sie nichts, was Sie für Ihre Aufgabe nicht brauchen. Das klingt offensichtlich, aber genau die Missachtung dieser Regel kostet Geld. Wenn Sie den Text einer Produktseite benötigen, brauchen Sie keine Produktfotos, Video-Rezensionen, Werbebanner oder Analytics-Tracker.

Wie sich das Gewicht einer Seite zusammensetzt: eine echte Analyse

Ziel dieses Abschnitts ist es, an einem konkreten Beispiel zu zeigen, dass ein Großteil des Seitengewichts für Sie meist unnötig ist. Wir nehmen eine typische Onlineshop-Seite.

Die Gewichtskomponenten und ihre Anteile

Eine durchschnittliche moderne Seite wiegt zwischen 2 und 5 Megabyte. Das Gewicht verteilt sich ungefähr so:

• Bilder – 50–70 Prozent des Gewichts. Produktfotos, Banner, Icons in hoher Auflösung.
• JavaScript-Skripte – 15–25 Prozent. UI-Logik, Widgets, Chats, Zähler.
• Schriftarten – 5–10 Prozent. Benutzerdefinierte Schriftarten werden als separate Dateien geladen.
• Analytics und Tracker – 5–15 Prozent. Pixel, Statistiksysteme, Werbeskripte.
• Video und Medien – von null bis zu extremen Größen. Autoplay-Videos sprengen das Budget.
• HTML-Dokument – nur 1–5 Prozent. Genau hier liegen meist die Daten, die Sie brauchen.

Praktische Schlussfolgerung

Wenn Sie Textdaten aus HTML benötigen, können Sie auf 90–95 Prozent des Seitengewichts verzichten. Eine Fünf-Megabyte-Seite schrumpft auf 100–200 Kilobyte nutzbares HTML. Das ist keine Übertreibung, sondern der typische Fall.

So analysieren Sie eine Seite manuell

1. Öffnen Sie die Seite im Browser.
2. Drücken Sie F12, um die Entwicklertools zu öffnen.
3. Wechseln Sie zum Tab Network.
4. Aktualisieren Sie die Seite mit F5.
5. Unten im Panel sehen Sie die Gesamtgröße der geladenen Daten und die Anzahl der Anfragen.
6. Sortieren Sie die Anfragen nach der Spalte „Size“, um die schwersten Ressourcen zu sehen.
7. Achten Sie auf die Spalte „Type“: img steht für Bilder, script für Skripte, font für Schriftarten.

Tipp: Im Network-Panel gibt es Filter nach Ressourcentyp. Klicken Sie auf den Button „Img“, um das Gesamtgewicht aller Bilder zu sehen. Diese Zahl ist meist schockierend.

✅ Prüfung: Sie sollten sehen, dass das HTML-Dokument um ein Vielfaches leichter ist als die Summe aus Bildern und Skripten. Das bestätigt, dass das größte Sparpotenzial im Verzicht auf Medien liegt.

Schritt 1: Den tatsächlichen Verbrauch Ihrer Aufgabe messen

Ziel dieses Schritts: Sie lernen genau zu berechnen, wie viel Traffic Ihr Skript verbraucht, um den Verbrauch bewusst zu steuern.

Traffic-Zählung mit Python

Die requests-Bibliothek ermöglicht es, die Größe jeder Antwort zu ermitteln. Wir summieren die Länge des Bodys und die ungefähre Größe der Header.

1. Erstellen Sie eine Datei traffic_counter.py in Ihrem Arbeitsordner.
2. Fügen Sie den Import der Bibliothek ein: import requests.
3. Konfigurieren Sie die Proxy-Einstellungen als Dictionary mit den Schlüsseln http und https.
4. Initialisieren Sie vor der Anfrageschleife eine Variable total_bytes mit dem Wert null.
5. Addieren Sie nach jeder Anfrage die Länge des Inhalts von response.content hinzu.
6. Für Genauigkeit addieren Sie auch die Größe der Header, indem Sie die Länge ihrer String-Repräsentation berechnen.
7. Teilen Sie am Ende total_bytes durch 1048576, um Megabyte zu erhalten.

Die Logik ist einfach: len(response.content) liefert die Anzahl der Bytes im Antwort-Body. Die Header werden als Summe der Längen von Schlüsseln und Werten berechnet. Bei den meisten Aufgaben ist der Antwort-Body der Hauptteil des Traffics, daher liefert selbst eine einfache Zählung über content eine Genauigkeit von etwa 95 Prozent.

Wichtig: response.content liefert bereits dekomprimierte Daten, wenn der Server eine komprimierte Antwort gesendet hat. Der tatsächliche Netzwerk-Traffic könnte durch die Komprimierung geringer gewesen sein. Um genau die übertragenen Bytes zu messen, schauen Sie sich den Header Content-Length der Antwort an; er zeigt die Größe des Bodys, wie er über das Netzwerk ging.

Genaue Zählung der übertragenen Bytes

1. Greifen Sie nach der Anfrage auf response.headers.get('Content-Length') zu.
2. Falls ein Wert vorhanden ist, verwenden Sie ihn als tatsächliches Gewicht des Bodys in Bytes.
3. Falls der Header fehlt (z.B. bei Streaming), orientieren Sie sich an der Länge des Inhalts, wobei Sie beachten, dass dies die dekomprimierte Größe ist.

Traffic-Zählung mit Node.js

In Node können Sie das eingebaute https-Modul oder die axios-Bibliothek verwenden. Das Prinzip ist dasselbe: Wir summieren die Größe der empfangenen Daten.

1. Erstellen Sie eine Datei traffic_counter.js.
2. Binden Sie die Bibliothek für Anfragen ein.
3. Initialisieren Sie eine Variable totalBytes mit null.
4. Nehmen Sie für jede Antwort den Header content-length oder berechnen Sie die Länge des Datenpuffers.
5. Addieren Sie diesen Wert zu totalBytes.
6. Geben Sie am Ende totalBytes geteilt durch 1048576 aus, um Megabyte zu erhalten.

Tipp: Loggen Sie das Gewicht jeder Anfrage einzeln, nicht nur das Endergebnis. So sehen Sie sofort, welche URL am meisten verbraucht, und können gezielt optimieren.

Abgleich mit der Statistik im Kundenbereich

Ihr eigener Zähler und die Statistik des Proxy-Anbieters können leicht voneinander abweichen. Das ist normal. Die Gründe:

• Der Dienst zählt den gesamten Verbindungstraffic, einschließlich Overhead-Paketen und dem Aufbau des verschlüsselten Kanals.
• Ihr Zähler erfasst nur die Nutzlast der Antworten.
• Anfrage-Header, DNS-Austausch und Verbindungsaufbauten verursachen einen kleinen Overhead.

1. Führen Sie Ihr Skript mit 100 Anfragen aus und notieren Sie das Ergebnis Ihres Zählers.
2. Rufen Sie vor und nach dem Lauf den Kundenbereich des Proxy-Anbieters auf.
3. Halten Sie die Differenz der Werte im Kundenbereich fest.
4. Vergleichen Sie mit Ihrem Zähler. Eine Abweichung von 10–20 Prozent ist normal – das sind die Verbindungskosten.

⚠️ Achtung: Planen Sie immer einen Overhead für die Verbindung ein. Der reale Verbrauch liegt fast immer 10–20 Prozent über dem, was die Berechnung der Nutzlast auf Client-Seite zeigt.

✅ Prüfung: Wenn Ihr Zähler einen Wert anzeigt, der nach Abzug des Overheads nahe an der Differenz im Kundenbereich liegt, ist die Zählung korrekt eingerichtet und Sie können Ihren Messungen vertrauen.

Schritt 2: Grundlegende Methoden zur Traffic-Reduzierung

Ziel dieses Schritts: einfache Techniken anwenden, die den Verbrauch ohne komplexen Code reduzieren. Wir beginnen mit den einfachsten.

Methode 1: Komprimierung über Accept-Encoding aktivieren

Textdaten (HTML, JSON, Skripte) lassen sich hervorragend komprimieren. Wenn Sie den Server um eine komprimierte Antwort bitten, reduzieren Sie den Traffic um das 3- bis 5-fache.

1. Fügen Sie zu den Anfrage-Headern Accept-Encoding mit dem Wert gzip, br, deflate hinzu.
2. Die requests-Bibliothek in Python erledigt das automatisch und dekomprimiert die Antwort selbst.
3. Stellen Sie sicher, dass Sie diese Option nicht manuell deaktiviert haben.
4. Prüfen Sie den Antwort-Header Content-Encoding: Wenn dort gzip oder br steht, funktioniert die Komprimierung.

br steht für brotli – einen moderneren Algorithmus, der stärker komprimiert als gzip. Die meisten Server unterstützen ihn. Für die Nutzung von brotli in Python installieren Sie das Paket brotli mit dem Befehl pip install brotli.

Tipp: Komprimierung kostet keinen Traffic und fast keine CPU-Last. Lassen Sie sie immer aktiviert. Das ist das Erste, was Sie bei einem hohen Verbrauch prüfen sollten.

Methode 2: HEAD statt GET verwenden

Wenn Sie nur Header benötigen – z.B. um zu prüfen, ob eine Seite existiert, ihre Größe oder ihr Änderungsdatum zu erfahren –, verwenden Sie eine HEAD-Anfrage. Sie liefert Header ohne Body.

1. Rufen Sie statt requests.get die Methode requests.head auf.
2. Prüfen Sie die gewünschten Header in response.headers.
3. Der Body wird dabei nicht übertragen – die Ersparnis beträgt bei solchen Prüfungen bis zu 99 Prozent.

Typische Anwendungsfälle für HEAD: Link-Status prüfen, Dateigröße vor dem Download ermitteln, letzte Änderung für den Cache feststellen.

Methode 3: Überflüssige Redirects vermeiden

Jeder Redirect ist eine zusätzliche komplette Anfrage-Antwort-Runde. Wenn eine Website ständig von http auf https oder von einer Adresse auf eine andere weiterleitet, zahlen Sie für unnötige Umwege.

1. Nutzen Sie direkt die finale Adresse: mit https und ohne unnötige Schrägstriche.
2. Wenn Sie wissen, dass eine Adresse auf www weiterleitet, rufen Sie direkt die www-Version auf.
3. In der Bibliothek können Sie die automatische Weiterleitung mit dem Parameter allow_redirects auf False deaktivieren, um den Prozess manuell zu steuern.
4. Erstellen Sie einmal eine Redirect-Karte und gehen Sie dann direkt auf die Zieladressen.

Methode 4: Bilder und Medien bei einfachen Anfragen deaktivieren

Wenn Sie mit der requests-Bibliothek statt mit einem Browser arbeiten, laden Sie Bilder nicht automatisch. requests lädt nur die URL, die Sie angegeben haben. Das ist ein riesiger Vorteil gegenüber dem Browser.

Wenn Sie nur HTML benötigen, liefert requests.get Ihnen HTML ohne Bilder, weil Bilder vom Browser über separate Anfragen aus Links im HTML geladen werden. Die Bibliothek macht das nicht, wenn Sie sie nicht darum bitten.

Tipp: Für das Sammeln von Textdaten bevorzugen Sie einfache HTTP-Bibliotheken gegenüber einem Browser. Die Traffic-Ersparnis entsteht automatisch, weil Sie keine Medien, Schriften und Tracker laden.

✅ Prüfung: Vergleichen Sie das Gewicht derselben Seite, einmal über requests und einmal über den Browser geladen. Der Unterschied beträgt normalerweise das 10- bis 30-fache zugunsten der einfachen Anfrage.

Schritt 3: Mit Headless-Browser arbeiten und Ressourcen blockieren

Ziel dieses Schritts: Lernen, schwere Ressourcentypen im Browser zu blockieren. Das ist der größte Traffic-Gewinn, wenn der Browser wirklich benötigt wird.

Wann ein Browser nötig ist

Manchmal geht es nicht ohne Browser: Daten werden erst nach dem Laden der Seite per Skript nachgeladen, es gibt Schutz gegen einfache Anfragen oder Inhalte werden dynamisch erzeugt. In diesem Fall lädt der Browser alles Mögliche, und der Traffic schießt in die Höhe. Die Lösung: unnötige Ressourcentypen abfangen und blockieren.

Ressourcen in Playwright blockieren

Mit Playwright können Sie jede Browser-Anfrage abfangen und entscheiden, ob Sie sie durchlassen oder abbrechen. Wir brechen Bilder, Schriften, Medien und Styles ab.

1. Erstellen Sie eine Datei browser_saver.py.
2. Importieren Sie sync_playwright aus playwright.sync_api.
3. Starten Sie den Browser im Headless-Modus.
4. Erstellen Sie einen Kontext mit Proxy-Einstellungen über den Parameter proxy.
5. Richten Sie einen Routen-Handler mit page.route für alle URLs ein.
6. Prüfen Sie im Handler den Ressourcentyp über request.resource_type.
7. Wenn der Typ in der Blockierliste steht, rufen Sie route.abort auf.
8. Andernfalls rufen Sie route.continue_ auf.

Die Liste der Typen, die bei einer typischen Textsammel-Aufgabe blockiert werden: image, media, font, stylesheet. Manchmal kann man auch einen Teil der Skripte blockieren, aber Vorsicht: Ohne sie lädt der Inhalt möglicherweise nicht.

Beispiel für die Handler-Logik

Der Handler erhält ein Anfrageobjekt. Sie nehmen request.resource_type und vergleichen ihn mit der Blockierliste. Wenn die Ressource ein Bild oder eine Schriftart ist, brechen Sie sie ab, und der Browser verbraucht dafür keinen Traffic. Wenn es ein Dokument oder ein benötigtes Skript ist, lassen Sie es durch.

Wichtig: Das Blockieren von image, media und font bricht fast nie die Texterfassung, spart aber den Großteil des Traffics. Beginnen Sie genau damit; das Blockieren von Skripten und Styles fügen Sie erst nach einem Test hinzu, ob die Seite weiterhin die benötigten Daten liefert.

Ressourcen mit Puppeteer in Node blockieren

1. Aktivieren Sie die Anfrage-Abfangung über page.setRequestInterception mit dem Wert true.
2. Abonnieren Sie das request-Ereignis.
3. Prüfen Sie im Handler request.resourceType.
4. Rufen Sie für Bilder, Schriften und Medien request.abort auf.
5. Für alles andere rufen Sie request.continue auf.

⚠️ Achtung: Das Blockieren von Styles kann manchmal dynamische Inhalte stören, die von der Sichtbarkeit der Elemente abhängen. Wenn nach dem Blockieren der Styles Daten fehlen, nehmen Sie stylesheet wieder in die Liste der erlaubten Ressourcen auf.

Tipp: Fügen Sie einen Zähler für blockierte und durchgelassene Anfragen hinzu. Sie werden in Zahlen sehen, dass 80–90 Prozent der Anfragen blockiert werden – und das ist direkte Geldersparnis.

Weitere Sparmaßnahmen im Browser

• Deaktivieren Sie das Laden von Bildern auf Kontext-Ebene, wenn die Engine das unterstützt.
• Öffnen Sie keine überflüssigen Tabs, jeder lädt seine eigenen Ressourcen.
• Schließen Sie die Seite sofort nach dem Abruf der Daten, lassen Sie sie nicht offen.
• Verwenden Sie für eine Reihe von Seiten denselben Browserkontext, statt ihn neu zu starten.

✅ Prüfung: Starten Sie den Browser mit und ohne Blockierung für dieselbe Seite und vergleichen Sie den Traffic mit Ihrem Zähler. Die Ersparnis sollte 70–90 Prozent betragen. Wenn sie geringer ist, prüfen Sie, ob der Routen-Handler wirklich greift.

Schritt 4: Caching und Deduplizierung von Anfragen

Ziel dieses Schritts: nicht zweimal für dasselbe anfragen. Wiederholte Anfragen für unveränderte Daten sind verschwendetes Geld.

Warum es zu Wiederholungen kommt

Bei großen Aufgaben wird dieselbe Ressource immer wieder angefordert: ein gemeinsames Skript auf allen Seiten, sich wiederholende Links, der Neustart eines abgestürzten Skripts von Anfang an. Jede Wiederholung ist Traffic, für den Sie erneut zahlen.

Einfaches Caching von Antworten

1. Legen Sie ein Dictionary oder eine lokale Datenbank an, wo der Schlüssel die URL und der Wert die Antwort ist.
2. Prüfen Sie vor der Anfrage, ob die URL im Cache vorhanden ist.
3. Wenn ja – nehmen Sie die Daten aus dem Cache, ohne eine Netzwerkanfrage zu stellen.
4. Wenn nein – führen Sie die Anfrage aus und speichern Sie die Antwort im Cache.
5. Für einen dauerhaften Cache über mehrere Läufe speichern Sie Antworten in Dateien oder einer lokalen Datenbank.

Ein solcher Cache ist besonders effektiv, wenn Sie ein Skript debuggen und mehrfach hintereinander ausführen. Der zweite und alle weiteren Läufe lesen die Daten von der Festplatte und verbrauchen kein einziges Byte Netzwerk-Traffic.

Deduplizierung der URL-Liste

1. Sammeln Sie vor Beginn alle URLs in einer Liste.
2. Wandeln Sie die Liste in ein Set um, um Duplikate zu entfernen.
3. Normalisieren Sie die Adressen: entfernen Sie unnötige Parameter und bringen Sie sie in eine einheitliche Form mit Schrägstrichen.
4. Verarbeiten Sie nur eindeutige Adressen.

Tipp: Oft verbergen sich Duplikate hinter verschiedenen Parametern am Ende der Adresse, die den Inhalt nicht verändern. Schneiden Sie Tracking- und Sortierparameter vor dem Vergleich ab, und die Zahl der eindeutigen URLs sinkt deutlich.

Bedingte Anfragen zum Sparen

Wenn Sie regelmäßig dieselben Seiten prüfen, verwenden Sie bedingte Anfragen. Der Server liefert nur dann eine vollständige Antwort, wenn sich die Daten geändert haben.

1. Speichern Sie bei der ersten Anfrage die Header ETag und Last-Modified aus der Antwort.
2. Senden Sie sie bei der wiederholten Anfrage in den Headern If-None-Match und If-Modified-Since zurück.
3. Wenn sich die Daten nicht geändert haben, gibt der Server eine kurze Antwort mit Status 304 ohne Body zurück.
4. Sie sparen das Gewicht des gesamten Bodys und zahlen nur für den winzigen Header.

✅ Prüfung: Nach der Cache-Implementierung sollte ein erneuter Skriptlauf mit denselben Daten nahezu null Traffic anzeigen. Wenn der Traffic immer noch hoch ist, prüfen Sie, ob die Cache-Prüfung vor der Netzwerkanfrage erfolgt und nicht danach.

Schritt 5: Traffic-Budget berechnen

Ziel dieses Schritts: den Verbrauch vorhersagen und eine Reserve einplanen, damit Ihnen mitten in der Aufgabe nicht das Guthaben ausgeht.

Die Grundformel

Die Grundformel ist einfach: Der Gesamt-Traffic entspricht der Anzahl der Seiten multipliziert mit dem durchschnittlichen Gewicht einer Seite. Aber der Teufel steckt im Detail, und die sehen wir uns an.

1. Ermitteln Sie das durchschnittliche Gewicht einer verarbeiteten Seite nach allen Optimierungen.
2. Multiplizieren Sie es mit der geplanten Seitenanzahl.
3. Addieren Sie den Verbindungs-Overhead – etwa 15 Prozent obendrauf.
4. Addieren Sie eine Reserve für Wiederholungen und Fehler – weitere 20 Prozent.
5. Die resultierende Zahl ist Ihr realistisches Traffic-Budget.

So messen Sie das Durchschnittsgewicht

1. Führen Sie Ihr optimiertes Skript mit einer Stichprobe von 50–100 Seiten aus.
2. Zählen Sie den Gesamt-Traffic mit Ihrem Zähler.
3. Teilen Sie durch die Anzahl der Seiten – Sie erhalten das durchschnittliche Gewicht einer Seite.
4. Verwenden Sie genau diese Zahl in der Formel, nicht theoretische Annahmen.

Rechenbeispiel

Angenommen, nach dem Blockieren von Medien liegt das durchschnittliche Seitengewicht bei 150 Kilobyte. Sie müssen 100.000 Seiten verarbeiten. Rechnung: 150 Kilobyte mal 100.000 ergibt 15.000.000 Kilobyte, also etwa 14,3 Gigabyte. Dazu 15 Prozent Overhead und 20 Prozent Reserve – insgesamt rund 19,5 Gigabyte. An dieser Größenordnung sollten Sie sich bei der Tarifwahl orientieren.

Vergleichen Sie das mit einer Situation ohne Optimierung: Wenn jede Seite 3 Megabyte wöge, würden dieselben 100.000 Seiten 300 Gigabyte ergeben. Der Faktor fünfzehn ist buchstäblich der Unterschied in der Rechnung.

Tipp: Machen Sie vor einem großen Lauf immer einen Probelauf mit einer kleinen Stichprobe. Das gemessene Durchschnittsgewicht ist ehrlicher als jede Annahme und schützt vor unangenehmen Überraschungen in der Rechnung.

⚠️ Achtung: Vergessen Sie die Reserve nicht. Reale Aufgaben halten immer Überraschungen bereit: Ein Teil der Seiten ist schwerer, ein Teil der Anfragen muss wiederholt werden. Ein Budget ohne Reserve ist im ungünstigsten Moment aufgebraucht.

Übersicht der Sparmethoden

Hier eine Übersicht der wichtigsten Methoden: Wie viel jede einspart und womit Sie dafür bezahlen.

• gzip- und brotli-Komprimierung – spart 60–80 Prozent bei Textdaten – Sie zahlen mit einer geringen CPU-Last beim Dekomprimieren.
• Verzicht auf den Browser zugunsten einer HTTP-Bibliothek – spart 90–95 Prozent – Sie zahlen damit, dass Sie keine Daten erhalten, die per Skript nachgeladen werden.
• Blockieren von Bildern und Medien im Browser – spart 50–70 Prozent – Sie zahlen mit dem Einrichten des Anfrage-Intercepts, das Risiko ist minimal.
• Blockieren von Schriftarten – spart 5–10 Prozent – Sie zahlen fast nichts; Schriften werden für Daten nicht benötigt.
• Blockieren von Skripten und Styles – spart 15–25 Prozent – Sie zahlen mit dem Risiko, dass Inhalte nicht geladen werden; ein Test ist nötig.
• HEAD statt GET – spart bis zu 99 Prozent bei Prüfanfragen – Sie zahlen damit, dass Sie keinen Antwort-Body erhalten.
• Redirects vermeiden – spart 10–30 Prozent bei weiterleitenden Websites – Sie zahlen mit einmaligem Zeitaufwand für die Adresskarte.
• Caching von Antworten – spart bis zu 100 Prozent bei Wiederholungen – Sie zahlen mit Speicherplatz für den Cache.
• Deduplizierung von URLs – spart 10–40 Prozent bei Duplikaten – Sie zahlen mit einer einmaligen Normalisierung der Liste.
• Bedingte Anfragen mit ETag – spart bis zu 99 Prozent bei unveränderten Daten – Sie zahlen mit der Speicherung von Versionskennungen.

✅ Prüfung: Berechnen Sie das Budget nach der Formel und vergleichen Sie es mit dem Guthaben Ihres Tarifs. Wenn die Reserve reicht, können Sie starten. Wenn nicht, gehen Sie zurück zu den Sparmethoden und reduzieren Sie das durchschnittliche Seitengewicht.

Schritt 6: Wann eine Flatrate lohnt und wann Volumenabrechnung

Ziel dieses Schritts: eine ehrliche Tarifwahl für Ihre konkrete Aufgabe treffen und nicht wegen eines falschen Abrechnungsmodells zu viel bezahlen.

Wann sich Gigabyte-Abrechnung lohnt

• Die Aufgabe ist einmalig oder selten, die Mengen sind klein.
• Sie haben den Traffic gut optimiert und kennen den Verbrauch genau.
• Das durchschnittliche Seitengewicht ist dank Medien-Blockierung gering.
• Spitzenlasten sind selten, die meiste Zeit ist der Traffic gering.
• Ihnen ist Transparenz wichtig: Sie zahlen genau für das, was Sie genutzt haben.

Wann sich eine Flatrate zum Festpreis lohnt

• Die Aufgabe ist dauerhaft, die Mengen sind groß und stabil.
• Sie müssen mit dem Browser arbeiten und schwere Seiten laden.
• Sie benötigen Bilder, Videos oder andere schwere Medien als Teil der Aufgabe.
• Der Verbrauch ist unvorhersehbar und kann stark ansteigen.
• Ihnen ist die psychologische Ruhe wichtig: eine feste Zahlung ohne Risiko der Kostenüberschreitung.

So berechnen Sie den Übergangspunkt

1. Nehmen Sie den Preis pro Gigabyte im volumenbasierten Tarif.
2. Nehmen Sie den Preis der Flatrate für denselben Zeitraum.
3. Teilen Sie den Flatrate-Preis durch den Preis pro Gigabyte – Sie erhalten die Gigabyte-Menge, bei der beide Tarife gleich teuer sind.
4. Liegt Ihre Verbrauchsprognose über dieser Menge, nehmen Sie die Flatrate.
5. Liegt sie darunter, nehmen Sie die Volumenabrechnung.

Angenommen, die Flatrate kostet so viel wie 50 Gigabyte im Einzeltarif. Das bedeutet: Wenn Sie mehr als 50 Gigabyte verbrauchen, ist die Flatrate günstiger. Bei weniger lohnt sich die Volumenabrechnung. Ihr in Schritt 5 gemessenes Budget liefert sofort die Antwort.

Tipp: Optimieren Sie zuerst den Traffic und wählen Sie dann den Tarif. Eine gute Optimierung verschiebt Sie oft aus der Flatrate-Zone in die Zone der günstigen Volumenabrechnung und spart eine erhebliche Summe.

Kombinierte Strategie

Manchmal ist es optimal, zwei Ansätze zu verfolgen: leichte Textaufgaben über die Volumenabrechnung laufen zu lassen und schwere Browser-Aufgaben über die Flatrate. Die Trennung nach Aufgabentyp ist oft günstiger als ein Tarif für alles.

✅ Prüfung: Berechnen Sie beide Optionen in Geld für Ihre reale Prognose. Sie sollten eine konkrete Ersparnis durch die richtige Wahl erhalten. Wenn der Unterschied minimal ist, nehmen Sie den Tarif, der einfacher zu verwalten ist.

Ergebnisprüfung: Checkliste

Gehen Sie die Liste durch, um sicherzustellen, dass Sie Traffic-Zählung und -Ersparnis richtig eingerichtet haben.

• Der Traffic-Zähler in Python oder Node startet und liefert fehlerfreie Werte.
• Die Zählerwerte stimmen mit der Statistik im Kundenbereich überein, abzüglich des Overheads.
• Die Komprimierung ist in den Anfragen aktiviert, in den Antworten ist Content-Encoding gzip oder br sichtbar.
• Für Prüfaufgaben wird HEAD statt GET verwendet.
• Sie rufen direkt die Endadressen auf, ohne unnötige Redirects.
• Für Textaufgaben verwenden Sie, wo möglich, eine HTTP-Bibliothek statt des Browsers.
• Im Browser ist das Blockieren von Bildern, Medien und Schriftarten eingerichtet.
• Das Caching von Antworten ist eingerichtet, ein erneuter Lauf verbraucht kaum Traffic.
• Die URL-Liste ist von Duplikaten bereinigt.
• Das Budget wurde nach der Formel mit 15 und 20 Prozent Reserve berechnet.
• Der Tarif passt zur Verbrauchsprognose.

So testen Sie

1. Führen Sie das optimierte Skript mit einer Stichprobe von 100 Seiten aus.
2. Notieren Sie den Traffic vorher und nachher im Kundenbereich.
3. Teilen Sie durch die Anzahl der Seiten und vergleichen Sie mit dem Durchschnittsgewicht aus der Berechnung.
4. Wenn es übereinstimmt, funktioniert das System und Sie können skalieren.

✅ Prüfung: Wenn der Probelauf innerhalb des prognostizierten Budgets für 100 Seiten liegt, sind Sie bereit für den vollständigen Lauf. Multiplizieren Sie das Ergebnis mit dem Umfang und stellen Sie sicher, dass das Guthaben ausreicht.

Typische Fehler und Lösungen

Wir sehen uns häufige Probleme an, die bei der Traffic-Zählung und -Einsparung auftreten.

Fehler 1: Der Zähler zeigt weniger an als der Kundenbereich

Ursache: Sie zählen nur den Antwort-Body, während der Dienst den gesamten Netzwerkverkehr inklusive Overhead erfasst. Lösung: Rechnen Sie mit einer Korrektur von 15–20 Prozent und betrachten Sie das als normal, nicht als Fehler.

Fehler 2: Die Komprimierung funktioniert nicht

Ursache: Das brotli-Paket ist nicht installiert oder Accept-Encoding wurde manuell deaktiviert. Lösung: Installieren Sie das brotli-Paket, prüfen Sie die Anfrage-Header und stellen Sie sicher, dass die Antwort Content-Encoding enthält.

Fehler 3: Nach dem Blockieren von Ressourcen fehlen Daten

Ursache: Sie haben Skripte oder Styles blockiert, von denen das Nachladen von Inhalten abhängt. Lösung: Nehmen Sie script und stylesheet wieder in die Erlaubten auf und blockieren Sie nur image, media und font.

Fehler 4: Traffic sinkt beim Caching nicht

Ursache: Die Cache-Prüfung erfolgt nach der Netzwerkanfrage statt vorher. Lösung: Prüfen Sie zuerst den Cache und senden Sie nur dann eine Netzwerkanfrage, wenn keine Daten vorhanden sind.

Fehler 5: Der Browser verbraucht Traffic trotz Handler

Ursache: Der Routen-Handler ist an das falsche URL-Muster gebunden oder wurde nach dem Ladebeginn eingerichtet. Lösung: Richten Sie den Intercept vor dem Öffnen der Seite ein, und zwar für alle URLs mit einem Sternchen.

Fehler 6: Der reale Verbrauch liegt um ein Vielfaches über der Prognose

Ursache: Das Durchschnittsgewicht stammt aus der Theorie und wurde nicht in einem Probelauf gemessen. Lösung: Messen Sie das Durchschnittsgewicht immer an einer realen Stichprobe vor einem großen Lauf.

Fehler 7: Das Budget ist mitten in der Aufgabe aufgebraucht

Ursache: Es wurde keine Reserve für Wiederholungen und Overhead eingeplant. Lösung: Fügen Sie zur Prognose insgesamt 35 Prozent Reserve hinzu und überwachen Sie das Guthaben während des Prozesses.

Fehler 8: Viele wiederholte Anfragen für dieselbe Adresse

Ursache: Duplikate in der URL-Liste aufgrund verschiedener Parameter am Ende der Adresse. Lösung: Normalisieren Sie die Adressen, entfernen Sie Tracking-Parameter und überführen Sie die Liste in ein Set.

Weitere Möglichkeiten und Optimierung

Wenn die grundlegende Ersparnis etabliert ist, können Sie noch mehr herausholen.

Streaming-Verarbeitung großer Antworten

Wenn eine Antwort groß ist, aber nur ein Teil benötigt wird, lesen Sie sie als Stream und brechen Sie das Lesen ab, sobald Sie das Nötige haben. So laden Sie nicht die gesamte Datei herunter. Das ist nützlich, wenn die Daten am Anfang eines großen Dokuments liegen.

Maximalgröße für Antworten begrenzen

Legen Sie eine maximale Antwortgröße fest, die Sie bereit sind zu akzeptieren. Wenn der Server mehr liefert, brechen Sie den Ladevorgang ab. Das schützt vor unerwartet schweren Seiten, die auf einmal viel Traffic verbrauchen könnten.

Batch-Verarbeitung und Parallelität

Parallele Anfragen sparen nicht von selbst Traffic, aber sie ermöglichen es, die Aufgabe schneller abzuschließen und ein Verbrauchsproblem früher zu erkennen. Halten Sie eine vernünftige Anzahl gleichzeitiger Verbindungen, um die Kontrolle über den Traffic nicht zu verlieren.

Logging und Echtzeit-Überwachung

1. Führen Sie einen Live-Traffic-Zähler und geben Sie ihn alle paar hundert Anfragen aus.
2. Definieren Sie einen Schwellenwert, bei dessen Erreichen das Skript stoppt.
3. So überschreiten Sie das Budget nie unbemerkt.

Tipp: Ein automatischer Stopp beim Traffic-Limit ist die beste Absicherung. Das Skript stoppt von selbst am definierten Schwellenwert, und eine Kostenüberschreitung wird selbst bei einem Logikfehler unmöglich.

Nur die benötigten API-Ausschnitte abrufen

Wenn Daten über eine API verfügbar sind, fragen Sie nur die benötigten Felder ab, wo das unterstützt wird. Viele Schnittstellen erlauben es, anzugeben, welche Felder zurückgegeben werden sollen – das reduziert das Antwortgewicht drastisch im Vergleich zur vollständigen Ausgabe.

FAQ: Häufige Fragen zur Traffic-Ersparnis

Wird ausgehender Traffic bei Gigabyte-Abrechnung gezählt?

In der Regel werden sowohl eingehender als auch ausgehender Traffic gezählt, aber ausgehender (Ihre Anfragen) ist um ein Vielfaches kleiner als eingehender (Serverantworten). Die größte Ersparnis liegt immer beim eingehenden Traffic.

Wie genau ist die clientseitige Zählung?

Die Genauigkeit liegt bei etwa 85–95 Prozent gegenüber dem realen Netzwerk-Traffic. Die Differenz ist der Verbindungs-Overhead. Für die Budgetplanung reicht das aus, wenn Sie eine Korrektur einplanen.

Kann man komplett auf den Browser verzichten?

Für viele Textsammlungs-Aufgaben: ja, eine einfache HTTP-Bibliothek genügt und spart um ein Vielfaches Traffic. Ein Browser wird nur dort benötigt, wo Inhalte erst nach dem Laden der Seite per Skript erzeugt werden.

Ist Komprimierung standardmäßig aktiviert?

In den meisten modernen Bibliotheken: ja, aber ein Check lohnt sich. Für brotli kann ein separates Paket erforderlich sein. Kontrollieren Sie immer den Header Content-Encoding in der Antwort.

Was zuerst im Browser blockieren?

Beginnen Sie mit Bildern, Medien und Schriftarten – das ist der größte und sicherste Gewinn. Skripte und Styles blockieren Sie erst nach einem Test, dass die Daten weiterhin geladen werden.

Wie erkennt man, dass das Budget reicht?

Messen Sie das durchschnittliche Seitengewicht in einem Probelauf, multiplizieren Sie es mit der Seitenanzahl, addieren Sie 35 Prozent Reserve und vergleichen Sie mit dem Guthaben des Tarifs. Wenn es hineinpasst, reicht es.

Hilft der Cache bei einem einmaligen Durchlauf?

Bei einem einmaligen Durchlauf ohne Wiederholungen bringt er wenig, aber er spart stark beim Debuggen und bei Neustarts. Bedingte Anfragen und Deduplizierung helfen sogar bei einem einzigen Durchlauf.

Was lohnt sich bei großen, dauerhaften Mengen?

In der Regel eine Flatrate zum Festpreis. Berechnen Sie den Übergangspunkt: Teilen Sie den Flatrate-Preis durch den Preis pro Gigabyte und vergleichen Sie ihn mit Ihrer Verbrauchsprognose.

Beeinflusst die Anzahl der Redirects die Rechnung?

Ja, jeder Redirect ist eine zusätzliche Anfrage-Antwort-Runde. Auf Websites mit Redirect-Ketten spart das Entfernen unnötiger Weiterleitungen einen erheblichen Teil des Traffics.

Wie vermeide ich eine unbeabsichtigte Budgetüberschreitung?

Richten Sie einen Live-Zähler und einen automatischen Stopp beim Erreichen der Traffic-Schwelle ein. Das Skript stoppt von selbst, und eine Überschreitung wird selbst bei einem Fehler unmöglich.

Fazit

Sie haben den Weg vom Nichtverstehen, wohin der Traffic fließt, bis zur vollständigen Kontrolle über den Verbrauch geschafft. Jetzt können Sie das Gewicht einer Seite nach Komponenten zerlegen und sehen, dass ein Großteil des Gewichts unnötig ist. Sie haben einen Traffic-Zähler eingerichtet und gleichen ihn mit der Statistik des Kundenbereichs ab. Sie nutzen Komprimierung, verwenden HEAD statt GET, eliminieren Redirects und bevorzugen leichte HTTP-Bibliotheken gegenüber einem schweren Browser.

Wenn der Browser doch nötig ist, blockieren Sie Bilder, Medien und Schriftarten und reduzieren den Traffic um 70–90 Prozent. Sie cachen Antworten und fragen nicht zweimal dasselbe ab. Und das Wichtigste: Sie berechnen das Budget nach Formel mit Reserve und wählen den Tarif bewusst statt nach Bauchgefühl.

So gehen Sie vor

1. Setzen Sie die grundlegenden Methoden noch heute in Ihrem aktuellen Projekt um.
2. Führen Sie einen Probelauf durch und messen Sie das reale Durchschnittsgewicht einer Seite.
3. Berechnen Sie das Budget neu und wechseln Sie bei Bedarf den Tarif.
4. Richten Sie den automatischen Stopp beim Limit als Absicherung ein.

Traffic zu sparen ist eine Fähigkeit, die sich in jedem Projekt auszahlt. Wenn Sie einmal Zeit in die Einrichtung von Messung und Optimierung investiert haben, zahlen Sie bei gleichem Ergebnis um ein Vielfaches weniger. Fangen Sie klein an, messen Sie den Effekt in Zahlen, und Sie werden überrascht sein, wie viel günstiger dieselbe Arbeit sein kann.