{"id":13500,"date":"2026-10-13T12:45:00","date_gmt":"2026-10-13T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13500"},"modified":"2026-09-25T09:45:53","modified_gmt":"2026-09-25T07:45:53","slug":"cache-control-einfach-erklart-was-no-cache-no-store-max-age-und-s-maxage","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/web-entwicklung\/tutorials-de-web-entwicklung\/cache-control-einfach-erklart-was-no-cache-no-store-max-age-und-s-maxage\/","title":{"rendered":"Cache-Control einfach erkl\u00e4rt: Was no-cache, no-store, max-age und s-maxage jeweils bewirken"},"content":{"rendered":"

Eine Seite, die beim zweiten Besuch sofort da ist, wurde nicht noch einmal geholt, sondern kam aus einem Speicher irgendwo zwischen Server und Bildschirm – und ein Header hat das erlaubt.<\/p>\n

Diese Zeile hei\u00dft Cache-Control<\/code> – kurz, gebaut aus W\u00f6rtern, die selbsterkl\u00e4rend aussehen, und zwei davon bedeuten beinahe Gegens\u00e4tzliches, obwohl sie wie Synonyme klingen.<\/p>\n

\n\"Zwei
Eine Angabe steht in dem Band, f\u00fcr das sie gilt. Was in beiden steht, gilt f\u00fcr beide.<\/figcaption><\/figure>\n

Zwei Speicher, nicht einer<\/h2>\n

Zwischen Server und Bildschirm gibt es meist zwei Orte, an denen eine Antwort liegen bleiben kann.<\/p>\n

Der erste ist der Browser auf einem Ger\u00e4t. Was dort liegt, dient genau einer Person und bleibt, bis es abl\u00e4uft oder gel\u00f6scht wird.<\/p>\n

Der zweite ist ein gemeinsamer Speicher: ein CDN, ein Firmen-Proxy, irgendetwas im Weg, das viele Menschen aus einer Kopie bedient. Er ist der wirksamere von beiden, weil eine gespeicherte Kopie tausende Anfragen spart – und der gef\u00e4hrlichere, weil eine pers\u00f6nliche Seite, die dort landet, an die Falschen ausgegeben wird.<\/p>\n

Fast jedes Missverst\u00e4ndnis \u00fcbers Zwischenspeichern kommt daher, dass der zweite Speicher vergessen wird. Angaben, die sich zu widersprechen scheinen, sprechen meist verschiedene Speicher an.<\/p>\n

no-cache und no-store sind nicht zweimal dasselbe Wort<\/h2>\n

Die beiden sehen aus wie ein Paar und sind keins.<\/p>\n

no-store<\/code> hei\u00dft: nichts aufbewahren. Keine Kopie irgendwo, weder im Browser noch in einem gemeinsamen Speicher noch auf einer Platte. Jede Anfrage geht zum Server zur\u00fcck. Das ist die Angabe f\u00fcr einen Kontoauszug.<\/p>\n

no-cache<\/code> hei\u00dft: aufbewahren, aber vor der Verwendung nachfragen. Die Kopie wird ganz normal gespeichert; der Browser darf sie nur nicht ohne R\u00fcckfrage ausliefern. Antwortet der Server, dass sich nichts ge\u00e4ndert hat, wird die gespeicherte Kopie verwendet, und es flie\u00dft kein Inhalt.<\/p>\n

no-cache<\/code> bedeutet also nicht \u201enicht zwischenspeichern”. Es bedeutet \u201ezwischenspeichern, aber jedes Mal nachfragen” – und es gibt diese Angabe gerade deshalb, um Zwischenspeichern f\u00fcr Seiten m\u00f6glich zu machen, die sich unvorhersehbar \u00e4ndern. Eine kurze R\u00fcckfrage kostet einen Bruchteil einer vollen \u00dcbertragung.<\/p>\n

Wer no-store<\/code> schreibt und no-cache<\/code> meint, verschenkt diese Ersparnis bei jeder einzelnen Anfrage. Wer no-cache<\/code> schreibt und no-store<\/code> meint, hinterl\u00e4sst eine Kopie von etwas Vertraulichem auf einer Platte.<\/p>\n

Zwei Zahlen f\u00fcr zwei Speicher<\/h2>\n

max-age<\/code> ist die Lebensdauer in Sekunden. s-maxage<\/code> ist dasselbe, aber nur f\u00fcr gemeinsame Speicher, und dort sticht es max-age<\/code> aus.<\/p>\n

Die Startseite von Wikipedia zeigt, wozu es beide gibt. Der Header dort lautet s-maxage=86400, must-revalidate, max-age=3600<\/code>: das CDN darf die Seite einen ganzen Tag behalten, ein Browser eine Stunde. Der teure Speicher h\u00e4lt sie lange, der pers\u00f6nliche kurz – und eine Zeile regelt beides.<\/p>\n

Ohne s-maxage<\/code> folgt der gemeinsame Speicher schlicht dem max-age<\/code>. Das ist der Normalfall, und deshalb h\u00e4lt ein CDN eine Seite manchmal weit l\u00e4nger oder k\u00fcrzer als gedacht: f\u00fcr ihn wurde keine eigene Zahl geschrieben.<\/p>\n

must-revalidate<\/code> vervollst\u00e4ndigt das Bild. Ist die Lebensdauer abgelaufen, darf die gespeicherte Kopie nicht mehr verwendet werden, auch nicht kurz, auch nicht bei unerreichbarem Server. Ohne diese Angabe hat ein Speicher mit einer abgelaufenen Kopie einen gewissen Spielraum.<\/p>\n

\n\"Zwei
\n<\/figure>\n

Wer \u00fcberhaupt speichern darf<\/h2>\n

private<\/code> und public<\/code> beschreiben nicht den Inhalt, sondern benennen den Speicher.<\/p>\n

private<\/code> hei\u00dft: nur der Browser einer Person. Gemeinsame Speicher d\u00fcrfen diese Antwort nicht behalten. Das ist die richtige Einstellung f\u00fcr alles, was einen Namen, einen Warenkorb oder einen Kontostand zeigt – alles, was f\u00fcr einen einzelnen Besuch zusammengesetzt wurde.<\/p>\n

public<\/code> hei\u00dft: gemeinsame Speicher d\u00fcrfen ebenfalls behalten. Es hebt au\u00dferdem ein paar Regeln auf, die sonst gegen das Zwischenspeichern spr\u00e4chen, und steht deshalb auch auf Seiten, die ohnehin problemlos speicherbar w\u00e4ren.<\/p>\n

Der Fehler ist hier leise und ernst: eine pers\u00f6nliche Seite ohne private<\/code>, hinter einem CDN, wird einmal gespeichert und dem n\u00e4chsten Besuch samt fremdem Namen vorgesetzt. Nichts st\u00fcrzt ab, nichts wird protokolliert, und die Seite sieht richtig aus – f\u00fcr die falsche Person.<\/p>\n

Die veralteten Antworten, die mit Absicht ausgeliefert werden<\/h2>\n

Zwei Zus\u00e4tze erlauben einem Speicher, eine abgelaufene Kopie bewusst auszuliefern, und beide lassen Seiten schneller wirken, als sie sind.<\/p>\n

stale-while-revalidate<\/code> sagt: ist die Kopie gerade eben abgelaufen, gib sie trotzdem heraus und hol im Hintergrund eine frische. Der Besuch wartet auf nichts; der n\u00e4chste bekommt die neue Fassung.<\/p>\n

stale-if-error<\/code> sagt: ist der Server nicht erreichbar, liefere lieber die alte Kopie als eine Fehlerseite. Eine Seite mit dieser Angabe \u00fcbersteht einen kurzen Ausfall, ohne dass es jemand bemerkt.<\/p>\n

Die Startseite der BBC verwendet beides, mit 30 und 90 Sekunden. GitHub schickt dagegen max-age=0, private, must-revalidate<\/code> – nichts wird ohne R\u00fcckfrage ausgeliefert, denn eine Repository-Seite darf keine Sekunde veraltet sein.<\/p>\n

Keines von beidem ist richtiger. Es sind verschiedene Antworten auf dieselbe Frage: was ist hier schlimmer, eine langsame Seite oder eine alte.<\/p>\n

Was ein Header zeigt<\/h2>\n

Die Zeile kommt mit jeder Antwort mit, und sie zu lesen kostet eine Anfrage.<\/p>\n

Vier Fragen lohnen sich. Ist no-store<\/code> gemeint oder no-cache<\/code> – nichts behalten, oder behalten und nachfragen. Tr\u00e4gt eine pers\u00f6nliche Seite ein private<\/code>. Gibt es ein eigenes s-maxage<\/code> f\u00fcr den gemeinsamen Speicher, oder erledigt eine Zahl stillschweigend beide Aufgaben. Und ist die Lebensdauer plausibel daf\u00fcr, wie oft sich der Inhalt tats\u00e4chlich \u00e4ndert.<\/p>\n

Der HTTP-Security-Header-Pr\u00fcfer<\/a> liest die Header einer beliebigen Adresse so, wie ein Browser sie liest, und verfolgt dabei die Weiterleitungen.<\/p>\n

Die brauchbare Antwort ist ein Satz: ob diese Seite dort gespeichert wird, wo sie soll, und so lange, wie sie soll – und von niemandem sonst.<\/p>\n

\n

Fragen und Antworten<\/h2>\n

Warum spart no-cache nur dann \u00dcbertragung, wenn die Antwort einen ETag oder ein Last-Modified tr\u00e4gt?<\/h3>\n

Weil die R\u00fcckfrage einen Vergleichswert braucht. Der Browser schickt ihn als If-None-Match<\/code> oder If-Modified-Since<\/code> mit, und nur dann kann der Server mit 304 Not Modified antworten, ohne den Inhalt erneut zu senden. Fehlen beide Angaben, gibt es nichts zu vergleichen, und jede R\u00fcckfrage wird zu einer vollen \u00dcbertragung.<\/p>\n

Wie verschwindet eine veraltete Seite aus einem CDN, das sie mit s-maxage=86400 h\u00e4lt?<\/h3>\n

Nicht durch einen neuen Header. Die Kopien, die schon gespeichert sind, tragen ihre Lebensdauer mit sich; ein ge\u00e4nderter Header gilt erst f\u00fcr die n\u00e4chste Kopie. Beim CDN gibt es daf\u00fcr das Leeren des Caches \u00fcber dessen Verwaltung oder Schnittstelle, meist Purge genannt.<\/p>\n

Bei Browsern gibt es dieses Mittel nicht. Eine Kopie mit max-age=3600 bleibt dort bis zu eine Stunde, gleich was der Server inzwischen sendet. Das passt zur Aufteilung im Beispiel von Wikipedia: Der Speicher, den der Betreiber leeren kann, darf die Seite lange halten, der, den er nicht erreicht, nur kurz.<\/p>\n

F\u00fcr Skripte und Stylesheets ist der \u00fcbliche Weg ein anderer: eine neue Adresse je Fassung, etwa mit einer Versionsnummer oder Pr\u00fcfsumme im Dateinamen, und dazu eine lange Lebensdauer. Eine ge\u00e4nderte Datei hat dann eine neue Adresse, und keine alte Kopie steht im Weg.<\/p>\n

Welche Regel hebt public auf, und wann wird das heikel?<\/h3>\n

Die wichtigste betrifft Anfragen mit einem Authorization-Header, also etwa hinter einem Passwortschutz per HTTP-Anmeldung. Die Antwort auf eine solche Anfrage darf ein gemeinsamer Speicher nach RFC 9111 normalerweise nicht f\u00fcr weitere Anfragen verwenden, weil sie f\u00fcr eine angemeldete Person bestimmt ist. public erlaubt es ausdr\u00fccklich, ebenso s-maxage und must-revalidate.<\/p>\n

Heikel wird das, wenn eine Vorlage public f\u00fcr alle Seiten setzt und ein gesch\u00fctzter Bereich darunterf\u00e4llt: Das CDN darf die Antwort dann speichern und an Besuche ohne Anmeldung ausliefern. F\u00fcr gesch\u00fctzte Bereiche geh\u00f6rt private oder no-store in den Header, unabh\u00e4ngig davon, was die \u00fcbrige Seite sendet.<\/p>\n

Greift stale-if-error auch, wenn der Server zwar antwortet, aber mit einem Fehler?<\/h3>\n

Ja. Nach RFC 5861 z\u00e4hlen auch die Statuscodes 500, 502, 503 und 504 als Fehler, nicht nur ein unerreichbarer Server. Ob ein Speicher die Angabe \u00fcberhaupt beachtet, h\u00e4ngt allerdings vom CDN und vom Browser ab, und eine Fehlerseite mit Status 200 erkennt keiner von beiden als Fehler.<\/p>\n<\/div>\n

\n

Quellen<\/h2>\n