HTTP-Cache-Header Cache-Control, ETag und max-age ohne Vermutung

Jede HTTP-Antwort, die Sie senden, wird entweder im Cache gespeichert oder nicht – und wenn Sie nicht absichtlich handeln, entscheidet der Browser für Sie. Das Ergebnis ist normalerweise eine Mischung aus aggressiver Caching-Strategie für Dinge, die häufig wechseln, und keinem Caching für Dinge, die selten wechseln. Beides schadet Ihren Benutzern.

Dieser Leitfaden gibt Ihnen das mentale Modell, um HTTP-Cache-Header korrekt zu setzen: Was jede Richtlinie steuert, wie ETags die Wiedervalidierung auslösen und wie Sie TTLs wählen, die bei Bereitstellungen überleben, ohne veraltete Inhalte zu servieren.

Wie Browser-Caching tatsächlich funktioniert

Wenn ein Browser eine Ressource anfordert, prüft er zunächst seinen lokalen Cache. Wenn ein frischer, gespeicherter Kopf vorhanden ist, dient er sofort – ohne Netzwerkanfrage. Wenn der gespeicherte Kopf möglicherweise veraltet ist, sendet er eine bedingte Anfrage an die Quelle. Die Quelle bestätigt entweder, dass die Ressource nicht geändert wurde (304 Not Modified) oder sendet die vollständige aktualisierte Antwort (200 OK).

CDNs befinden sich in der Mitte dieses Lebenszyklus. Sie speichern Antworten näher an die Benutzer geografisch und befolgen die gleichen HTTP-Cache-Header – mit einigen CDN-spezifischen Erweiterungen wie s-maxage.

Drei Fragen bestimmen das Caching-Verhalten:

• Ist diese Antwort überhaupt cachbar? Steuerbar durch Cache-Control: no-store oder private
• Wie lange ist sie frisch? Steuerbar durch max-age oder s-maxage
• Wie wird die Veralterung validiert? Steuerbar durch ETags oder Last-Modified

Cache-Control-Header-Richtlinien

Der Cache-Control Der Header ist die primäre Methode, um eine Caching-Richtlinie zu deklarieren. Mehrere Richtlinien werden durch Komma getrennt. Hier ist, was jede einzelne tatsächlich macht:

max-age

max-age=N sagt den Caches (Browser und CDN) an, wie viele Sekunden die Antwort frisch bleibt. Eine Antwort mit max-age=86400 wird genau 24 Stunden nach dem Empfang als frisch angesehen. Danach muss der Cache vor dem Wiederverwenden eine Wiedervalidierung durchführen.

Für statische Assets mit versionierten Dateinamen (wie main.abc123.js) ist ein voller Jahr üblich: max-age=31536000. Für HTML-Dokumente ist ein viel kürzerer Zeitraum – oder gar kein Caching – sicherer, da HTML auf diese versionierten Assets verweist.

s-maxage

s-maxage ersetzt max-age für gemeinsame Caches (CDNs, Proxy-Server) nur. Der Browser ignoriert es. Dadurch können Sie Benutzern lange gespeicherte Antworten liefern, während der CDN-Edge frischer bleibt. Ein typisches Muster ist Cache-Control: public, max-age=3600, s-maxage=86400 — Browser-Cache für 1 Stunde, CDN-Cache für 24 Stunden.

no-cache

no-cache bedeutet nicht „kein Caching“. Es bedeutet, dass der Cache die Quelle wiedervalidieren muss, bevor er den gespeicherten Antwortinhalt bereitstellt, selbst wenn er noch frisch ist. Die Antwort wird gespeichert, aber jede Nutzung erfordert eine Runde um die Gültigkeit zu überprüfen. Dies ist angemessen für Inhalte, die häufig wechseln, aber von der Bandbreitenersparnis eines 304-Responses profitieren.

no-store

no-store ist die einzige Richtlinie, die das Caching tatsächlich verhindert. Kein Browser-Cache, kein CDN-Cache, keine Speicherung auf Festplatte. Verwenden Sie es für Antworten, die sensible Benutzerdaten enthalten – Bankauszüge, medizinische Aufzeichnungen, Tokens. Verwenden Sie es nicht als Standard, weil Sie noch nicht darüber nachgedacht haben, ob Caching überhaupt notwendig ist.

