Cache-Control: weniger Anfragen, schnellere Seiten

Jedes Mal, wenn ein Browser Ihre Seite lädt, braucht er Ihre Bilder, Stylesheets und Skripte. Sagen Sie ihm nichts, entscheidet er selbst, wie lange er jeder Datei vertraut – und fragt häufig beim Server nach, was in Ihren Logs einen Strom von 304 Not Modified-Antworten erzeugt. Jede dieser Rückfragen ist ein Umweg, auf den Ihr Besucher wartet, und Arbeit für Ihren Server – selbst wenn sich nichts geändert hat. Cache-Control löst das: Der Header sagt Browsern, wie lange sie eine Datei wiederverwenden dürfen, ohne erneut zu fragen.

So funktioniert Caching

Fordert ein Browser eine Datei an, die er noch nicht im Cache hat, lädt er sie herunter. Bei späteren Besuchen schickt er ohne Caching-Regeln oft eine bedingte Anfrage: „Hat sich das geändert?“ Trägt die Antwort einen brauchbaren Validator – einen ETag- oder Last-Modified-Header –, kann der Server mit 304 Not Modified antworten: keine neuen Daten, aber trotzdem ein Hin und Zurück. (Ohne Validator muss er die ganze Datei erneut senden.) Mit Cache-Control überspringen Sie diesen Umweg komplett für Dateien, die ihn nicht brauchen:

Cache-Control: public, max-age=604800

max-age wird in Sekunden angegeben (604800 = 7 Tage). Solange die Kopie im Cache frisch ist und noch dort liegt, verwendet der Browser sie normalerweise wieder, ohne den Server überhaupt zu kontaktieren. Cache-Control hat den älteren Expires-Header weitgehend abgelöst; beide funktionieren aber noch.

no-cache, no-store und private – drei verschiedene Dinge

Diese drei Anweisungen verwechselt man leicht, und die Namen führen in die Irre:

• no-cache heißt nicht „nicht cachen“. Es heißt: Ein Cache darf die Antwort speichern, muss sie aber vor der Wiederverwendung beim Server revalidieren – eine Anweisung im Sinn von „erst nachfragen, dann der Kopie trauen“. Ein nützlicher Standard für HTML, das vor der Wiederverwendung geprüft werden muss; kombinieren Sie ihn mit einem Validator, damit die Antwort ein günstiger 304 sein kann. (Stabiles, öffentliches HTML kann stattdessen eine kurze Frischedauer bekommen.)
• no-store weist regelkonforme HTTP-Caches an, die Antwort gar nicht für später aufzuheben. Nutzen Sie es für wirklich sensible Antworten (eine Seite mit Bankdaten) – zusätzlich zu sauberen Zugriffskontrollen, denn es verhindert weder Screenshots noch Downloads, noch dass ein nicht regelkonformer Zwischenspeicher doch eine Kopie behält.
• private heißt: Regelkonforme geteilte Caches – ein CDN, ein Proxy – dürfen die Antwort nicht speichern; nur der Browser des Besuchers selbst darf das. Nutzen Sie es für personalisierte Inhalte wie ein Dashboard nach dem Login. Die Anwendung muss die Zugriffskontrolle trotzdem selbst durchsetzen und Cache-Einträge pro Nutzer getrennt halten: private repariert keine Edge-Regel, die das Falsche zwischenspeichert.

Für die meisten statischen Assets wollen Sie das Gegenteil: public mit langem max-age – wobei public dann sicher ist, wenn die Antwort für jeden Besucher identisch ist.

Empfohlene Einstellungen

• Statische Assets, deren URL sich mit dem Inhalt ändert (versionierte CSS-, JS-, Bild- und Schriftdateien): aggressiv cachen.
• Assets unter wiederverwendbaren, unversionierten URLs: eine Laufzeit, kurz genug für die Veralterung, die Sie hinnehmen können.
• HTML: revalidieren oder kurz cachen; strenger (private, no-store), wo es personalisiert oder sensibel ist.

