Cache-Control
Verwendung
Ursprungsserver, Zwischenstationen und Clients verlassen sich alle auf Cache-Control, um sich darüber zu verständigen, wann eine gespeicherte Antwort weiterhin verwendbar ist und wann eine frische Kopie benötigt wird. Eine einzelne Antwort kombiniert häufig mehrere Direktiven, um eine vollständige Cache-Richtlinie auszudrücken: wie lange gespeichert werden darf, wer speichern darf und was nach Ablauf der Frische zu tun ist.
Die folgende Tabelle zeigt, welche Direktiven für Anfragen, für Antworten oder für beide gelten.
Mehrere Direktiven werden in einem einzelnen Header-Wert durch Kommas getrennt oder auf mehrere Cache-Control-Header aufgeteilt. Treten widersprüchliche Direktiven auf, gilt die restriktivste Kombination.
Hinweis
Nicht erkannte Direktiven werden von Caches ignoriert. Dadurch lassen sich neue Direktiven einführen, ohne ältere Implementierungen zu beeinträchtigen.
Hinweis
Fehlt der Cache-Control-Header, wenden Caches eine heuristische Frische an. Eine verbreitete Heuristik sind 10 % der seit Last-Modified vergangenen Zeit. Das bedeutet, dass Antworten ohne Cache-Control von Browsern und CDNs zwischengespeichert werden. Ein explizit gesetztes Cache-Control verhindert unerwartetes Cache-Verhalten.
Hinweis
Cache-Control regelt, wann neu validiert wird (Frische-Lebensdauer). ETag regelt, wie neu validiert wird (Identität des Inhalts). Beide wirken zusammen: Cache-Control bestimmt, ob eine Neuvalidierung nötig ist, ETag bestimmt, ob sich der Inhalt geändert hat. Der Pragma-Header ist das HTTP/1.0-Äquivalent zu Cache-Control: no-cache und gilt praktisch als veraltet.
max-age
Die Direktive max-age weist Caches an, eine gespeicherte Antwort nur dann zurückzugeben, wenn die Antwort nicht älter als die angegebene Anzahl an Sekunden ist. Ungültige Werte wie negative Zahlen werden als 0 behandelt.
Cache-Control: max-age=<seconds>max-age=0 erzwingt eine Ende-zu-Ende-Neuvalidierung. Dieses Muster stammt aus HTTP/1.0-Implementierungen, denen die Unterstützung für no-cache fehlte.
max-stale
Die Direktive max-stale signalisiert, dass eine Antwort akzeptiert wird, deren Age die Frische-Lebensdauer um bis zu die angegebene Anzahl an Sekunden überschreitet. Das Toleranzfenster beginnt, sobald max-age abgelaufen ist.
Cache-Control: max-stale=<seconds>Diese Direktive ist nützlich, wenn ein Ursprungsserver vorübergehend nicht erreichbar ist und eine leicht veraltete Antwort akzeptabel ist.
min-fresh
Die Direktive min-fresh fordert eine gespeicherte Antwort an, deren verbleibende Frische-Lebensdauer mindestens der angegebenen Anzahl an Sekunden entspricht. Der Cache gibt die gespeicherte Kopie nur zurück, wenn die Antwort für diesen zusätzlichen Zeitraum frisch bleibt.
Cache-Control: min-fresh=<seconds>no-cache
Eine Anfrage mit no-cache verlangt, dass der Cache die gespeicherte Antwort beim Ursprungsserver validiert, bevor er die Kopie ausliefert. Das erzwingt eine Neuvalidierung, ohne den gespeicherten Eintrag zu verwerfen.
Cache-Control: no-cacheHinweis
Um zu verhindern, dass ein Cache eine Antwort überhaupt speichert, verwenden Sie stattdessen no-store.
no-store
Die Direktive no-store fordert Caches auf, weder die Anfrage noch die zugehörige Antwort zu speichern.
Cache-Control: no-storeno-transform
Die Direktive no-transform verbietet Zwischenstationen, den Antwort-Body zu verändern, etwa Bilder neu zu komprimieren oder Medienformate zu konvertieren. Die Einschränkung gilt unabhängig davon, ob die Zwischenstation ein Caching-Proxy oder ein weiterleitendes Gateway ist.
Cache-Control: no-transformonly-if-cached
Die Direktive only-if-cached weist den Cache an, eine gespeicherte Antwort zurückzugeben, ohne den Ursprungsserver zu kontaktieren. Existiert keine passende gespeicherte Antwort, gibt der Cache den Status 504 zurück.
Cache-Control: only-if-cachedmax-age
Die Direktive max-age gibt an, wie viele Sekunden die Antwort nach ihrer Erzeugung frisch bleibt. Die Zeitmessung beginnt in dem Moment, in dem der Ursprungsserver die Antwort erstellt, sodass Übertragungszeit und die in Zwischen-Caches verbrachte Zeit auf dieses Budget angerechnet werden.
Cache-Control: max-age=<seconds>Eine Antwort mit max-age=3600 bleibt eine Stunde lang frisch. Nach Ablauf der Stunde behandeln Caches die Antwort als veraltet und validieren sie je nach den vorhandenen weiteren Direktiven entweder neu oder holen eine neue Kopie.
s-maxage
Die Direktive s-maxage (shared max-age) überschreibt max-age für gemeinsam genutzte Caches wie CDNs und Proxyserver. Private Browser-Caches ignorieren s-maxage und greifen auf max-age zurück.
Cache-Control: s-maxage=<seconds>no-cache
Die Direktive no-cache in der Antwort verlangt, dass Caches die gespeicherte Antwort vor jeder Wiederverwendung beim Ursprungsserver neu validieren. Der Cache speichert die Antwort dennoch und ermöglicht so bedingte Anfragen mit ETag oder Last-Modified.
Cache-Control: no-cacheEnthält no-cache eine Liste von Feldnamen, erfordern nur diese bestimmten Header eine Neuvalidierung. Der übrige Teil der gespeicherten Antwort wird ausgeliefert, ohne den Ursprungsserver zu kontaktieren.
Cache-Control: no-cache="Set-Cookie"Hinweis
Um die Speicherung vollständig zu verhindern, verwenden Sie no-store.
no-store
Die Direktive no-store verhindert, dass irgendein Cache die Antwort speichert. Jede nachfolgende Anfrage geht an den Ursprungsserver.
Cache-Control: no-storeHinweis
no-cache erlaubt die Speicherung, verlangt aber vor jeder Verwendung eine Neuvalidierung. Der Cache prüft per If-None-Match oder If-Modified-Since beim Ursprungsserver nach und erhält ein 304, wenn der Inhalt unverändert ist. no-store verhindert die Speicherung vollständig, sodass keine Kopie aufbewahrt wird und jede Anfrage die vollständige Antwort abruft. Ein häufiger Fehler besteht darin, no-cache zu verwenden, wenn für sensible Daten wie Bank- oder medizinische Unterlagen eigentlich no-store gemeint ist. no-cache ist effizient für häufig aktualisierte Inhalte. no-store ist für Inhalte gedacht, die niemals auf der Festplatte verbleiben dürfen.
no-transform
Die Direktive no-transform in der Antwort verhindert, dass Zwischenstationen den Antwort-Body vor dem Weiterleiten verändern, unabhängig davon, ob die Zwischenstation den Inhalt zwischenspeichert oder nicht.
Cache-Control: no-transformmust-revalidate
Die Direktive must-revalidate erlaubt Caches, die Antwort auszuliefern, solange sie frisch ist. Sobald sie veraltet ist, kontaktiert der Cache den Ursprungsserver zur Neuvalidierung, bevor er die Antwort erneut ausliefert. Ist der Ursprungsserver nicht erreichbar, gibt der Cache ein 504 zurück, statt veraltete Inhalte auszuliefern.
Cache-Control: must-revalidateproxy-revalidate
Die Direktive proxy-revalidate wirkt genauso wie must-revalidate, nur dass die Anforderung ausschließlich für gemeinsam genutzte Caches gilt. Private Browser-Caches sind nicht betroffen.
Cache-Control: proxy-revalidatemust-understand
Die Direktive must-understand weist einen Cache an, die Antwort nur dann zu speichern, wenn er den Statuscode kennt und die zugehörigen Cache-Anforderungen versteht.
Cache-Control: must-understand, no-storeDie Kombination von must-understand mit no-store bietet einen Rückfallweg: Caches ohne Unterstützung für must-understand ignorieren die unbekannte Direktive und befolgen stattdessen no-store.
private
Die Direktive private beschränkt die Speicherung auf private Caches, typischerweise den Browser des Endnutzers. Gemeinsam genutzte Caches wie CDNs und Proxyserver verwerfen die Antwort.
Cache-Control: privatepublic
Die Direktive public kennzeichnet eine Antwort als für die Speicherung in gemeinsam genutzten Caches geeignet. Antworten, die einen Authorization-Header tragen, werden von gemeinsam genutzten Caches nur gespeichert, wenn die Direktive public vorhanden ist.
Cache-Control: publicHinweis
Die Direktive public ist überflüssig, wenn must-revalidate oder s-maxage bereits vorhanden ist.
immutable
Die Direktive immutable garantiert, dass sich der Antwort-Body während der Frische-Lebensdauer nicht ändert. Caches überspringen bedingte Anfragen für unveränderliche Ressourcen und vermeiden so Neuvalidierungs-Roundtrips für Assets wie versionierte JavaScript-Bundles oder Bilder mit Fingerprint im Dateinamen.
Cache-Control: public, max-age=31536000, immutablestale-while-revalidate
Die Direktive stale-while-revalidate verlängert das Zeitfenster, in dem eine veraltete Antwort nutzbar bleibt. Nach Ablauf der Frische liefern Caches die veraltete Kopie aus, während sie im Hintergrund neu validieren. Der Parameter legt fest, wie viele zusätzliche Sekunden lang die veraltete Antwort akzeptabel bleibt.
Cache-Control: max-age=600, stale-while-revalidate=30Sobald die Neuvalidierung im Hintergrund abgeschlossen ist, ersetzt der Cache den veralteten Eintrag durch die frische Antwort. Dieses Muster verbirgt die Latenz der Neuvalidierung vor den Endnutzern.
stale-if-error
Die Direktive stale-if-error erlaubt Caches, eine veraltete Antwort auszuliefern, wenn der Ursprungsserver einen Fehlerstatus zurückgibt (500, 502, 503 oder 504) oder nicht erreichbar ist. Der Parameter legt fest, wie viele Sekunden über die Frische-Lebensdauer hinaus die veraltete Antwort als Rückfalllösung nutzbar bleibt.
Cache-Control: max-age=600, stale-if-error=86400Beispiel
Ein statisches Asset, das mit langer Frische-Lebensdauer und dem Flag immutable ausgeliefert wird. Der Browser und jeder gemeinsam genutzte Cache speichern diese Antwort ein Jahr lang ohne Neuvalidierung.
Cache-Control: public, max-age=31536000, immutableEine API-Antwort, die ausschließlich für den anfragenden Browser bestimmt ist. Der Cache speichert die Antwort fünf Minuten und validiert sie nach Ablauf der Frische vor der Wiederverwendung neu.
Cache-Control: private, max-age=300, must-revalidateEine auf CDNs ausgerichtete Richtlinie, die dem gemeinsam genutzten Cache ein Fenster von zehn Minuten einräumt, während der Browser-Cache eine Minute erhält. Veraltete Antworten werden bis zu 30 Sekunden lang ausgeliefert, während das CDN im Hintergrund neu validiert.
Cache-Control: s-maxage=600, max-age=60, stale-while-revalidate=30Googlebot und max-age
Googles Crawling-Infrastruktur setzt heuristisches HTTP-Caching um. Die Direktive max-age hilft Googlebot, die Frequenz des erneuten Crawlens zu bestimmen. Eine Seite mit langem max-age wird seltener erneut abgerufen, während no-cache auf häufige Inhaltsänderungen hinweist und häufigeres Crawling rechtfertigt. Antworten ohne jegliche Cache-Header sind bei bestimmten Statuscodes standardmäßig heuristisch zwischenspeicherbar; Ursprungsserver, die das Caching vollständig unterbinden wollen, müssen daher explizit no-store senden. Bingbot sendet Cache-Control: no-cache in Anfragen und verlässt sich für die Crawl-Geschwindigkeit auf crawl-delay in der robots.txt sowie auf IndexNow.
Hinweis
Für Unterstützung bei SEO und Caching wenden Sie sich an die ehemaligen Google-SEO-Berater Search Brothers.
Fehlersuche
Unerwartetes Cache-Verhalten entsteht durch Missverständnisse zu Direktiven, CDN-Überschreibungen oder widersprüchliche Header.
Trotz der Direktive no-cache werden veraltete Inhalte ausgeliefert. Die Direktive no-cache verhindert nicht die Speicherung. Caches speichern die Antwort und validieren sie bei jeder Wiederverwendung neu. Um die Speicherung vollständig zu verhindern, verwenden Sie no-store. Kombinieren Sie beide, wenn sensible Daten im Spiel sind: Cache-Control: no-cache, no-store.
Das CDN ignoriert Cache-Control-Direktiven. Viele CDNs überschreiben das Cache-Control des Ursprungsservers mit eigenen Richtlinien. Cloudflare respektiert standardmäßig die Header des Ursprungsservers, überschreibt sie aber, sobald eine Page Rule oder Cache Rule aktiv ist. AWS CloudFront verwendet den Header des Ursprungsservers, sofern keine Cache-Richtlinie mit eigenen TTLs angehängt ist. Prüfen Sie das CDN-Dashboard auf Überschreibungsregeln, bevor Sie die Konfiguration des Ursprungsservers debuggen.
Veraltete Inhalte bleiben nach dem Senken von max-age bestehen. CDN-Edge-Knoten und Browser-Caches behalten Antworten, bis das ursprüngliche max-age abgelaufen ist. Den Wert am Ursprungsserver zu senken, entfernt bereits zwischengespeicherte Kopien nicht. Führen Sie nach einer Änderung der Cache-Lebensdauern eine CDN-Bereinigung durch. In Cloudflare löschen Sie nach URL oder verwenden eine vollständige Zonen-Bereinigung. In CloudFront erstellen Sie eine Invalidierung für die betroffenen Pfade.
Der Browser zeigt trotz no-store bei Vorwärts-/Rückwärtsnavigation die alte Seite. Der Vorwärts-/Rückwärts-Cache (bfcache) in Chrome, Firefox und Safari stellt den vollständigen Seitenzustand aus dem Arbeitsspeicher wieder her und umgeht dabei no-store. Dieses Verhalten ist beabsichtigt und stellt keine Cache-Verletzung dar. Prüfen Sie den Cache-Control-Header im Network-Tab der DevTools bei deaktivierter Option “Disable cache”, um zu bestätigen, dass der Header den Browser erreicht. Das Hinzufügen von unload-Event-Listenern deaktiviert den bfcache in einigen Browsern, verschlechtert aber die Performance.
Der Expires-Header steht im Konflikt mit Cache-Control. Sind beide Header vorhanden, hat Cache-Control: max-age Vorrang vor Expires. Entfernen Sie den Expires-Header, um Verwirrung zu vermeiden. In nginx:
expires off;
add_header Cache-Control "max-age=3600";In Apache:
Header unset Expires
Header set Cache-Control "max-age=3600"Cache-Header mit curl und DevTools diagnostizieren. Führen Sie curl -I https://example.re aus, um die Antwort-Header des Ursprungsservers zu untersuchen. Fügen Sie -H “Cache-Control: no-cache” hinzu, um CDN-Caches zu umgehen und den Ursprungsserver direkt anzusprechen. Öffnen Sie in den Browser-DevTools den Network-Tab, wählen Sie die Anfrage aus und sehen Sie sich den Abschnitt Response Headers an. Achten Sie auf die Header Age, X-Cache und CF-Cache-Status, um festzustellen, ob die Antwort von einem CDN-Edge-Knoten oder vom Ursprungsserver kam.