public und private

public erlaubt explizit gemeinsame Caches (CDNs) das Caching der Antwort, selbst wenn die Anfrage einen Authorization Header eingefügt wird. private beschränkt auf den Browser des Endbenutzers – CDNs dürfen es nicht speichern. Für authentizierte Antworten, die benutzerbezogen sind, private verhindert, dass eine Antwort eines Benutzers einem anderen dargestellt wird.

must-revalidate

must-revalidate verhindert, dass Caches veraltete Antworten servieren, wenn sie die Quelle nicht erreichen können. Ohne diese Richtlinie könnte ein Cache eine abgelaufene Antwort servieren, wenn das Netzwerk nicht verfügbar ist. Mit dieser Richtlinie wird die Anfrage mit einem 504-Fehler abgelehnt, wenn die Quelle nicht erreichbar ist. Verwenden Sie es für Inhalte, bei denen das Servieren veralteter Daten schlimmer ist als ein Fehler.

ETags: präzise Wiedervalidierung

Ein ETag ist eine von der Serverseite generierte Identifikation für eine bestimmte Version einer Ressource – denken Sie daran wie ein Fingerabdruck für den Antwortinhalt. Der Server sendet es in der Antwort:

ETag: "abc123def456"

Wenn der gespeicherte Kopf abgelaufen ist, sendet der Browser eine bedingte GET-Anfrage mit dem gespeicherten ETag:

If-None-Match: "abc123def456"

Wenn die Ressource nicht geändert wurde, antwortet der Server mit 304 Not Modified und einem leeren Körper – was Bandbreiten spart, während die Frische bestätigt wird. Wenn die Ressource geändert wurde, antwortet der Server mit 200 OK und dem neuen ETag.

Starke vs. schwache ETags

A starke ETag ("abc123") bedeutet, dass die Antwort byte-für-byte identisch ist. Ein schwache ETag (W/"abc123") bedeutet, dass die Antworten semantisch äquivalent sind, aber in trivialen Details wie Leerzeichen oder Header-Reihenfolge variieren können. Schwache ETags können effizienter generiert werden, können aber nicht in Range-Anfragen verwendet werden. Es sei denn, Sie haben einen speziellen Grund für schwache ETags, verwenden Sie starke ETags.

Last-Modified: die ältere Alternative

Bevor ETags verwendet wurden, benutzten Server Last-Modified Zeitstempel zur Wiedervalidierung. Der Server sendet:

Last-Modified: Thu, 01 May 2026 12:00:00 GMT

Der Browser validiert mit:

If-Modified-Since: Thu, 01 May 2026 12:00:00 GMT

Der Server antwortet mit 304, wenn die Ressource seit dem Zeitstempel nicht geändert wurde.

Die Schwäche: Zeitstempel haben eine Auflösung von einer Sekunde. Eine Datei, die innerhalb derselben Sekunde zweimal geändert wird, erscheint als unverändert. ETags behandeln dies korrekt und sind bevorzugt. Die meisten modernen Frameworks senden beide – der Browser verwendet das verfügbare, wobei ETags Vorrang haben.

Caching-Vermeidung ohne Bereitstellungsstörungen

Ein langer max-age auf einem statischen Asset ist nur sicher, wenn die URL beim Inhalt wechselt. Es gibt zwei Strategien:

URL-Fingerprinting (empfohlen)

Fügen Sie einen Hash des Dateiinhalts in den Dateinamen ein: main.a1b2c3d4.js. Wenn die Datei geändert wird, ändert sich der Hash, die URL ändert sich und der Browser holt die neue Datei – ohne den Cache zu berühren. Die alte URL bleibt im Cache, wird aber nie erneut angefordert, sobald die HTML-Datei die neue URL bezieht.

Webpack, Vite und die meisten modernen Bundlers tun dies automatisch. Das Muster ermöglicht es Ihnen, sicher Cache-Control: public, max-age=31536000, immutable – die immutable Richtlinie sagt dem Browser, dass er nicht einmal die Wiedervalidierung durchführen muss, selbst wenn der Cache-Eintrag technisch veraltet ist.

Query-Strings (weniger zuverlässig)

