Ordnen Sie die Policy der Ressource zu, nicht dem Server
Erstellen Sie vor dem Ändern von Headern ein Inventar repräsentativer URLs: Startseite, Inhaltsseite, Application Shell, CSS, JavaScript, Bilder, Schriftarten, APIs, Login, Konto, Checkout und Downloads. Dokumentieren Sie für jede, ob die Antwort öffentlich oder personalisiert ist, ob sich die URL ändert, wenn sich die Bytes ändern, und wie schnell eine Korrektur die Besucher erreichen muss.
Erstellen Sie aus diesem Inventar eine Policy‑Matrix. Ein öffentliches, inhaltsadressiertes Asset benötigt eine andere Regel als HTML unter einer stabilen Adresse. Antworten ohne Cache-Control können weiterhin heuristisch zwischengespeichert werden, daher sind explizite Regeln einfacher zu testen.
Der Zeitraum, in dem eine gespeicherte Antwort wiederverwendet werden darf; max-age gibt ihn in Sekunden an.
Verwenden Sie Cache-Control‑Begriffe präzise
Cache-Control teilt Browsern und Shared‑Caches mit, wie eine Antwort gespeichert und wiederverwendet werden soll. max-age=N erlaubt die Wiederverwendung, solange die Antwort noch fresh ist. s-maxage=N setzt die Freshness für Shared‑Caches und überschreibt dort max-age, wird von Browsern aber ignoriert. public erlaubt jedes Cache; private erlaubt Browser‑Caching, verhindert aber die Speicherung in Shared‑Caches.
no-cache erlaubt Speicherung, erfordert jedoch vor der Wiederverwendung eine Validierung beim Origin. no-store bedeutet, dass Caches die Antwort nicht speichern dürfen, ist aber keine vollständige Datenschutzmaßnahme. Verwenden Sie must-revalidate, wenn das Ausliefern veralteter Inhalte nach Ablauf inakzeptabel ist; ein nicht erreichbarer Origin kann dann 504 statt veralteter Fallbacks liefern.
Es entfernt die Speicherung anstatt lediglich eine Prüfung zu verlangen; reservieren Sie es für Antworten, die wirklich nicht gespeichert werden dürfen.
Versionieren Sie unveränderliche Assets, bevor Sie lange Laufzeiten vergeben
Eine versionierte Asset‑URL enthält einen Inhalts‑Fingerprint oder Release‑Version, z. B. app.4f2c.js. Wenn sich die Asset‑Bytes ändern, veröffentlichen Sie eine andere URL und aktualisieren die HTML‑Referenz. Der Cache sieht eine neue Ressource, sodass Besucher das neue Asset laden, ohne dass eine Invalidierung jeden Browser erreichen muss.
Für eine Repräsentation, die während ihrer Freshness‑Lifetime nicht ändert, ist Cache-Control: max-age=31536000, immutable ein praktisches Muster. immutable weist unterstützende Clients an, während der Freshness‑Periode nicht bedingt zu revalidieren. Wenden Sie es oder eine einjährige max-age nicht auf eine mutable Datei mit gleicher URL an. Bewahren Sie frühere fingerprinted Assets solange auf, wie gecachte HTML noch auf sie verweisen kann.
HTML wählt Asset‑URLs, daher muss die Release‑Sequenz sicherstellen, dass die referenzierte Generation erhalten bleibt.
Machen Sie HTML durch Validierung aktuell, nicht durch langes Caching
HTML hat normalerweise eine stabile, benutzerorientierte URL und ändert sich mit Inhalten, Asset‑Referenzen, Feature‑Flags oder Sicherheitsmeldungen. Ein konservatives öffentliches HTML‑Pattern ist Cache-Control: no-cache mit ETag und Last-Modified, wenn Ihre Plattform diese korrekt erzeugen kann. Der Browser speichert den Body, verlangt aber vor der Wiederverwendung eine bedingte Anfrage; eine unveränderte Antwort kann dann 304 Not Modified ohne Body zurückgeben.
ETag identifiziert eine Ressourcen‑Version. Bei einer veralteten Antwort kann der Browser ihn in If-None-Match senden; stimmt er überein, antwortet der Server mit 304, andernfalls sendet er die neue Repräsentation. RFC‑Empfehlungen bevorzugen sowohl ETag als auch Last-Modified bei einer 200‑Antwort, wenn möglich. no-cache verspricht keine Validierung bei Back‑ oder Forward‑Navigation, weil ein Browser eine Session‑History‑Snapshot‑Wiederherstellung durchführen kann.
Ein ETag muss sich ändern, wenn sich die Repräsentation ändert; testen Sie ihn über Origins und Deployments hinweg.
Trennen Sie öffentliche Auslieferung von personalisierten und sensiblen Antworten
Ein Shared‑Cache, z. B. ein CDN, kann eine Antwort für mehrere Nutzer wiederverwenden. Lassen Sie nicht zu, dass kontospezifisches HTML oder API‑Daten über Nutzer hinweg wiederverwendet werden. Für personalisierte Inhalte, die im Browser verbleiben können, ist private, no-cache ein sinnvoller Ausgangspunkt: es verhindert Shared‑Speicherung und erzwingt Validierung. Ein Set-Cookie‑Header allein stoppt das Caching nicht.
Für Antworten, die nicht gespeichert werden dürfen, verwenden Sie no-store und prüfen Sie Anwendungs‑Code, CDN‑Regeln, Service Worker, Browser‑Speicher, Logs und Fehlerseiten. Header allein sind kein Datenschutz-, Compliance‑ oder Zahlungssicherheitsprogramm. Lassen Sie qualifizierte Security‑, Privacy‑ und Payment‑Reviewer sensible Flows und anwendbare Anforderungen bewerten.
Testen Sie Anmeldung, Abmeldung, Kontowechsel und Berechtigungsänderungen mit warmen Browser‑ und CDN‑Caches.
Führen Sie Cache‑Änderungen als umkehrbaren Release ein
Erfassen Sie Baseline‑Header und Body‑Verhalten für nicht gecachte und wiederholte Anfragen. Deployen Sie in Staging zuerst versionierte Assets, dann das HTML, das auf sie verweist, und testen Sie älteres gecachtes HTML gegen den neuen Origin. Prüfen Sie sowohl Direkt‑Origin‑ als auch CDN‑Pfade, falls beide existieren. DevTools Network‑Header sollten die beabsichtigte Policy und das Wiederholungsverhalten anzeigen.
Führen Sie ein Release‑Manifest mit Asset‑URLs, Header‑Regeln und Konfigurationsversion. Wenn ein Release inkompatible Client‑Dateien kombiniert, stellen Sie kompatibles HTML und Anwendungverhalten wieder her, überschreiben Sie jedoch keine veröffentlichte fingerprinted Datei. Zeigen Sie HTML auf die als bekannt‑gut identifizierte Generation und behalten Sie beide Generationen, solange gecachte HTML sie verlangen kann. Ein Shared‑Cache‑Purge kann Browser nicht zwingen, eine frische Antwort zu verwerfen.
Machen Sie Header‑Test‑Fehler, Asset‑404s und Versions‑Mismatch zu Punkten auf der Checkliste für das nächste Release.