Was ist ein Cache?

Ein Cache ist ein schneller Zwischenspeicher, der Kopien bereits ausgelieferter oder berechneter Inhalte vorhält, um künftige Zugriffe mit minimaler Latenz zu bedienen. Im Web ist Caching eine Querschnittsfunktion – sie greift im Browser (privater Cache), in Shared Caches wie Proxies und CDNs (Edge), in Service Workern (Cache Storage API), im DNS-Resolver und sogar auf der Hardwareebene (CPU-Caches). Die Semantik für HTTP-Caching ist in RFC 9111 als Internet-Standard (STD 98) verbindlich festgelegt.

Der Browser-Cache speichert häufig genutzte Dateien lokal, um Ladezeiten zu reduzieren und die Benutzererfahrung zu verbessern.

Warum Caching? Nutzen und Wirkprinzip

Performance & Nutzererlebnis: Liegt eine Antwort im Cache, entfällt der Round-Trip zum Origin – Time to First Byte (TTFB) sinkt, Seiten reagieren subjektiv wie „vor Ort“. CDNs replizieren Inhalte an den Edge und liefern aus geografischer Nähe.

Skalierung & Kosten: Hohe HIT-Raten reduzieren Lastspitzen am Origin und den Bandbreitenverbrauch messbar.

Resilienz: Mit stale-while-revalidate und stale-if-error lassen sich veraltete Kopien kurzzeitig weiterliefern, während im Hintergrund revalidiert wird – oder wenn der Origin temporär fehlschlägt.

Taxonomie: Cache-Arten im Web

Private vs. Shared Caches. Die HTTP-Spezifikation unterscheidet private Caches (typisch: Browser) und geteilte Caches (Proxy, CDN). Private Caches dürfen personalisierte Antworten speichern; Shared Caches versorgen viele Clients und respektieren strengere Direktiven wie s-maxage oder private.

Browser-Cache & Back-Forward-Cache (bfcache). Klassischer Browser-Cache speichert Ressourcen (z. B. CSS, JS, Bilder). Der bfcache hält zusätzlich komplette Sitzungszustände für die Vor/Zurück-Navigation – Rücksprünge wirken praktisch instantan. Chrome hebt seit März/April 2025 die traditionelle Sperre für Seiten mit Cache-Control: no-store schrittweise auf, sodass diese – unter Auflagen – ebenfalls in den bfcache kommen können. Das verbessert insbesondere die Benutzererfahrung bei Navigation.

CDN/Edge-Caches. CDNs (z. B. Cloudflare, Fastly) cachen nahe am Nutzer und bieten zusätzliche Steuerungs-Header wie CDN-Cache-Control (separate TTL nur für das CDN) bzw. Surrogate-Control (Edge-TTL bei Fastly) sowie Surrogate-Keys für tag-basiertes Purging.

Service Worker (Cache Storage). Service Worker können Netzwerkzugriffe abfangen und Antworten programmatisch im Cache Storage verwalten – mit Strategien wie Cache-First, Network-First oder Stale-While-Revalidate (z. B. via Workbox). Das ermöglicht Offline-Funktionalität und feingranulare Steuerung auf Routen- oder Asset-Ebene.

DNS-Cache. Resolver und Browser cachen DNS-Antworten gemäß TTL, damit Namen nicht bei jeder Anfrage erneut aufgelöst werden müssen.

CPU-Cache. Außerhalb des HTTP-Stacks beschleunigen L1/L2/L3-Caches den Zugriff auf Daten direkt auf Hardwareebene – das Prinzip ist analog: kleine, schnelle Speicher halten heiß genutzte Daten nahe am Kern.

HTTP-Caching: Grundbegriffe

Hit/Miss. Ein Hit beantwortet aus Cache, ein Miss führt zum Origin und legt (je nach Richtlinien) die Antwort ab. (Definitionen siehe RFC 9111.)

Fresh vs. Stale. Eine Antwort ist fresh, solange ihre Frischelebensdauer nicht abgelaufen ist (TTL via Cache-Control: max-age oder Expires). Danach ist sie stale und muss revalidiert oder ersetzt werden.

