HTTP Caching Erklärt: Starker Cache vs. Ausgehandelter Cache

Browser-Caching-Mechanismus

Wir alle wissen, dass der Browser, wenn wir eine Webseite öffnen, eine Anfrage an den entsprechenden Server basierend auf der eingegebenen URL sendet, um die benötigten Datenressourcen abzurufen. Während dieses Prozesses kann es jedoch einige Zeit dauern, bis die Seite geladen ist (was zu einem weißen Bildschirm führt), bevor sie auf dem Bildschirm gerendert wird.

Bei dem Versuch, die Benutzererfahrung zu verbessern, werden verschiedene Caching-Techniken unerlässlich, wie z. B. DNS-Caching, CDN-Caching, Browser-Caching und lokales Seiten-Caching. Eine gute Caching-Strategie kann redundante Ressourcenanfragen reduzieren, den Server-Overhead senken und die Seitenladegeschwindigkeit verbessern.

Dieser Artikel konzentriert sich auf HTTP-Strong-Caching und Negotiated Caching.

Grundprinzipien

Wenn ein Browser eine Ressource lädt, bestimmt er zunächst anhand der Anfrageheader Expires und Cache-Control, ob die Strong-Caching-Strategie angewendet werden soll. Dies bestimmt, ob der Browser die Ressource vom Remote-Server anfordern oder aus dem lokalen Cache abrufen soll.

Strong Caching

In Browsern wird Strong Caching in zwei Kategorien unterteilt: Expires (definiert in der HTTP/1.0-Spezifikation) und Cache-Control (definiert in HTTP/1.1).

Expires

Expires ist ein Standard aus HTTP/1.0, der als Antwortheaderfeld verwendet wird, um die Ablaufzeit einer Ressource anzugeben. Der Wert ist ein absoluter Zeitstempel, der vom Server zurückgegeben wird.

Wenn ein Browser zum ersten Mal eine Ressource anfordert, enthält der Antwortheader des Servers das Feld Expires.
Wenn der Browser das nächste Mal dieselbe Ressource anfordert, überprüft er den Wert Expires aus der vorherigen Antwort.
Wenn die aktuelle Anfragezeit vor der von Expires angegebenen Ablaufzeit liegt, verwendet der Browser direkt die zwischengespeicherte Ressource.

Da sich Expires jedoch auf die lokale Systemzeit stützt, können Abweichungen zwischen Client- und Serveruhren zu Cache-Inkonsistenzen führen.

Cache-Control

Wie bereits erwähnt, hat Expires einen Nachteil: Wenn die lokale Zeit des Clients von der Zeit des Servers abweicht, kann die Cache-Genauigkeit beeinträchtigt werden. Um dieses Problem zu beheben, führte HTTP/1.1 das Feld Cache-Control ein, das Vorrang vor Expires hat. Im Gegensatz zu Expires definiert Cache-Control den Cache-Ablauf mithilfe einer relativen Zeit anstelle eines absoluten Zeitstempels.

Die gebräuchlichsten Cache-Control-Direktiven sind:

max-age: Gibt die Anzahl der Sekunden (z. B. 3600) an, während der die Ressource frisch bleibt (d. h. aktuelle Zeit + 3600 Sekunden).
s-maxage: Ähnlich wie max-age, aber speziell für das Caching auf Proxy-Servern.
private: Die Ressource darf nur von privaten Caches zwischengespeichert werden (d. h. vom Client, aber nicht von freigegebenen Caches wie Proxy-Servern).
public: Die Ressource kann sowohl vom Client als auch von Proxy-Servern zwischengespeichert werden.
no-store: Verhindert jegliches Caching.
no-cache: Die Ressource wird im lokalen Cache gespeichert, muss aber vor der Bereitstellung für den Client erneut mit dem Ursprungsserver validiert werden.

Negotiated Caching

Strong Caching wird allein vom Browser bestimmt. Wenn Strong Caching nicht getroffen wird, sendet der Browser eine Anfrage an den Server, um zu überprüfen, ob Negotiated Caching angewendet wird. Wenn der Cache gültig ist, gibt der Server den Status 304 Not Modified anstelle neuer Ressourcendaten zurück.

Negotiated Caching (auch Conditional Caching genannt) wird vom Server bestimmt und umfasst zwei Sätze von gepaarten Headern. Wenn der Browser seine erste Anfrage stellt, fügt der Server entweder einen Last-Modified- oder einen ETag-Header in die Antwort ein. Nachfolgende Anfragen enthalten die entsprechenden Anfrageheader (If-Modified-Since oder If-None-Match), um festzustellen, ob sich die Ressource geändert hat.

Last-Modified: Gibt die letzte Änderungszeit der Ressource an, die vom Server zurückgegeben wird.
If-Modified-Since: Wird vom Browser in einer Anfrage gesendet und enthält den vorherigen Wert Last-Modified.
ETag: Ein eindeutiger Bezeichner für eine Ressource. Wenn sich die Ressource ändert, ändert sich auch der Wert ETag. Im Gegensatz zu Last-Modified, das sich auch dann ändern kann, wenn der Dateiinhalt gleich bleibt, gewährleistet ETag eine genauere Cache-Validierung.
If-None-Match: Wird vom Browser in einer Anfrage gesendet und enthält den zuvor zurückgegebenen Wert ETag.

Strong Caching und Request Flow