Fügen Sie eine Version als Query-String an die URL an (main.js?v=1.2.3). Technisch wird dadurch eine andere URL erzeugt, aber einige CDNs und Proxies ignorieren Query-Strings beim Erstellen von Cache-Schlüsseln. URL-Fingerprinting im Pfad ist zuverlässiger und universell unterstützt.

Gängige Fehler, die das Caching schädigen

Caching von API-Antworten, die nicht gekannt werden sollten

JSON-APIs, die benutzerbezogene oder zeitabhängige Daten liefern, sollten Cache-Control: no-store oder zumindest private, no-cacheverwenden. Ein häufiger Fehler ist, dass ein CDN eine Antwort wie /api/user/profile und eine Antwort eines Benutzers an einen anderen serviert. Wenn Ihre API kein Cache-Control Header setzt, werden einige CDNs sie trotzdem mit Heuristiken speichern.

Vary: Accept-Encoding zu vergessen

Wenn Ihr Server komprimierte und unkomprimierte Versionen einer Ressource je nach dem Accept-Encoding Header des Clients liefert, muss der Cache getrennte Kopien für jede Variante speichern. Ohne Vary: Accept-Encodingkann ein CDN die gzip-Version speichern und sie an einen Client liefern, der gzip nicht unterstützt – oder umgekehrt. Setzen Sie es immer ein, wenn die Kompression bedingt ist.

no-cache verwenden, wenn Sie „no-store“ meinen

Entwickler schreiben oft Cache-Control: no-cache wenn sie das vollständige Caching verhindern wollen, aber no-cache speichert die Antwort – es wird nur vor jeder Nutzung wiedervalidiert. Verwenden Sie no-store wenn Sie tatsächlich nicht wollen, dass die Antwort irgendwo gespeichert wird.

max-age auf HTML ohne Caching-Strategie setzen

HTML-Dokumente verweisen auf versionierte Assets. Wenn Sie Ihr HTML mit einem langen max-agecachen, werden Benutzer die neuen Asset-Dateinamen nach einer Bereitstellung nicht erkennen – sie laufen weiter mit dem alten HTML, das auf die alten Hashes verweist. Setzen Sie einen kurzen TTL (oder no-cache) auf HTML und reservieren Sie lange TTLs für die unveränderlichen Assets, auf die das HTML verweist.

Berechnen Sie Ihr Ablaufintervall vor der Bereitstellung

Die Wahl eines max-age Werts ist einfacher, wenn Sie sich vorstellen können, was es in Wahrzeit bedeutet. Der HTTP Cache TTL / max-age Rechner auf iotools.cloud ermöglicht es Ihnen, einen TTL in Sekunden einzugeben und das genaue Ablaufdatum zu sehen. Nützlich, um Werte wie 86400 (24 Stunden), 2592000 (30 Tage) oder 31536000 (1 Jahr) vor der Einbindung in Ihre Serverkonfiguration oder CDN-Regeln zu überprüfen.

Ein praktischer Caching-Checkliste

• HTML-Dokumente: Cache-Control: no-cache — immer wiedervalidieren, profitieren von 304-Responsen, wenn nichts geändert wurde
• Versionierte statische Assets (JS, CSS, Bilder mit Hash im Dateinamen): Cache-Control: public, max-age=31536000, immutable
• Unversionierte statische Assets (Schriftarten, Favicon): Cache-Control: public, max-age=604800 (1 Woche)
• API-Antworten (öffentlich, zeitabhängig): Cache-Control: public, max-age=60, s-maxage=300 — kurzer Browser-TTL, längerer CDN-TTL
• API-Antworten (benutzerbezogen): Cache-Control: private, no-cache
• Sensible Daten: Cache-Control: no-store
• Stets setzen Vary: Accept-Encoding bei der Bereitstellung komprimierter Antworten, die bedingt sind

ETags sollten standardmäßig für alles, was Sie cachen, aktiviert sein – sie sind das Mechanismus, der Bandbreiten-effiziente Wiedervalidierung ermöglicht. Die meisten Webserver (Nginx, Apache, Caddy) generieren ETags automatisch, es sei denn, Sie haben sie deaktiviert.

Das könnte Ihnen auch gefallen