Ablauf vs. Validierung. Ablauf-basiertes Caching liefert bis zum TTL-Ende ohne Rückfrage aus. Validierungs-basiert prüft via If-None-Match (ETag) oder If-Modified-Since (Last-Modified), ob sich die Ressource geändert hat – bei Gleichheit antwortet der Server mit 304 Not Modified (ohne Body-Transfer).

Cache-Key & Vary. Welche Anfrage auf welchen Eintrag mappt, bestimmen URL, Methode und ggf. vary-ende Header (Vary). Falsch gesetzte Vary-Werte fragmentieren den Cache; fehlende Vary-Angaben riskieren Fehlzuordnungen (z. B. Sprachen, Kompression, Cookies).

Age. Der Age-Header zeigt, wie viele Sekunden eine Antwort bereits in einem (Proxy-)Cache liegt – nützlich für Debugging und Frischeberechnung.

Steuerung per Header: die Stellschrauben in der Praxis

Cache-Control – zentraler Regler

Wichtige Antwort-Direktiven (Auswahl):

• max-age=<s> – Lebensdauer im Client (Sekunden).
• s-maxage=<s> – überschreibt max-age für Shared Caches (CDN/Proxy).
• public / private – für geteilte vs. nur private Caches.
• no-store – nicht speichern (weder privat noch geteilt).
• no-cache – Speichern erlaubt, aber vor Auslieferung revalidieren.
• must-revalidate – stale niemals ohne Revalidierung verwenden.
• immutable – während Freshness nicht revalidieren (ideal mit Hash-Dateinamen).
• stale-while-revalidate=<s>, stale-if-error=<s> – veraltete Inhalte kurzzeitig ausliefern, während im Hintergrund aktualisiert wird bzw. bei Fehlern.

Hinweis: Hat eine Antwort max-age/s-maxage, wird ein zusätzliches Expires von modernen Caches ignoriert – steuern Sie vorrangig über Cache-Control.

Beispiel – statische Assets (Versionierung via Hash):

Variante mit Dateinamen-Hash (z. B. app.8f3a1c.js) eliminiert Aktualitätsrisiken bei langer TTL, weil ein neues Asset eine neue URL trägt.

Beispiel – HTML am Edge cachen, im Browser nicht:

Fastly respektiert Surrogate-Control (Edge-TTL) vorrangig; der Browser hält sich an Cache-Control: no-store. So entlasten Sie den Origin ohne Risiken im Endgerät.

Beispiel – API mit schneller Revalidierung:

Kurze Freshness plus Hintergrund-Revalidierung senken Latenz und Traffic; der ETag macht 304-Runden effizient.

Validatoren: ETag & Last-Modified → 304

ETag identifiziert eine konkrete Version einer Ressource (stark vs. schwach). Last-Modified gibt den letzten Änderungszeitpunkt an; beide ermöglichen konditionelle Requests. Bleibt die Ressource gleich, liefert der Server 304 – ohne Body.

Browser-Details: Back-Forward-Cache (bfcache)

Der bfcache speichert eine komplette Seitenumgebung für die Vor/Zurück-Navigation. Dadurch sind Rücksprünge nahezu instantan. Historisch schloss Cache-Control: no-store Seiten vom bfcache aus; Chrome hat dieses Verhalten geändert und rollt seit Chrome 116 bis März/April 2025 die Unterstützung für no-store-Seiten aus, sofern Sicherheitskriterien erfüllt sind. Prüfen Sie die bfcache-Eignung und vermeiden Sie Hinderungsgründe (z. B. unload-Handler).

CDN/Edge-Spezifika: getrennte Steuerung & Purging

Separate TTLs für Browser vs. Edge. Neben s-maxage bieten CDNs proprietäre Header:

• Cloudflare CDN-Cache-Control – steuert nur das Verhalten des CDN, unabhängig vom Browser-Cache.
• Fastly Surrogate-Control – Edge-TTL unabhängig von Cache-Control.

Punktgenaue Invalidierung. Surrogate-Keys erlauben, thematisch gruppierte Inhalte (z. B. alle Artikel einer Kategorie) per Tag gezielt zu purgen, statt einzelne URLs oder den gesamten Cache zu leeren.