Wenn ein Browser eine Ressource anfordert, prüft er zunächst, ob ein lokaler Cache-Eintrag vorhanden ist. Wenn kein Eintrag vorhanden ist, sendet er eine Anfrage an den Server und speichert den zurückgegebenen Wert Last-Modified.
Wenn ein Cache-Eintrag vorhanden ist, prüft der Browser zunächst, ob Strong Caching noch gültig ist (Cache-Control hat Vorrang vor Expires). Wenn der Cache noch gültig ist, stellt der Browser die zwischengespeicherte Ressource bereit (HTTP-Status 200).
Wenn Strong Caching abgelaufen ist, initiiert der Browser eine Anfrage mit der Negotiated-Caching-Strategie. Der Server prüft zunächst den Wert ETag:
- Wenn der ETag des Clients mit dem des Servers übereinstimmt, gibt der Server 304 Not Modified zurück (ohne die Ressourcendaten zu senden).
Wenn der Server ETag nicht verwendet, prüft er If-Modified-Since. Wenn der angegebene Wert mit der letzten Änderungszeit des Servers übereinstimmt, gibt der Server 304 Not Modified zurück.
Wenn weder ETag noch If-Modified-Since übereinstimmen, sendet der Server eine neue Ressource und aktualisiert den Cache.

Warum wird ETag benötigt?

ETag wurde eingeführt, um Probleme mit Last-Modified zu beheben, darunter:

Ungenauigkeiten bei Zeitstempeln: Der Zeitstempel der letzten Änderung einer Datei kann sich auch dann ändern, wenn der Inhalt gleich bleibt, was zu einer unnötigen Cache-Invalidierung führt.
Hochfrequente Änderungen: Last-Modified unterstützt nur eine Granularität auf Sekundenebene, die für häufig aktualisierte Dateien möglicherweise nicht ausreicht. ETag gewährleistet eine bessere Präzision.
Einige Server können die letzte Änderungszeit einer Datei nicht genau bestimmen, was ETag zu einer besseren Alternative macht.

Unterschiede bei HTTP-Statuscodes

200: Anfrage erfolgreich, Server gibt eine neue Kopie der Ressource zurück.
200 (from memory cache / from disk cache): Strong Caching ist noch gültig, sodass der Browser die Ressource aus dem lokalen Cache lädt.
304 Not Modified: Die Anfrage verwendete Negotiated Caching, und der Server hat festgestellt, dass die zwischengespeicherte Ressource noch gültig ist.

Hinweis:

from memory cache: Die Ressource wurde aus dem Speicher abgerufen (z. B. nach einer Soft Refresh).

from disk cache: Die Ressource wurde aus dem Festplattenspeicher abgerufen (z. B. nach dem erneuten Öffnen der Browser-Registerkarte).

Cache-Prioritätsregeln

Wenn sowohl Expires als auch Cache-Control vorhanden sind, hat Cache-Control Vorrang.
- Cache-Control > Expires
Wenn sowohl Strong Caching als auch Negotiated Caching vorhanden sind, prüft der Browser zuerst Strong Caching. Wenn der Cache noch gültig ist, wird er verwendet. Andernfalls wird Negotiated Caching angewendet.
- Strong Caching > Negotiated Caching
Wenn sowohl ETag als auch Last-Modified vorhanden sind, hat ETag Vorrang.
- ETag > Last-Modified

Zusätzliche Hinweise

In der HTTP/1.0-Spezifikation gab es eine ältere Caching-Direktive namens Pragma, die die gleiche Wirkung hatte wie Cache-Control: no-cache und den Browser zwang, die Ressource mit dem Ursprungsserver neu zu validieren.

Caching-Prioritätsreihenfolge:

Pragma -> Cache-Control -> Expires -> ETag -> Last-Modified

Heuristik-Caching

Wenn eine Antwort keine Expires- oder Cache-Control-Header enthält, aber Last-Modified enthält, wenden Browser eine Heuristik-Caching-Strategie an.

Die vom Browser verwendete Formel lautet:

(currentTime - lastModified) * 0.1

Diese Caching-Strategie wird nur angewendet, wenn der Server keine Cache-Richtlinie explizit definiert.

Weitere Informationen finden Sie unter: HTTP Heuristic Caching (Missing Cache-Control and Expires Headers) Explained

Weitere Überlegungen

Negotiated Caching ist nur in Kombination mit Strong Caching wirksam. Ohne Strong Caching hat Negotiated Caching keine Bedeutung.
Die meisten Webserver aktivieren Negotiated Caching standardmäßig und verwenden in der Regel sowohl Last-Modified als auch ETag gleichzeitig.

Wichtige Szenarien

Stellen Sie in verteilten Systemen sicher, dass die Last-Modified-Zeitstempel auf allen Servern konsistent sind. Andernfalls kann der Lastenausgleich zu inkonsistenten Cache-Validierungen führen, was zu unnötigen Ressourcenabrufen führt.
In verteilten Systemen wird empfohlen, ETag zu deaktivieren, da verschiedene Server möglicherweise unterschiedliche ETag-Werte generieren, was zu unnötigen Cache-Fehlern führt.

Wir sind Leapcell, Ihre erste Wahl für das Hosting von Backend-Projekten.

Leapcell ist die Serverless-Plattform der nächsten Generation für Webhosting, asynchrone Aufgaben und Redis:

Unterstützung mehrerer Sprachen

Entwickeln Sie mit Node.js, Python, Go oder Rust.

Stellen Sie unbegrenzt viele Projekte kostenlos bereit

Zahlen Sie nur für die Nutzung – keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

Pay-as-you-go ohne Leerlaufgebühren.
Beispiel: 25 $ unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

Intuitive Benutzeroberfläche für mühelose Einrichtung.
Vollautomatische CI/CD-Pipelines und GitOps-Integration.
Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

Mühelose Skalierbarkeit und hohe Leistung

Automatische Skalierung zur einfachen Bewältigung hoher Parallelität.
Null Betriebsaufwand – konzentrieren Sie sich einfach auf das Erstellen.

Erfahren Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