Was ist der Unterschied zwischen no-cache und no-store?

no-store bedeutet, dass die Antwort niemals in irgendeinen Cache geschrieben werden darf, sodass jede Anfrage zum Origin zurückgeht. no-cache erlaubt zwar das Speichern der Antwort, aber der Cache muss sie mit dem Origin revalidieren, bevor er sie erneut ausliefert. no-store geht darum, keine Kopie zu behalten; no-cache darum, eine behaltene Kopie stets zu prüfen.

Was bewirkt immutable in einem Cache-Control-Header?

immutable sagt dem Browser, dass sich die Ressource über die Lebensdauer ihres max-age nie ändert, sodass er die Revalidierung überspringen kann, selbst wenn der Nutzer neu lädt. Es ist für versionierte oder fingerprintete Dateien wie app.9f2c.js gedacht, bei denen ein neuer Build unter einer neuen URL ausgeliefert wird, statt die alte zu überschreiben.

Wie unterscheiden sich max-age und s-maxage?

max-age legt fest, wie lange die Antwort in jedem Cache frisch bleibt, einschließlich des Browsers. s-maxage überschreibt max-age, aber nur für Shared Caches wie CDNs und Proxys. Beide zu setzen erlaubt dir, eine Antwort kurz in Browsern zu cachen und länger auf deinem CDN zu halten.

Wann sollte ich public gegenüber private verwenden?

public erlaubt Shared Caches wie CDNs und Proxys, die Antwort zusammen mit dem Browser zu speichern. private beschränkt die Speicherung auf den Browser des einzelnen Nutzers, was die richtige Wahl für personalisierte oder authentifizierte Antworten ist, die nicht aus einem Shared Cache an einen anderen Nutzer ausgeliefert werden dürfen.

Was bewirkt stale-while-revalidate?

stale-while-revalidate erlaubt einem Cache, eine leicht veraltete Antwort sofort auszuliefern, während er im Hintergrund eine frische Kopie holt. Nutzer erhalten eine sofortige Antwort und der Cache aktualisiert sich für die nächste Anfrage selbst, was den Moment glättet, in dem eine Ressource abläuft.

Wird meine Konfiguration an einen Server gesendet?

Nein. Der Header, die Erklärung und die Snippets werden alle in deinem Browser zusammengesetzt, während du Optionen umschaltest, sodass die Konfiguration lokal auf deinem Gerät verarbeitet wird und nichts hochgeladen wird.

Cache-Control-Header-Generator

Baue direkt in deinem Browser aus einfachen Schaltern und menschlichen Zeiteinheiten einen korrekten HTTP-Cache-Control-Response-Header.

Dein Cache-Control-Header wird lokal in deinem Browser aus den gewählten Optionen zusammengesetzt, und nichts, was du konfigurierst, wird hochgeladen oder auf einem Server gespeichert.

Richtest du einen Server ein? Probiere den nginx Config Generator.

Über Cache-Control-Generator

Dieser Cache-Control-Header-Generator verwandelt die verwirrende Menge an HTTP-Caching-Direktiven in ein paar einfache Schalter. Setze public oder private, no-store, no-cache, must-revalidate, proxy-revalidate oder immutable, und lege Lebensdauern wie max-age, s-maxage, stale-while-revalidate und stale-if-error in menschlichen Einheiten wie Stunden, Tagen oder Jahren fest, statt Sekunden zu zählen. Während du die Optionen änderst, setzt das Tool die Direktiven in kanonischer Reihenfolge zusammen, erklärt in klarem Deutsch, was der aktuelle Header genau bewirkt, und markiert widersprüchliche Kombinationen wie no-store mit max-age. Presets decken die Alltagsfälle ab: ein statisches immutable-Asset mit einem Jahr, immer-revalidierendes HTML, nie-speichernde private Daten und eine geteilte CDN-gegen-Browser-Policy. Kopiere den Roh-Header oder fertige Snippets für nginx, Apache und HTML-meta. Alles läuft auf deinem Gerät, im Browser.

Funktionen

Schalter für public, private, no-store, no-cache, must-revalidate, proxy-revalidate und immutable
Menschliche Zeiteingaben (Sekunden bis Jahre) für max-age, s-maxage, stale-while-revalidate und stale-if-error
Setzt Direktiven während der Bearbeitung in sauberer kanonischer Reihenfolge zusammen
Klare Erklärung auf Deutsch, was der aktuelle Header genau bewirkt
Erzwingt Regeln zur gegenseitigen Ausschließung und warnt vor widersprüchlichen Kombinationen
Presets mit einem Klick für statische Assets, immer-revalidierendes HTML, private Daten und geteiltes CDN-/Browser-Caching
Kopierfertige Snippets für den Roh-Header, nginx add_header, Apache Header set und ein HTML-meta-Tag
Läuft vollständig in deinem Browser, sodass nichts, was du konfigurierst, dein Gerät verlässt

