Cache-Control

Cache-Control

Copyright © Shimazaki/Pexels

Was ist Cache-Control?

Cache-Control

Der Begriff Cache-Control beschreibt ein Header-Feld, das Einsatz findet, um Direktiven für Caching-Mechanismen zu beschreiben. Dies bezieht sich sowohl auf Requests (Anfragen) als auch auf Responses (Antworten). Die Caching-Direktiven sind dabei unidirektional. Eine Direktive in einem Request bedeutet nicht zwingend, dass diese Direktive in einem Response zurückkommt. Caching-Richtlinien lassen sich über Cache-Control-Header für jede Ressource definieren.

Überblick und Allgemeines zum Begriff

Die Cache-Control-Anweisung ermöglicht eine Festlegung, wer Antworten im Cache-Speicher ablegen kann. Ebenso ist die Cache-Control-Anweisung dafür ausschlaggebend, unter welchen Bedingungen und welchen Zeitraum dies geschieht. Der Cache-Control-HTTP-Header ermöglicht eine genaue Definition der Caching-Richtlinien für jede Ressource.

Definiert wurde dieser HTTP-Header im Zuge der Spezifikation HTTP/1.1. Er ersetzt vorherige Header wie etwa Expires. Diese bisherigen Header fanden Anwendung zur Festlegung der Caching-Richtlinien für Antworten (Responses). Da nahezu sämtliche aktuellen Browser die Cache-Control unterstützen, ist dieser Header hinreichend.

Im Idealfall sind Requests solche Anfragen, die keine Server-Kommunikation erforderlich machen. Mittels einer lokalen Kopie der Antwort ist es möglich, die Netzwerklatenz auszuschalten. Auf diese Weise lassen sich Gebühren, die ansonsten für die Datenübertragung anfallen, umgehen. Um dies zu realisieren, ermöglicht die HTTP-Spezifikation dem Server die Rücksendung einer bestimmten Anzahl von Cache-Control-Anweisungen. Diese regeln, auf welche Weise und für welche Zeitdauer einzelne Responses von Browsern (oder anderen Cache-Speichern) zwischengespeichert werden.

Direktiven

Da Cache-Control der Beschreibung von Direktiven für die Caching-Mechanismen dient, ist eine genaue Kenntnis der Direktive von Bedeutung. Die Direktiven berücksichtigen die Schreibweise (Groß- und Kleinschreibung) und verfügen über optionale Argumente. Diese verwenden beispielsweise Zeichenketten mit Anführungszeichen oder eine bestimmte Syntax. Handelt es sich um mehrere Direktiven, so werden diese durch Kommata getrennt.

Eine wichtige Direktive betrifft die Angabe, ob es sich um eine öffentliche oder private Antwort handelt. Um anzugeben, dass eine Antwort cachebar ist beziehungsweise zwischengespeichert werden kann, ist sie als öffentlich oder public zu kennzeichnen. Die Antwort kann in diesem Fall auch dann zwischengespeichert werden, wenn eine HTTP-Authentifizierung damit verbunden ist. Eine Kennzeichnung als öffentlich ist oft nicht erforderlich, denn andere Informationen wie etwa max-age geben bereits an, dass es sich um eine cachebare Antwort handelt.

Davon zu unterscheiden sind private Antworten. Diese lassen sich im Browser zwischenspeichern, sind jedoch in der Regel nur für einen bestimmten Anwender vorgesehen. Dafür dürfen sie nicht dazwischen in einem anderen Cache abgelegt werden. Somit lässt sich eine HTML-Seite, die private Informationen beinhaltet nur vom Browser des Anwenders zwischenspeichern und nicht von einem CDN.

Die Direktive no-cache veranlasst Caches dazu, die Anfrage an den ursprünglichen Server zu stellen. Auf diese Weise lässt sich die Gültigkeit validieren, bevor es zur Freigabe einer zwischengespeicherten Kopie kommt. Mit der Direktive only-if-cached lässt sich angeben, dass zunächst keine neuen Informationen abgerufen werden. Der Client nimmt keinen Kontakt zum ursprünglichen Server auf, um zu überprüfen, ob es eine neuere Kopie vorliegt. Stattdessen erhält er lediglich eine zwischengespeicherte Response.

Die Direktive der Bezeichnung max-age= definiert die maximale Zeitspanne, in der eine Response als aktuell eingestuft wird. Die Angabe erfolgt in Sekunden. Sie bedeutet in der Praxis den Zeitraum, innerhalb dessen die abgerufene Response wiederverwendet werden kann. Handelt es sich etwa um einen max-age=60, so gilt die Antwort 60 Sekunden lang als aktuell, darf zwischengespeichert und wiederverwendet werden. Diese Direktive verhält sich relativ zum Zeitpunkt der Requests und verhält sich damit anders als etwa Expires.

