Caching gehoert zu den aeltesten Funktionen eines Proxys: Statt denselben Inhalt immer wieder herunterzuladen, wird eine Kopie gespeichert und spaetere Anfragen werden lokal beantwortet. Mit der Verbreitung von HTTPS hat sich der Anwendungsbereich dieser Funktion verengt, aber sie ist nicht vollstaendig verschwunden — und in Ihrer eigenen Datenerfassungspipeline ist sie nach wie vor eine erhebliche Einsparquelle.
Grundlegender Ablauf
Bei einem Cache-Treffer wird der Ursprungsserver gar nicht erst kontaktiert. Das ist ein Gewinn sowohl bei der Geschwindigkeit als auch bei der Bandbreite und der Last auf dem Zielserver.
Wer bestimmt, was gespeichert wird?
Die Entscheidung trifft der Server und teilt sie ueber den Header Cache-Control mit:
| Direktive | Bedeutung | Proxy-Verhalten |
|---|---|---|
public | Darf von einem gemeinsamen Cache gespeichert werden | Speichert |
private | Nur der Browser darf speichern | Speichert nicht |
no-store | Darf gar nicht gespeichert werden | Speichert nicht |
no-cache | Darf gespeichert werden, muss aber bei jeder Verwendung validiert werden | Stellt eine konditionale Anfrage |
max-age=3600 | Gilt 3600 Sekunden lang als frisch | Geht waehrend dieser Zeit nicht zur Quelle |
s-maxage=600 | Eigene Dauer fuer gemeinsame Caches | Hat Vorrang vor diesem Wert |
no-cachebedeutet nicht "gar nicht speichern" — es bedeutet "speichern, aber vor der Verwendung validieren". Das Gegenstueck zu "gar nicht speichern" ist no-store.
Konditionale Anfragen: 304 Not Modified
Wenn die Kopie im Cache veraltet, muss der Proxy den Inhalt nicht von Grund auf neu herunterladen. Er fragt den Server: "Ist die Version, die ich habe, noch gueltig?"
Die 304-Antwort enthaelt keinen Body; es werden nur Header zurueckgegeben. Das bedeutet, eine 500 KB grosse Seite auf 300 Byte zu reduzieren.
Diesen Mechanismus in Ihrer eigenen Datenerfassungspipeline zu nutzen, senkt die Bandbreitenkosten deutlich.
Wie hat HTTPS das Caching veraendert?
Sobald ein CONNECT-Tunnel aufgebaut ist, sieht der Proxy den Inhalt nicht — folglich kann er ihn auch nicht cachen. Da nahezu das gesamte Web auf HTTPS umgestiegen ist, ist klassisches Proxy-Caching weitgehend funktionslos geworden.
Deshalb ist modernes Caching von der Proxy-Ebene auf die CDN- und Client-Ebene gewandert.
Einen eigenen Cache einrichten
Wenn Proxy-Caching nicht nutzbar ist, koennen Sie denselben Vorteil in Ihrer eigenen Anwendung erzielen. In Datenerfassungspipelines ist das sehr wirkungsvoll:
Diese einfache Schicht verhindert, dass Sie selten geaenderte Seiten immer wieder herunterladen. Bei GB-basierten Ressourcen wie Residential Proxys schlaegt sich die Ersparnis direkt auf der Rechnung nieder.
Wann ist Caching falsch?
Cache geeignet
- Selten geaenderte Produkt- und Kategorieseiten.
- Statische Referenzdaten.
- Aufgaben, die dieselbe Seite mehrmals am Tag abrufen.
- Entwicklungs- und Testphase (schont das Kontingent).
Cache ungeeignet
- Echtzeit-Preis- und Bestandsueberwachung.
- Personalisierte Inhalte.
- Seiten, die eine Session erfordern.
- SEO-Aufgaben, die Rankingveraenderungen verfolgen.
Mit veralteten Daten aus dem Cache zu arbeiten, kann zu schlechteren Ergebnissen fuehren, als gar keine Daten zu erheben. Halten Sie die Cache-Dauer in zeitkritischen Bereichen wie Preisen und Bestaenden sehr kurz oder verzichten Sie ganz darauf.
Zusammenfassung
Proxy-Caching hat mit der Verbreitung von HTTPS im klassischen Sinne weitgehend seine Funktion verloren, denn im CONNECT-Tunnel sieht der Proxy den Inhalt nicht. Dieselbe Logik in Ihrer eigenen Anwendungsschicht aufzubauen, ist dagegen weiterhin moeglich und sehr wertvoll. ETag-basierte konditionale Anfragen eliminieren bei selten geaenderten Inhalten nahezu den gesamten Traffic. Bei zeitkritischen Daten hingegen sollten Sie Caching vermeiden. Fuer die Verbrauchsrechnung werfen Sie einen Blick in unseren Beitrag zur Bandbreite können Sie nachlesen.