Cache-Control-Header: Clientseitiges Caching per HTTP steuern

Browser-Cache

Alle gängigen Browser verfügen über einen Cache, in dem sie die Ressourcen einer abgerufenen Webseite eine Zeit lang zwischenspeichern. Wird eine Ressource benötigt, prüft der Browser immer zuerst, ob sie bereits lokal vorhanden ist, und spart sich gegebenenfalls den Download. (Das ist die Kurzversion; wie es sich tatsächlich verhält, lesen Sie weiter unten.) 

Der Vorteil liegt auf der Hand: Weil seltener Ressourcen erst vom Server geholt werden müssen, wird der Seitenaufbau beschleunigt und weniger Datenvolumen übertragen. Auch der Serverbetreiber profitiert davon, weil weniger Rechenkapazität und Bandbreite benötigt wird. Der Caching-Effekt ist nicht zu unterschätzen: Die durchschnittliche Größe von Websites steigt ständig an und hat gerade im April 2020 die 2000-Kilobyte-Grenze überschritten (Desktop). Jeder Website-Aufruf beinhaltet derzeit durchschnittlich mehr als 70 Requests, also Anforderungen einzelner Ressourcen (Quelle: HTTP Archive).

Es gibt aber – aus Sicht des Website-Betreibers – auch Nachteile: Zum einen liegt die Kontrolle des Browser-Caches natürlich beim Benutzer. Stellt er oder sie zu wenig Speicherplatz ein, kann nicht zwischengespeichert werden. Leert er seinen Cache, müssen alle Ressourcen beim nächsten Aufruf erneut vom Server geladen werden. Gravierender als das aber ist der Umstand, dass Cache-Inhalte veralten. Das kann dazu führen, dass die Besucher gar nicht das sehen, was sie sehen sollen, sondern eine alte, womöglich längst korrigierte Version der jeweiligen Inhalte.

Cache-Steuerung per HTTP

Deshalb sind Website-Betreiber gut beraten, sich über das optimale Caching ihrer Inhalte Gedanken zu machen und den Clients ihrer Besucher mitzuteilen, wann sie mit einer neuen Version rechnen müssen. Das können sie mit dafür vorgesehenen Meta-Informationen zur Cache-Kontrolle in den HTTP-Response-Headern. Empfehlungen dafür wurden 1999 in der RFC 2616 (v. a. Kapitel 13 und 14) gegeben und 2014 durch die RFC 7234 aktualisiert. Die Browser-Hersteller sind daran interessiert, diese Empfehlungen mehr oder weniger umzusetzen, aber nicht dazu verpflichtet.

Genauer können Website-Betreiber dem Client folgende Caching-relevante Informationen übermitteln:

• Darf eine Ressource gecacht werden oder nicht?
• Unter welchen Umständen darf eine gecachte Ressource für eine neue Anfrage verwendet werden?

Darf gecacht werden?

Browserhersteller sind angehalten, ihr Caching so zu gestalten, dass es folgende Regeln einhält: 

• Im Standard dürfen GET-Responses mit Status-Code 200, 203, 206, 300, 301 or 410 zwischengespeichert werden. Dieses Standard-Verhalten kann per Cache-Control-Anweisungen modifiziert werden.
• Es darf nicht gecacht werden, wenn eine Serverantwort die Cache-Control-Anweisungen „no-cache“ oder „no-store“ enthält.
• Für Ressourcen, die im Standard nicht zwischengespeichert werden dürfen, kann der Server das Cachen per „Cache-Control: public“ explizit erlauben.

Ein Beispiel: Der Server schickt als Antwort auf einen Request eine Ressource mit u. a. den folgenden HTTP-Kopfzeilen mit:

HTTP/1.1 200 OK
Last-Modified: Mon, 18 May 2020 10:01:22 GMT
Cache-Control: no-cache

Wird später erneut eine Ressource mit derselben URL benötigt, durchsucht der Client seinen Cache. Er findet dort zwar eine passende lokale Ressource, erfährt aber durch „no-cache“, dass er sie nicht zur Erfüllung des neuen Requests verwenden darf, ohne sich vorher beim Server zu vergewissern, dass sie nicht verändert wurde (Revalidierung). Hätte der Server die Ressource dagegen mit „no-store“ gekennzeichnet, wäre jegliche Zwischenspeicherung unerwünscht.

Verfallsdatum für Ressourcen 

Eine gecachte Ressource darf zur Beantwortung von Anfragen genutzt werden, solange sie noch „frisch“, also noch nicht abgelaufen ist. Um ein Verfallsdatum für die Ressource anzugeben, stehen die Anweisungen „Expires“ und „Cache-Control: max-age“ (bzw. „s-maxage“, dazu weiter unten) zur Verfügung. „Expires“ gibt einen Zeitpunkt an, bis zu dem die Ressource noch als „frisch“ gilt. Die Cache-Control-Anweisung „max-age“ spezifiziert dafür hingegen eine Zeitspanne in Sekunden (das ist die aktuellere, meist empfohlene Methode und hat auch für den Cache gegenüber „Expires“ Priorität).

Ändern wir dafür das genannte Beispiel leicht ab:

HTTP/1.1 200 OK
Last-Modified: Mon, 18 May 2020 10:01:22 GMT
Cache-Control: max-age=600
eTag: "x26e3"