s-maxage= hat Bezug zu öffentlichen, geteilten Caches, die beispielsweise von Proxy-Servern stammten. Private Caches ignorieren diese Direktive. Ihre Aufgabe ist es, den max-age (oder den Expires-Header) zu überschreiben.

Der max-stale[=] zeigt an, dass ein Client eine Antwort auch dann akzeptiert, wenn diese bereits ihre Ablaufzeit überschritten kann. Hier haben Anwender auch die Möglichkeit, anzugeben, welche Zeit in Sekunden eine Antwort maximal abgelaufen sein darf, um noch akzeptiert zu werden.

Die Direktive min-fresh= zeigt an, dass Clients Antworten erwarten, die minimal noch für die hier in Sekunden angegebene Zeit aktuell ist.

Mittels stale-while-revalidate= lässt sich angeben, dass Clients dann bereit sind, eine bereits abgelaufene Antwort noch zu akzeptieren, wenn im Hintergrund noch eine Prüfung auf eine Aktualisierung erfolgt. Mit dem zweiten Wert wird angegeben, wie lange der Client diese abgelaufene Antwort noch zu akzeptieren bereit ist.

Die Direktive must-revalidate sieht vor, dass der Cache den Status einer abgelaufenen Antwort überprüfen muss, bevor diese Verwendung finden kann. Hierbei sollten keine abgelaufenen Ressourcen angewandt werden.

Ähnlich funktioniert proxy-revalidate, jedoch bezieht sich dies auf öffentliche, geteilte Caches, beispielsweise Proxy-Server. Private Caches ignorieren diese Direktive.

Mit immutable lässt sich angeben, dass es zu keiner Änderung des Response-Körpers im Verlaufe der Zeit kommt. Handelt es sich um eine nicht abgelaufene Ressource, so liegt sie auf dem Server in unveränderter Form vor. Daher sollten Clients keine bedingte Revalidierung zur Überprüfung auf Aktualisierung schicken, beispielsweise in Form von If-None-Match. Dies gilt auch, wenn Anwender die Seite nicht explizit aktualisieren. In manchen Browsern wie Firefox wird die Direktive immutable nur im Falle von Transaktionen mit https:// berücksichtigt.

Mit no-cache lässt sich angeben, dass sich eine zurückgesendete Response nicht ohne Weiteres zur Beantwortung eines anschließenden Requests an die gleiche URL einsetzen lässt. Voraussetzung ist eine Nachfrage beim Server, ob es zu einer Änderung der Antwort kam. Handelt es sich um ein ordnungsgemäßes Validierungs-Token, so führt no-cache einen Umlauf zur Validierung der gecachten Antwort durch. Hat sich an der Ressource nichts geändert, so wird der Download vermieden.

No-store untersagt den Browsern sowie den zwischengeschalteten Cache-Speichern die Speicherung irgendeiner Version der zurückgesendeten Response. Bei jeder Anforderung einer Ressource durch einen Anwender kommt es daher zu einer neuen Anfrage an den Server. In jedem Falle kommt es dann zum Download einer vollständigen Antwort.

Mittels no-transform wird verhindert, dass eine Konvertierung oder Transformation einer Ressource ausgeführt wird. Verschiedene Header wie Content-Range oder Content-Encoding erfahren hierbei keine Veränderung durch einen Proxy-Server. Proxy-Server könnten etwa Konvertierungen zwischen unterschiedlichen Formaten (beispielsweise Bilddateien) vornehmen. Dies dient der Einsparung des Datenverkehrs zur Beschleunigung der Verbindung oder einer Ersparnis von Speicherplatz. No-transform unterbindet diese Aktivitäten.

Cache-Control und seine Richtlinien

Eine Herausforderung besteht für Anwender darin, die für sie bestmögliche Caching-Direktiven für bestimmte Ressourcen zu bestimmen. Empfehlenswert ist es, möglichst viele Antworten über einen maximalen Zeitraum auf einem Client zwischenzuspeichern. Für eine gelingende Revalidierung ist es vorteilhaft, Validierungs-Token für jede Response anzugeben.

Auf den beliebtesten Internetseiten lassen sich die Hälfte der heruntergeladenen Responses im Browser zwischenspeichern. Dies geht insbesondere bei wiederholtem Aufruf mit deutlicher Ressourcen-Ersparnis einher. Wie viel sich de facto zwischenspeichern lässt, hängt von der jeweiligen Webseite ab. Manche ermöglichen Einsparungen von 80 Prozent, während andere aufgrund zahlreicher privater Daten kaum Möglichkeiten für den Cache-Speicher bieten.


Sie haben noch Fragen?

Kontaktieren Sie uns

Kostenloser SEO-Check der OSG


Weitere Inhalte