Default-Verhalten verstehen. Cloudflare respektiert Origin-Header (inkl. Ausnahmen) und stellt Cache-Status über CF-Cache-Status transparent dar; Fastly exponiert X-Cache und X-Cache-Hits. Diese Felder unterstützen Ihre Diagnose im Betrieb.

Service Worker & Cache Storage: feingranular cachen

Mit Cache Storage verwalten Sie Caches programmatisch – etwa Pre-Caching für App-Shells und Runtime-Caching für Routen. Workbox stellt Strategien bereit:

• Cache-First (z. B. Icons, Fonts)
• Network-First (z. B. HTML, Suchergebnisse)
• Stale-While-Revalidate (kritische Assets: sofort + Hintergrund-Update)

Wichtig: Der HTTP-Cache des Browsers ist separat vom Cache Storage; widersprüchliche Regeln sollten Sie vermeiden.

Anwendungscaches (Server/Data-Layer): Redis & Co.

Für API-Antworten, Sessions, Berechnungen oder Datenbank-Reads nutzen Teams In-Memory-Caches wie Redis:

• Eviction-Policies. Bei Speicherdruck entfernt Redis Einträge gemäß konfigurierter Policy (LRU, LFU, volatile-*, allkeys-*, noeviction usw.). Managed-Varianten setzen sinnvolle Defaults (z. B. volatile-lru bei ElastiCache).
• Strategien. Cache-Aside (Lazy Loading), Write-Through und Write-Behind bestimmen, wann Daten in Cache und Datenbank landen; TTLs bemessen Sie nach Änderungsrate und Toleranz gegen veraltete Daten.
• Betrieb. Achten Sie auf Speicherfragmentierung, Schlüssel-TTL und Beobachtbarkeit (Monitoring). Cloud-Guides liefern praxistaugliche Richtlinien.

SEO-Relevanz: Core Web Vitals & Indexierung

Caching unterstützt die Core Web Vitals indirekt: schnellere LCP (schnell geladene hero-Assets), bessere Interaktivität (INP ersetzt FID) und stabilere Erlebnisse. Google dokumentiert Schwellenwerte und die Auswertung in der Search Console. Planen Sie Caching als einen Baustein neben Server-TTFB-Optimierung, Bildkompression, kritischem CSS und Script-Disziplin.

Sicherheit & Datenschutz

Sensible Inhalte nicht cachen. Seiten mit personenbezogenen Daten sollten Cache-Control: no-store setzen. Das verhindert Speicherung in Browsern und Shared Caches (OWASP-Empfehlung).

Web-Cache-Poisoning. Unkeyed Inputs oder fehlerhafte Key-Definition können es Angreifern erlauben, manipulierte Antworten im Shared Cache zu platzieren. Gegenmaßnahmen: dynamische Inhalte nicht im Shared Cache speichern, Cache-Key korrekt definieren (Header/Parameter per Vary einbeziehen), Eingaben hart validieren.

Web-Cache-Deception. Diskrepanzen zwischen Origin- und Cache-Routing können dazu führen, dass dynamische Inhalte fälschlich als statisch behandelt und gespeichert werden. Konsequenz: strikte Routen- und Content-Type-Regeln, konsequente Cache-Klassifizierung, saubere Key-Definition.

Implementierungsrezepte (Header-Muster)

1) Statische Assets (mit Dateinamen-Hash):

Minimale Komplexität, maximale Wirkung – Clients revalidieren während der Freshness nicht.

2) HTML/SSR – Edge cachen, Browser nicht:

CDN entlasten, aber keine persistente Speicherung im Endgerät zulassen.

3) APIs – schnell & robust:

Geringe Latenz im Wiederholungsfall, 304 spart Transfer; SWR verdeckt die Revalidierungs-Latenz.

4) Personalisierte/private Inhalte:

Shared-Caching unterbinden, keine persistente Speicherung.

5) Feinsteuerung nur am CDN (Cloudflare):

Edge-TTL getrennt vom Browser steuern; bei Origin-Fehlern kurz stale weiterliefern.

Fehlersuche & Monitoring