Gibt es im Cache eine in Frage kommende Ressource, prüft der Client, ob sie noch verwendbar ist, genauer, ob zwischen seiner ursprünglichen Anfrage, auf die hin ihm die gecachte Ressource mit diesen Anweisungen geliefert wurde, und dem erneuten Laden mehr als 10 Minuten (600 Sekunden) vergangen sind. Ist das der Fall, darf er die gecachte Datei nicht mehr verwenden – sie ist abgelaufen. Die Ressource neu vom Server zu laden ist aber nur sinnvoll, wenn sie auch tatsächlich geändert wurde. Alles andere wäre Verschwendung.

Revalidierung

Deshalb fragt der Client beim Server lieber nach, ob eine neue Version vorliegt. Dafür muss er verschiedene Versionen einer Ressource unterscheiden können. Am sichersten erkennt der Client solche Versionen am Validierungstoken „eTag“, den der Server individuell für eine Ressource erzeugt und mitschickt (hier „x26e3“). Ist der nicht vorhanden, kann sich der Client ggf. auch an einem Zeitstempel (Last-Modified) orientieren. Zur Revalidierung schickt der Client eine „Conditional Get“-Anfrage mit diesem „Validator“ (eTag oder Zeitstempel) zurück an den Server. Wurde die Ressource nicht geändert (Server-Antwort mit Status 304 „not modified“), ist ein Download unnötig und die Ressource im Cache kann noch einmal verwendet werden.

Der Server kann auch explizit fordern, dass eine Ressource stets revalidiert wird. Dazu dienen die Cache-Control-Anweisungen „no-cache“, „must-revalidate“ und „proxy-revalidate“. Die letzten beiden sind für kritische Anwendungen bestimmt, zum Beispiel finanzielle Transaktionen, bei denen die Auslieferung abgelaufener Ressourcen unbedingt vermieden werden muss, auch wenn die Client-Konfiguration das erlauben würde.

The Big Picture – Caching durch Proxys

Serverbetreiber müssen allerdings beachten, dass aus Sicht des Servers „clientseitiges Caching“ mehr umfasst als den lokalen Cache des Besuchers. Zwischen Browser und Server können sich diverse Caches befinden, und zwar in Gestalt von Proxy-Servern etwa im Netzwerk des Besuchers, beim Internet-Provider oder als Bestandteil eines CDNs (Reverse Proxy). Die Anfrage des Besuchers durchläuft in der Regel alle diese Caches, und sobald einer davon sie ordnungsgemäß erfüllen kann, tut er das und liefert die angeforderte Ressource aus. So kann unter Umständen eine Anfrage auch beantwortet werden, wenn der Original-Server gar nicht erreichbar ist.

Die meisten Cache-Control-Anweisungen gelten gleichermaßen für Browser- und Proxy-Caches. Es gibt aber Ausnahmen: So gibt das oben erwähnte „s-maxage“ zwar ebenso wie „max-age“ die Ablaufzeitspanne einer Ressource an, gilt aber nur für Proxys. Das Gleiche gilt für „proxy-revalidate“. Die Anweisung „Cache-Control: private“ zeigt dagegen an, dass eine Ressource nur vom Browser zwischengespeichert werden darf, weil sie typischerweise für einen individuellen Benutzer bestimmt ist. Das folgende Beispiel bedeutet, dass nur Browser diese Ressource 10 Minuten zwischenspeichern dürfen (wie Sie sehen, können Cache-Control-Anweisungen auch kombiniert werden):

Cache-Control: private, max-age=600

❗ Übrigens: Proxys dürfen aus Sicherheitsgründen niemals zwischengespeicherte Antworten mit Autorisierungskopfzeilen ausliefern, es sei denn, das wird vom Server ausdrücklich erlaubt (per public-, must-revalidate- oder s-maxage-Anweisung).

Empfehlung: Caching-Control-Strategie entwickeln

Gerade bei Webseiten, die sich häufig ändern, kann es sich lohnen, etwas Zeit in die Entwicklung einer optimalen Caching-Strategie zu investieren. Wenn Sie so viel und so lange wie möglich zwischenspeichern und Ausnahmen klug definieren, stellen Sie sicher, dass Ihre Besucher stets die aktuelle Version Ihrer Seite zu Gesicht bekommen und trotzdem nicht zu lange darauf warten müssen. Auf der Google-Developers-Website gibt es dazu einen hilfreichen Artikel, der auch die folgende Grafik enthält:

Sie veranschaulicht für eine bestimmte Ressource das Vorgehen, um geeignete Cache-Control-Anweisungen zu finden. Dazu noch ein ergänzender Hinweis von uns: Sollten Sie eine kritische Anwendung betreiben, bei der das Ausliefern einer abgelaufenen Ressource zu Problemen führen kann, nutzen Sie beim Entscheidungsknoten „Revalidate each time“ besser „must-revalidate“. Wenn dann die Revalidierung fehlschlägt, zum Beispiel weil der Server nicht erreichbar ist, darf der Client die Anfrage nicht aus dem Cache bedienen, sondern soll anstelle der Ressource einen 504-Fehler (Gateway Timeout) anzeigen.

Weitere Informationen zum Thema und Code-Beispiele finden Sie im folgenden Artikel: So nutzt Du Browser Caching zur Beschleunigung Deiner Website