Unter Apache setzen Sie die Header mit mod_headers in der .htaccess (sofern Ihr Hoster diese Direktiven dort erlaubt – mod_expires ist ein separates, weiterhin aktuelles Modul, das stattdessen Ablaufzeiten verwaltet):

<IfModule mod_headers.c>
  # Use only when every matching URL is versioned — the regex can't check that for you
  <FilesMatch "\.(webp|avif|png|jpg|jpeg|gif|svg|woff2|css|js)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
  # HTML — always revalidate
  <FilesMatch "\.(html|php)$">
    Header set Cache-Control "no-cache"
  </FilesMatch>
</IfModule>

Wichtig: Die Ein-Jahres-Regel mit immutable ist nur für Dateinamen mit Versions-Fingerprint (style.a1b2c3.css, app.9f2.js) sicher. Dieses FilesMatch erfasst jede Datei mit passender Endung. Tragen Ihre CSS-, JS- oder Bilddateien also schlichte, unversionierte Namen (style.css, logo.png), nagelt die Regel veraltete Kopien ein Jahr lang in den Browsern der Besucher fest – „das ändern wir selten“ reicht für immutable nicht. Versionieren Sie entweder erst Ihre Dateinamen (siehe unten), oder geben Sie unversionierten Assets ein viel kürzeres max-age und lassen immutable weg. Und prüfen Sie nach dem Einrichten die Header, die ein Besucher an der öffentlichen URL tatsächlich bekommt: Ein vorgeschalteter Reverse-Proxy oder ein CDN kann die Cache-Vorgaben Ihres Ursprungsservers umschreiben oder ignorieren.

Das Problem der veralteten Datei: Versionierung

Lange Cache-Laufzeiten werfen eine Sorge auf: Wie kommt Ihr Update beim Besucher an, wenn sein Browser die alte Datei ein Jahr behalten soll? Die Antwort ist Cache-Busting – ändern Sie den Dateinamen, wenn sich der Inhalt ändert:

style.css        →  style.a1b2c3.css

Weil die URL neu ist, holen Browser sie frisch, während alle unveränderten Dateien im Cache bleiben. Zwei Bedingungen müssen stimmen: Aktualisieren Sie jeden Verweis (HTML, CSS, Preloads, Manifest) auf die neue URL, und lassen Sie die alte Datei auf dem Server, bis zwischengespeichertes HTML, das noch auf sie verweist, abgelaufen ist – die Cache-Vorgabe des HTML gehört mit zum System. Viele Produktions-Build-Pipelines erzeugen diese Inhalts-Hashes, wenn man sie entsprechend konfiguriert.

Sagen Sie Browsern, was sie gefahrlos wiederverwenden dürfen – dann werden wiederholte Besuche schneller, und weniger Anfragen erreichen Ihren Server.

Was zu tun ist

1. Setzen Sie langes max-age (und immutable) auf statische Assets – aber erst, wenn deren Dateinamen versioniert sind; unversionierte Dateien bekommen stattdessen eine kurze Laufzeit.
2. Lassen Sie HTML auf no-cache mit funktionierendem ETag/Last-Modified oder auf einer kurzen Laufzeit; nutzen Sie private für personalisierte Seiten und no-store (plus Zugriffskontrollen) für wirklich sensible.
3. Versionieren Sie Asset-Dateinamen und aktualisieren Sie bei Inhaltsänderungen jeden Verweis.
4. Schalten Sie auch Gzip-/Brotli-Kompression ein – und prüfen Sie die tatsächlich an der öffentlichen URL ausgelieferten Header, denn ein CDN kann sie verändern.
5. Schauen Sie erneut in Ihre Logs: Wiederholte Anfragen und 304-Antworten für langlebige versionierte Assets sollten zurückgehen (HTML auf no-cache revalidiert absichtlich weiter).