Header prüfen. In DevTools/Logs: Cache-Control, Age, ETag/Last-Modified, Status (200/304), Vary. Bei CDNs zusätzlich CF-Cache-Status (Cloudflare) bzw. X-Cache/X-Cache-Hits (Fastly), um HIT/MISS zu deuten.

HIT-Ratio & Freshness. Beobachten Sie HIT-Raten und Rest-TTL; eine hohe Zahl bedingter (304) Antworten ist bei Wiederbesuchen positiv – sie spart Bandbreite und beschleunigt gefühlt.

Typische Antipatterns (und bessere Alternativen)

1. „Header-Salat“ wie no-store, no-cache, max-age=0, must-revalidate, Expires=0: widersprüchlich und schwer wartbar. Besser: minimale, klare Direktiven passend zum Anwendungsfall (z. B. nur no-store oder ein sauber definiertes max-age).
2. Fehlende Versionierung. Ohne Hash-Dateinamen müssen Sie TTLs künstlich kurz halten oder riskieren Staleness. Besser: Build-Hash + lange TTL + immutable.
3. Alles im Browser cachen. HTML gehört selten langfristig in den Browser-Cache; trennen Sie Browser- und Edge-TTL. Besser: s-maxage/Surrogate-Control am Edge, no-store im Browser.
4. Unkeyed Inputs. Fehlt ein relevanter Header/Parameter im Cache-Key, drohen Falschzuordnungen bis hin zu Cache-Poisoning. Besser: Vary und CDN-Key-Regeln korrekt definieren.

FAQ zum Thema Cache

Ist no-cache gleichbedeutend mit „nicht cachen“?
Nein. no-cache erlaubt Speicherung, erzwingt aber Revalidierung vor Auslieferung. Für gar nicht speichern verwenden Sie no-store.

Ignoriert max-age ein gesetztes Expires?
Ja. Liegt max-age/s-maxage vor, wird Expires ignoriert.

Wozu immutable?
Es vermeidet unnötige Revalidierungen während der Freshness – sinnvoll bei versionierten Assets mit Hash-Dateinamen.

Was bringt 304 gegenüber 200?
Bei Wiederbesuchen spart 304 Not Modified den Body-Transfer und beschleunigt die gefühlte Ladezeit.

Wie verhindere ich Sicherheitsprobleme durch Caches?
Sensible Routen: no-store. Dynamisches, nutzerspezifisches HTML nicht im Shared Cache speichern. Cache-Keys sauber definieren (Vary). Auf Cache-Poisoning/-Deception testen.

Kompakte Merkhilfe (Cheatsheet)

• Assets (mit Hash): public, max-age=31536000, immutable – lang leben lassen, keine Revalidierung nötig.
• HTML (Edge ja, Browser nein): Surrogate-Control: max-age=<N> und Cache-Control: no-store (oder s-maxage=<N> in Cache-Control).
• APIs (schnell revalidieren): public, max-age=60, stale-while-revalidate=30 + ETag.
• Sensible Daten: private, no-store.

Fazit

Caching ist eine der wirksamsten Hebeln für Performance, Skalierung und Stabilität – unter einer Bedingung: saubere Semantik. Praktisch heißt das für Ihre Websites und Web-Apps:

1. Header klar definieren (Cache-Control als primärer Regler; Expires nur für Legacy).
2. Keys korrekt bestimmen (Vary nur dort, wo inhaltlich erforderlich – aber dann konsequent).
3. Langzeit-Caching für Assets mit Dateinamen-Hash + immutable; kurzlebiges Dokument-Caching via Edge-TTL (s-maxage/Surrogate-Control).
4. Validatoren nutzen (ETag, Last-Modified) und 304 als Feature begreifen.
5. Sicherheit vorziehen: no-store für schützensame Inhalte; Shared-Caching für dynamische, nutzerspezifische Seiten vermeiden; Key-Design gegen Poisoning/Deception absichern.

Wenn Sie diese Prinzipien befolgen, erhöhen Sie Ihre HIT-Quote, senken Latenz und Last – und schaffen die Grundlage für bessere Core Web Vitals und damit ein nachhaltiges Nutzer- und Sucherlebnis.