Cache-Control-Header: die einzige Anleitung, die Sie tatsächlich brauchen
Cache-Control entscheidet, was zwischengespeichert wird, von wem und wie lange. Es sieht kryptisch aus und ist meistens sechs Wörter, die Sie tatsächlich verwenden. Hier sind sie, plus die eine Unterscheidung, die alle kreuzt.
Das Cache-Control header beantwortet drei Fragen: kann dies zwischengespeichert werden, von wem, und für wie lange. Sechs Richtlinien decken fast jeden Fall ab — public, private, max-age, s-maxage, no-store und stale-while-revalidate. Cache hat ein Jahr lang Fingerabdrücke, gibt HTML ein kurzes Frischefenster mit abgestreifter Gültigkeit und hält echte persönliche Antworten aus gemeinsamen Caches heraus.
Cache-Control hat einen Ruf, zappelhaft zu sein, vor allem, weil die Spezifikation viele Richtlinien enthält, die niemand verwendet. Ziehen Sie es zurück zu denen, die ihren Platz verdienen und es ist einfach. Die Komplexität, die bleibt, ist jedoch real, und sie lebt in einer Unterscheidung, die fast alle fängt — so werden wir es früh schaffen.
Die Richtlinien, die wissenswert sind
| Richtlinie | Was es sagt | Wer gehorcht ihr? |
|---|---|---|
public | Jeder Cache kann diese speichern | Browser und CDNs |
private | Nur der eigene Browser des Benutzers kann es speichern | Nur Browser |
max-age=N | Frisch für N Sekunden | Alle |
s-maxage=N | Frisch für N Sekunden in gemeinsamen Caches, übergeordnetes Max-age | CDNs und Proxies |
no-store | Das nicht irgendwo lagern, überhaupt nicht | Alle |
no-cache | Bewahren Sie es auf, aber vor jeder Anwendung revalidieren | Alle |
must-revalidate | Einmal abgestreift, nie ohne Überprüfung dienen | Alle |
immutable | Das wird sich nie ändern; beim Nachladen nicht revalidieren | Browser |
stale-while-revalidate=N | Bis zu N-Sekunden ruhig servieren und hinter den Kulissen erfrischen | Hauptsächlich CDN |
stale-if-error=N | Dient für bis zu N Sekunden, wenn der Ursprung Fehler | Hauptsächlich CDN |
no-cache bedeutet nicht, nicht zwischenspeichern
Dies ist die am meisten irreführend benannte Direktive in HTTP und es lohnt sich, sich darüber klar zu sein. no-cache bedeutet "Sie können eine Kopie behalten, aber Sie müssen mit dem Ursprung vor der Verwendung überprüfen". Die Antwort ist immer noch gespeichert; sie kann einfach nicht ohne eine Verlängerungsanfrage bedient werden.
no-store ist derjenige, der bedeutet, nicht Cache. Wenn Sie eine Antwort wollen, die nie irgendwo auf Diskette geschrieben wird, dann ist das die Richtlinie, die Sie wollen.
Der praktische Unterschied ist wichtig: no-cache mit einem ETag ist ziemlich effizient, weil die Revalidierung meist einen 304 ohne Körper zurückgibt. no-store bedeutet, dass die volle Antwort jedes Mal übertragen wird.
Die eine Unterscheidung, die jeden reist: max-age vs s-maxage
Browser und CDNs sind beide Caches, aber Sie wollen selten, dass sie Inhalte für die gleiche Zeit halten.
Betrachten wir einen Artikel über Nachrichten. Sie möchten, dass Ihr CDN es für eine Stunde zwischenspeichert, damit Ihr Ursprung geschützt ist. Sie wollen nicht, dass der Browser eines Besuchers hält es für eine Stunde, denn wenn Sie einen Fehler korrigieren und reinigen Sie das CDN, dieser Besucher hat noch eine veraltete Kopie und keine Möglichkeit für Sie, es zu erreichen.
s-maxage löst dies, indem nur auf freigegebene Caches angewendet wird:
Cache-Control: public, max-age=60, s-maxage=3600Der Browser zwischenspeichert für eine Minute. Das CDN zwischenspeichert eine Stunde lang. Sie können das CDN säubern und sicher sein, dass jeder die Korrektur innerhalb von sechzig Sekunden bekommt, während Ihr Ursprung immer noch nur einmal pro Stunde die Seite bedient.
Dies ist die Form, die Sie für fast alle HTML wollen: Kurz im Browser, lang am Rand, bei Veränderung reinigen. Der Grund, warum es wichtig ist, ist, dass Sie ein CDN ungültig machen können und einen Browser nicht ungültig machen können.
stagle-while-revalidate, die unterschätzte
Normalerweise, wenn eine zwischengespeicherte Antwort abläuft, wartet der nächste Besucher, während der Cache eine neue Kopie abholt. Dieser Besucher zahlt die volle Ursprungslatenz, was eine leicht unfaire Art und Weise ist, die Kosten der Frische zu verteilen.
stale-while-revalidate ändert den Deal. Innerhalb des angegebenen Fensters nach Ablauf des Ablaufs dient der Cache der veralteten Kopie sofort und erfrischt sich im Hintergrund. Niemand wartet. Der nächste Besucher bekommt die neue Version.
Cache-Control: public, max-age=60, s-maxage=600, stale-while-revalidate=86400Seine Geschwister stale-if-error ist es wert hinzuzufügen, wo immer es tolerierbar ist: Wenn der Ursprung eine 5xx oder mal ausgibt, die veraltete Kopie anstatt eine Fehlermeldung-Seite dienen. Es ist die billigste Belastbarkeit, die Sie jemals konfigurieren werden — Ihre Website bleibt durch einen Ursprungsausfall aufrecht, weil die Kante immer diente, was sie hatte.
Rezepte
Fingerabdruckte statische Vermögenswerte — app.a1b2c3.js, styles.d4e5f6.css
public, max-age=31536000, immutable. Ein Jahr, und nie wieder bestätigt. Sicher, weil sich der Dateiname ändert, wenn der Inhalt sich ändert. immutable Außerdem stoppt Browser beim manuellen Nachladen.
Statische Dateien ohne Fingerabdruck — /logo.png
public, max-age=86400. Ein Tag, da Sie keine andere Möglichkeit haben, es außer Warten oder Umbenennen zu brechen.
HTML können Sie reinigen
public, max-age=60, s-maxage=86400, stale-while-revalidate=604800, stale-if-error=604800. Lange am Rand, kurz im Browser, purge on publizieren.
HTML kann man nicht reinigen
public, max-age=300, stale-while-revalidate=3600. Kürzer, da Ablauf Ihr einziger ungültiger Mechanismus ist.
API-Antworten, öffentliche Daten
public, max-age=0, s-maxage=60, stale-while-revalidate=300. Nie vertraut in den Browser, kurz zwischengespeichert am Rand — das absorbiert die Mehrheit der doppelten Anfragen.
Persönliche Seiten — Warenkorb, Konto, Dashboard
private, no-store. nicht no-cache. Nichts Persönliches sollte unter keinen Umständen in einem gemeinsamen Cache sitzen.
Eine Decke no-store überall angewendet "sicher sein" ist die häufigste Ursache für ein schlechtes Cache-Hit-Verhältnis. Es wird auch oft von Framework-Defaults angewendet, ohne dass jemand es wählt. Überprüfen Sie, was Ihre Anwendung tatsächlich sendet, bevor Sie Ihre Konfiguration annehmen, was in Kraft ist.
ETags und Verlängerung
Cache-Control entscheidet, wie lange etwas frisch ist. Wenn es aufhört, frisch zu sein, entscheiden Validatoren, ob es erneut heruntergeladen werden muss.
Eine ETag ist ein Fingerabdruck der Antwort. Bei der Verlängerung sendet der Client If-None-Match mit diesem Wert, und wenn sich nichts geändert hat, antwortet der Server 304 Not Modified ohne Körper. Last-Modified arbeitet ähnlich mit einem Zeitstempel und If-Modified-Since, mit einer Sekunde Genauigkeit.
Ein 304 kostet immer noch eine Rundreise, weshalb es kein Ersatz für eine anständige max-age — es spart Bandbreite, nicht Latenz. Schicken Sie trotzdem Validatoren, denn sie machen den teuren Fall viel billiger.
Prüfen Sie, was Sie tatsächlich senden
curl -sI https://example.com/ | grep -iE 'cache-control|etag|age|vary'Führen Sie es gegen Ihre Homepage, einen statischen Asset und einen API-Endpunkt aus. Das Age header sagt Ihnen, wie lange die Antwort in einem Cache gesessen hat, was eine schnelle Möglichkeit ist, zu bestätigen, dass das CDN tatsächlich Caching ist, anstatt einfach zu übertragen.
Häufig gestellte Fragen
Was macht Cache-Control?
Cache-Control ist ein HTTP Response Header, der Browser und freigegebene Caches wie CDNs anweist, ob eine Antwort gespeichert werden kann, wer sie speichern kann und wie lange sie frisch bleibt. Es ist der primäre Mechanismus zur Steuerung des Caching-Verhaltens und hat Vorrang vor dem älteren Expires Header.
Was ist der Unterschied zwischen No-Cache und No-Store?
no-cache erlaubt es, eine Antwort zu speichern, erfordert aber, dass der Cache vor dem Servieren mit dem Ursprung revalidiert, so dass eine unveränderte Antwort mit einer leichten 304 Antwort bestätigt werden kann. no-store verbietet die Speicherung der Antwort überall an, was bedeutet, dass der volle Körper auf jede Anfrage übertragen wird. Nur kein Laden verhindert tatsächlich das Caching.
Was ist der Unterschied zwischen max-age und s-maxage?
max-age gilt für alle Caches, einschließlich des Browsers des Besuchers. s-maxage gilt nur für freigegebene Caches wie CDNs und Proxies und überschreibt max-age für sie. Das übliche Muster ist eine kurze max-age mit einem viel längeren S-maxage, so dass das CDN schützt Ihren Ursprung, während Browser halten Inhalte nur kurz — wichtig, weil Sie ein CDN reinigen können, aber nicht reinigen einen Browser.
Was ist veraltet?
stale-wile-revalidate definiert ein Fenster, nachdem eine Antwort abläuft, während dessen ein Cache die abgespeicherte Kopie sofort bedienen kann, während er ein frisches im Hintergrund holt. Es entfernt die Latenzstrafe, die sonst auf den Besucher fällt, der zuerst nach Ablauf ankommt, so dass kein einzelner Benutzer auf den Ursprung wartet.
Wie lange sollte ich statische Assets verbergen?
Ein Jahr — max-age=31536000 — mit der unveränderlichen Direktive, vorausgesetzt, die Dateinamen enthalten einen Inhalt Hash wie app.a1b2c3.js. Da eine Änderung an der Datei einen neuen Dateinamen erzeugt, besteht kein Stillstandsrisiko. Dateien ohne Fingerabdruck im Namen sollten etwas kürzer, um einen Tag, da Umbenennung ist der einzige Weg, um sie zu entkräften.
Warum wird mein Inhalt nicht vom CDN zwischengespeichert?
Normalerweise, weil die Antwort enthält no-store, private oder max-age=0, oft durch eine Framework-Standard statt absichtlich hinzugefügt. Andere häufige Ursachen sind ein Set-Cookie-Header auf Antworten, die geteilt werden sollten, oder ein Vary-Header auf etwas mit unbegrenzten Werten wie User-Agent. Führen Sie curl -I gegen die URL und lesen Sie die Header, die Ihr Ursprung tatsächlich sendet.
Stellen Sie diese einmal pro Inhaltstyp ein und Sie werden selten wieder über den Header nachdenken, was genau das ist, wie eine gute Caching-Konfiguration sich anfühlen sollte.
Sehen Sie, wie NordicCDN dies für Ihre Website tut:
Mads hat seit seinem 16. Lebensjahr in der IT gearbeitet — hauptsächlich als Hosting. Er beteiligte sich früh an einer SaaS-Firma und half, sie bis zur Übernahme durch Visma weiterzuentwickeln, hat Data-Center-Netzwerke aufgebaut und betrieben und diente als CTO eines dänischen Rechenzentrums. Er hat NordicCDN gestartet, um eine schnelle, sichere Infrastruktur einfach zu bedienen.