So verwendest du Cache-Control-Generator

Wähle ein Preset oder beginne von Grund auf und wähle public oder private.
Schalte die benötigten Direktiven um, etwa no-cache, must-revalidate oder immutable.
Gib Lebensdauern wie max-age über eine Zahl und eine Einheit (Stunden, Tage, Jahre) ein.
Lies den erzeugten Header-Wert und die Erklärung auf Deutsch darunter.
Kopiere den Roh-Header oder das nginx-, Apache- oder HTML-meta-Snippet, das du brauchst.

Beispiel

Eingabe

public + immutable + max-age = 1 year

Ausgabe

Cache-Control: public, max-age=31536000, immutable

Die klassische Policy für fingerprintete statische Assets: ein Jahr cachen und nie revalidieren.

Häufige Fehler & Fehlerbehebung

Du hast no-store gesetzt, aber auch max-age oder immutable hinzugefügt, und sie sind verschwunden. — no-store bedeutet, dass nie etwas gecacht wird, daher überschreibt es jede andere Direktive. Schalte no-store aus, wenn du tatsächlich eine gecachte, aber kontrollierte Antwort möchtest.
immutable scheint keine Wirkung zu haben. — immutable ist nur wichtig, solange eine Antwort noch frisch ist, kombiniere es daher mit einem max-age ungleich null. Ohne max-age gibt es kein Frische-Fenster, auf das es angewendet werden könnte.
s-maxage wird von deinem CDN ignoriert, wenn der Header private ist. — private verbietet Shared Caches, die Antwort überhaupt zu speichern, daher greift s-maxage, das nur Shared Caches betrifft, nie. Verwende public, wenn ein CDN sie cachen soll.
no-cache mit einem langen max-age verhält sich, als wäre nichts gecacht. — no-cache erzwingt vor jeder Wiederverwendung eine Revalidierung mit dem Origin, was die Frische, die max-age gewährt, praktisch aufhebt. Lass je nach Ziel eine der beiden weg.

Häufig gestellte Fragen

Was ist der Unterschied zwischen no-cache und no-store?: no-store bedeutet, dass die Antwort niemals in irgendeinen Cache geschrieben werden darf, sodass jede Anfrage zum Origin zurückgeht. no-cache erlaubt zwar das Speichern der Antwort, aber der Cache muss sie mit dem Origin revalidieren, bevor er sie erneut ausliefert. no-store geht darum, keine Kopie zu behalten; no-cache darum, eine behaltene Kopie stets zu prüfen.
Was bewirkt immutable in einem Cache-Control-Header?: immutable sagt dem Browser, dass sich die Ressource über die Lebensdauer ihres max-age nie ändert, sodass er die Revalidierung überspringen kann, selbst wenn der Nutzer neu lädt. Es ist für versionierte oder fingerprintete Dateien wie app.9f2c.js gedacht, bei denen ein neuer Build unter einer neuen URL ausgeliefert wird, statt die alte zu überschreiben.
Wie unterscheiden sich max-age und s-maxage?: max-age legt fest, wie lange die Antwort in jedem Cache frisch bleibt, einschließlich des Browsers. s-maxage überschreibt max-age, aber nur für Shared Caches wie CDNs und Proxys. Beide zu setzen erlaubt dir, eine Antwort kurz in Browsern zu cachen und länger auf deinem CDN zu halten.
Wann sollte ich public gegenüber private verwenden?: public erlaubt Shared Caches wie CDNs und Proxys, die Antwort zusammen mit dem Browser zu speichern. private beschränkt die Speicherung auf den Browser des einzelnen Nutzers, was die richtige Wahl für personalisierte oder authentifizierte Antworten ist, die nicht aus einem Shared Cache an einen anderen Nutzer ausgeliefert werden dürfen.
Was bewirkt stale-while-revalidate?: stale-while-revalidate erlaubt einem Cache, eine leicht veraltete Antwort sofort auszuliefern, während er im Hintergrund eine frische Kopie holt. Nutzer erhalten eine sofortige Antwort und der Cache aktualisiert sich für die nächste Anfrage selbst, was den Moment glättet, in dem eine Ressource abläuft.
Wird meine Konfiguration an einen Server gesendet?: Nein. Der Header, die Erklärung und die Snippets werden alle in deinem Browser zusammengesetzt, während du Optionen umschaltest, sodass die Konfiguration lokal auf deinem Gerät verarbeitet wird und nichts hochgeladen wird.