Was ist ein Cache?

Stellen Sie sich Ihre Speisekammer vor.

Mehl, Salz, Öl, Pasta. Sie laufen nicht für jedes Abendessen in den Großmarkt. Was Sie häufig brauchen, steht griffbereit. Zwei Schritte, Türgriff, fertig.

Genau das tut ein Cache: Er hält Kopien von Inhalten oder Ergebnissen vor, damit der nächste Zugriff schnell geht. Im Web greift dieses Prinzip überall: im Browser des Lesers (privater Cache), in Shared Caches wie Proxies und CDNs, in Service Workern, im DNS-Resolver, sogar tief in der Hardware (CPU-Caches).

Die Spielregeln für das HTTP-Caching im Web sind verbindlich festgelegt: in RFC 9111, dem Internet-Standard STD 98. Wer mit Caches arbeitet, arbeitet mit dieser Grammatik.

Ein Cache hält häufig benötigte Inhalte griffbereit und beschleunigt Webseiten durch Regeln wie max-age, ETag und stale-while-revalidate.

Warum Caching? Drei Gründe, die zählen

Tempo. Liegt eine Antwort im Cache, fällt der Weg zum Origin weg. Time to First Byte sinkt. Die Seite reagiert, als säße der Server in der gleichen Straße. CDNs replizieren Inhalte an den Edge und liefern aus geografischer Nähe.

Kosten. Hohe HIT-Raten nehmen Lastspitzen vom Origin und sparen messbar Bandbreite. Ihr Server muss nicht alles selbst beantworten. Er muss nicht einmal die Hälfte selbst beantworten.

Stabilität. Mit stale-while-revalidate und stale-if-error lassen sich veraltete Kopien noch kurz weiterliefern, während im Hintergrund nachgeladen wird. Geht der Origin temporär in die Knie, bleibt die Seite trotzdem online.

Drei Vorteile, eine Voraussetzung: saubere Semantik. Wer einen Cache schlampig konfiguriert, verliert nicht nur Performance. Er erzeugt Bugs, die sich erst Wochen später beim falschen Nutzer zeigen.

Welche Caches gibt es?

Private und geteilte Caches

Die HTTP-Spezifikation unterscheidet zwei Welten. Private Caches gehören einem einzelnen Nutzer, typischerweise im Browser. Sie dürfen auch personalisierte Antworten speichern. Shared Caches stehen zwischen Origin und Publikum, etwa als Proxy oder CDN. Sie versorgen viele Clients gleichzeitig und respektieren strengere Direktiven wie s-maxage oder private.

Wer das verwechselt, lagert Privates ins öffentliche Regal. Das wäre, als würden Sie Ihre Insulinspritzen in den Hausflur stellen.

Browser-Cache und bfcache

Der klassische Browser-Cache hält CSS, JavaScript, Bilder und Schriften vor. Der Back-Forward-Cache geht weiter: Er speichert eine komplette Seitenumgebung mitsamt JavaScript-Zustand. Wer auf Zurück klickt, springt fast verzögerungsfrei in die alte Ansicht. Es fühlt sich nicht nach Reload an. Es fühlt sich nach Wiederkehr an.

Lange Zeit galt: Seiten mit Cache-Control: no-store sind vom bfcache ausgeschlossen. Chrome hat das bis April 2025 schrittweise geändert. Solche Seiten dürfen nun, unter Auflagen, ebenfalls in den bfcache. Wichtige Einschränkungen bleiben: Die Aufenthaltsdauer liegt bei drei Minuten statt zehn, und sobald sich Cookies ändern, fliegt die Seite aus dem Cache. Das schützt vor dem Fall, dass jemand nach dem Logout per Zurück in einen alten Zustand stolpert.

CDN- und Edge-Caches

CDNs wie Cloudflare oder Fastly cachen so nah am Nutzer wie möglich. Sie kennen zusätzliche Steuerungs-Header: CDN-Cache-Control wirkt ausschließlich am CDN, Surrogate-Control setzt die Edge-TTL bei Fastly. Mit Surrogate-Keys lassen sich ganze Themen-Cluster auf einen Schlag purgen, etwa alle Seiten einer Kategorie, sobald sich der Preis ändert.

Service Worker und Cache Storage

Service Worker sind die Hausmeister Ihrer Web-App. Sie fangen Netzwerk-Requests ab und legen Antworten programmatisch in den Cache Storage. Drei Strategien haben sich durchgesetzt: Cache-First (nimm zuerst aus dem Vorrat), Network-First (frag erst den Server), Stale-While-Revalidate (gib aus dem Vorrat raus, geh dabei einkaufen). So funktioniert Offline-Tauglichkeit.

DNS- und CPU-Cache

Auch unter der Haube wird gecacht. DNS-Resolver merken sich, welche IP zu einer Domain gehört, damit nicht jeder Klick einen Lookup auslöst. Und L1-, L2- und L3-Caches auf der CPU halten heiß genutzte Daten direkt neben dem Rechenkern. Das Prinzip wiederholt sich auf jeder Ebene: kleiner Speicher, schneller Zugriff, höhere Nähe zum Bedarf.

HTTP-Caching: die Grammatik in Kürze

Hit oder Miss? Trifft eine Anfrage auf einen passenden Eintrag, antwortet der Cache direkt (Hit). Fehlt der Eintrag, geht die Anfrage zum Origin und wird, je nach Regel, abgelegt (Miss).

Fresh oder stale? Eine Antwort ist fresh, solange ihre Frischelebensdauer noch läuft. Sie ist stale, sobald die TTL abgelaufen ist. Das ist die Speisekammer-Logik. Mehl hält ein Jahr. Milch eine Woche. Sushi nicht über Nacht.

Ablauf oder Validierung? Ablauf-basiertes Caching liefert ohne Rückfrage aus, solange die TTL läuft. Validierungs-basiertes Caching fragt beim Origin nach, ob sich die Datei geändert hat, mittels If-None-Match (ETag) oder If-Modified-Since (Last-Modified). Ist nichts neu, antwortet der Server mit 304 Not Modified. Ohne Body. Ohne Datenballast.

Wer mappt auf was? Der Cache-Key entscheidet, welche Anfrage welchen Eintrag trifft. URL und Methode sind Pflicht, dazu kommen Header, die der Vary-Wert mit aufnimmt. Sind diese Werte falsch gesetzt, passieren zwei Sorten Unglück: Der Cache fragmentiert sinnlos, oder er sortiert Antworten falsch zu. Sprache, Kompression, Cookies sind die klassischen Stolperfallen.

Wie alt ist die Antwort? Der Age-Header verrät, wie lange die Antwort schon in einem Proxy liegt. Klein und unscheinbar, aber Gold wert beim Debuggen.

Steuerung per Header: die Stellschrauben

Cache-Control – der zentrale Regler

Wenn Sie nur eine Sache lernen wollen, lernen Sie Cache-Control. Die wichtigsten Direktiven für Antworten:

• max-age=<s>: Lebensdauer im Client in Sekunden.
• s-maxage=<s>: überschreibt max-age für Shared Caches. Browser hält sich an max-age, CDN an s-maxage.
• public / private: für geteilte oder ausschließlich private Caches.
• no-store: gar nicht speichern. Weder hier noch dort.
• no-cache: Speichern ja, aber vor jeder Auslieferung revalidieren. (Ein Missverständnis-Magnet: no-cache heißt nicht „nicht cachen“.)
• must-revalidate: stale-Antworten nie ohne Rückfrage ausliefern.
• immutable: während der Freshness nicht revalidieren. Perfekt für versionierte Assets.
• stale-while-revalidate und stale-if-error: kurz veraltet ausliefern, im Hintergrund frisch holen oder bei Origin-Fehlern überbrücken.

Liegt max-age oder s-maxage vor, hat ein zusätzliches Expires keine Wirkung mehr. Steuern Sie vorrangig über Cache-Control. Expires ist Legacy.

Beispiel 1 – statische Assets mit Dateinamen-Hash:

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

Ein Jahr Freshness, keine Revalidierung. Funktioniert, weil ein neues Asset einen neuen Hash trägt: app.8f3a1c.js wird zu app.d47b2e.js. Neue URL, neuer Inhalt. Kein Risiko.

Beispiel 2 – HTML am Edge cachen, im Browser nicht:

Surrogate-Control: max-age=600
Cache-Control: no-store

Das CDN hält die Seite zehn Minuten vor und entlastet den Origin. Der Browser speichert nichts. Sensibel und schnell zugleich.

Beispiel 3 – API mit schneller Revalidierung:

Cache-Control: public, max-age=60, stale-while-revalidate=30
ETag: "abc123"

Niedrige Latenz, weil 60 Sekunden lang aus dem Cache geliefert wird. Robust, weil die folgenden 30 Sekunden stale-Ausgabe erlaubt sind, während im Hintergrund frisch geladen wird. Der ETag macht 304-Runden günstig.

Validatoren: ETag und Last-Modified

ETag markiert eine konkrete Version (stark oder schwach). Last-Modified nennt den letzten Änderungszeitpunkt. Beide ermöglichen konditionelle Requests: „Hast du was Neues?“ Wenn nicht: 304, kein Body, kein Transfer. Das ist nicht nur Performance, das ist Höflichkeit gegenüber der Leitung.

Browser-Detail: der Back-Forward-Cache

Der bfcache ist die unterschätzte Performance-Quelle der letzten Jahre. Er speichert nicht nur Ressourcen, sondern den kompletten Zustand einer Seite. Inklusive DOM, JavaScript-Heap, Scroll-Position. Wer zurückgeht, kommt zurück. Nicht „lädt nochmal“.

Was bfcache verhindert? Klassiker:

• unload-Handler. Chrome ist dabei, diese Events ohnehin zu deprecaten. Bauen Sie sie raus.
• Offene WebSockets oder WebRTC-Verbindungen.
• Bestimmte Sicherheits-Konstellationen.

Was Sie nicht mehr verhindert: Cache-Control: no-store allein. Chrome hat diese Sperre gelockert, was vor allem für Shop-Systeme spürbar ist, in denen Nutzer ständig zwischen Liste und Detailseite hin- und herwandern.

Was würden Sie eher tun: hundert Optimierungen am Initial-Load suchen oder den bfcache freischalten, der die zweite Hälfte aller Navigationen beschleunigt?

CDN und Edge: getrennt steuern, gezielt purgen

Edge-TTL getrennt von Browser-TTL. Über s-maxage steuern Sie Shared Caches im Standard. Darüber hinaus bieten CDNs eigene Header:

• Cloudflare nutzt CDN-Cache-Control ausschließlich für das eigene Verhalten, unabhängig vom Browser.
• Fastly nutzt Surrogate-Control für die Edge-TTL und ignoriert dabei Cache-Control nicht, lässt es aber für den Client gelten.

Punktgenau invalidieren. Surrogate-Keys sind das, was den Unterschied zwischen Profi und Bastler ausmacht. Statt einzelne URLs zu purgen oder gleich den ganzen Cache zu leeren, taggen Sie Inhalte und löschen sie gruppenweise. Ein Produkt-Update? Alle Seiten mit dem Tag product-1234 raus. Drei Sekunden später ist alles aktuell.

Cache-Status sichtbar machen. Cloudflare zeigt das Verhalten über CF-Cache-Status an. Fastly nutzt X-Cache und X-Cache-Hits. Wer einen Cache betreibt, ohne diese Header zu lesen, fliegt im Blindflug.

Service Worker: feingranular cachen

Mit Cache Storage bekommen Sie programmatische Kontrolle. Pre-Caching für die App-Shell. Runtime-Caching nach Routen. Strategien wählen, wie Sie es brauchen:

• Cache-First: für Icons, Fonts, statische Assets, die selten wechseln.
• Network-First: für HTML und Suchergebnisse, wo Aktualität zählt.
• Stale-While-Revalidate: für alles, was sofort da sein muss, aber gerne im Hintergrund aktualisiert wird.

Eine Warnung: HTTP-Cache und Cache Storage sind zwei verschiedene Welten. Wenn beide widersprüchliche Regeln haben, geraten sie sich ins Gehege. Ein Konzept pro Asset. Nicht zwei.

Anwendungscaches: Redis und Verwandte

Was im Web der HTTP-Cache ist, ist im Backend Redis. Schneller In-Memory-Speicher für API-Antworten, Sessions, Berechnungen, Datenbank-Reads.

Drei Begriffe, die Sie kennen sollten:

Eviction-Policies. Wenn der Speicher voll ist, fliegt etwas raus. Welche Einträge zuerst? LRU (Least Recently Used) wirft das Älteste weg. LFU (Least Frequently Used) das Selten-Genutzte. Managed-Varianten setzen oft volatile-lru als Default, also „älteste Einträge mit TTL zuerst“.

Strategien. Cache-Aside: Anwendung fragt erst Cache, dann Datenbank. Write-Through: Schreiben in Cache und Datenbank gleichzeitig. Write-Behind: Erst in den Cache, später in die Datenbank. Welche Strategie passt, hängt davon ab, wie oft sich Ihre Daten ändern und wie viel Veraltung Sie ertragen.

Betrieb. Speicher überwachen. Schlüssel-TTL setzen. Fragmentierung im Blick behalten. Cloud-Anbieter liefern praxistaugliche Leitfäden.

SEO-Relevanz: Caching wirkt mittelbar

Caching steht nicht auf der Liste der Google-Rankingfaktoren. Aber: Die Core Web Vitals hängen direkt davon ab.

Schneller geladene Hero-Assets verbessern LCP (Largest Contentful Paint). Schlankere Interaktivität verbessert INP (Interaction to Next Paint), das seit dem 12. März 2024 FID als Core Web Vital ersetzt. Stabiles Laden senkt unerwartete CLS (Cumulative Layout Shift).

Caching ist hier kein Wundermittel, sondern ein Baustein neben Server-TTFB, Bildkompression, kritischem CSS und Script-Disziplin. Aber: ein wirkungsvoller. Wer eine starke HIT-Rate auf seinen Hero-Assets hat, hat den halben LCP-Kampf bereits gewonnen.

Was, wenn Sie Ihre HIT-Rate kennen würden, wie Sie Ihre Conversion-Rate kennen?

Sicherheit und Datenschutz

Ein Cache speichert Inhalte. Das ist sein Job. Das ist auch sein Problem.

Sensible Inhalte nicht cachen. Personenbezogene Daten, Account-Seiten, Warenkörbe: Cache-Control: no-store setzen. OWASP empfiehlt das nicht aus Übervorsicht, sondern weil Lecks regelmäßig genau hier entstehen: Jemand sieht die Seite eines anderen. Ein Klassiker.

Web-Cache-Poisoning. Angreifer schmuggeln über unkeyed Inputs manipulierte Antworten in den Shared Cache. Was ein einzelner Angreifer auslöst, treffen tausend andere Nutzer. Die Schutzmaßnahmen sind unbequem, aber klar: dynamische Inhalte nicht im Shared Cache halten, Vary sauber definieren, Eingaben hart validieren.

Web-Cache-Deception. Diskrepanzen zwischen Origin-Routing und Cache-Routing führen dazu, dass dynamische Inhalte fälschlich als statisch behandelt werden. Eine private Konto-Seite landet im öffentlichen Regal. Vorbeugung: strikte Content-Type- und Routen-Regeln, konsequente Klassifizierung, saubere Cache-Keys.

Ein Cache ist eine Beschleunigungsmaschine, kein Sicherheitslayer. Wer das verwechselt, verliert beides.

Implementierungsrezepte (Header-Muster)

1) Statische Assets mit Dateinamen-Hash:

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

Lang leben lassen, keine Revalidierung. Maximale Wirkung, minimale Komplexität.

2) HTML mit Edge-Caching ohne Browser-Speicherung:

Surrogate-Control: max-age=86400
Cache-Control: no-store

Origin entlastet, Browser-Speicher leer. Geeignet für SSR-Seiten, die zwar dynamisch wirken, aber für 24 Stunden auf Edge-Ebene gleich bleiben dürfen.

3) APIs schnell und robust:

Cache-Control: public, max-age=60, stale-while-revalidate=30
ETag: "W/\"v42\""

Latenz unten, Robustheit oben. Die 304-Antworten erledigen den Rest.

4) Personalisierte oder private Inhalte:

Cache-Control: private, no-store

Kein Shared-Caching, keine persistente Speicherung. Für alles, was nicht im Schaufenster stehen darf.

5) Feinsteuerung nur am CDN (Cloudflare):

CDN-Cache-Control: max-age=600, stale-if-error=60
Cache-Control: no-store

Edge cacht zehn Minuten, Browser nichts. Bei Origin-Fehlern wird stale weitergegeben. Das ist der Notgenerator.

Fehlersuche und Monitoring

Header lesen. In DevTools und Logs auf Cache-Control, Age, ETag, Last-Modified, Vary und den Status (200 vs. 304) achten. Bei CDNs zusätzlich CF-Cache-Status (Cloudflare) oder X-Cache, X-Cache-Hits (Fastly). Diese Header sind keine Beigabe. Sie sind das Cockpit.

HIT-Quote im Blick. Eine niedrige HIT-Rate ist meist nicht ein Caching-Problem. Sie ist ein Header-Problem. Oder ein Cache-Key-Problem. Oder beides.

304-Antworten als Erfolg lesen. Viele bedingte Antworten bei Wiederbesuchen sind ein gutes Zeichen. Sie sparen Bandbreite und beschleunigen die gefühlte Ladezeit.

Typische Antipatterns

Header-Salat. Wer no-store, no-cache, max-age=0, must-revalidate und Expires=0 in einer Zeile zusammenwürfelt, hat keine Strategie, sondern Angst. Eine klare Direktive pro Use Case reicht.

Fehlende Versionierung. Ohne Hash-Dateinamen müssen Sie TTLs künstlich kurz halten und riskieren trotzdem Staleness. Build-Hash plus lange TTL plus immutable: Drei Zutaten, drei Probleme weniger.

Alles im Browser cachen. HTML gehört selten langfristig in den Browser-Cache. Trennen Sie Browser-TTL und Edge-TTL bewusst.

Unkeyed Inputs. Fehlt ein relevanter Header oder Parameter im Cache-Key, drohen Falschzuordnungen bis hin zu Poisoning. Vary und CDN-Key-Regeln gehören zur Architektur, nicht zur Kosmetik.

FAQ zum Cache

Heißt no-cache „nicht cachen“?
Nein. no-cache erlaubt Speicherung, erzwingt aber Revalidierung vor jeder Auslieferung. „Nicht speichern“ heißt no-store. Die Begriffe sind irreführend. Lernen Sie sie einmal richtig, ärgern Sie sich seltener.

Überschreibt max-age ein gesetztes Expires?
Ja. Liegt max-age oder s-maxage vor, hat Expires keine Wirkung mehr.

Wozu immutable?
Es spart unnötige Revalidierungen während der Freshness. Sinnvoll, wenn Sie versionierte Assets mit Hash-Dateinamen ausliefern. Bei diesen Assets kann sich der Inhalt nicht ändern, also muss niemand fragen.

Was bringt 304 gegenüber 200?
Den eingesparten Body. Bei Wiederbesuchen bedeutet das schnelle, schmale Antworten und entlastete Leitungen.

Wie schütze ich mich vor Cache-Angriffen?
Sensible Routen mit no-store ausschließen. Dynamisches HTML nicht in Shared Caches halten. Cache-Keys sauber definieren. Auf Poisoning und Deception gezielt testen, nicht hoffen.

Fazit: Saubere Semantik schlägt blindes Vertrauen

Caching ist einer der wirkungsvollsten Hebel für Performance, Skalierung und Stabilität, den das Web kennt. Es kostet kein neues Tool, keinen Architekturumbau, keine zusätzliche Lizenz. Nur Sorgfalt.

Worauf es ankommt:

• Header klar definieren. Cache-Control als primärer Regler. Expires nur, wenn alte Systeme es verlangen.
• Keys korrekt bestimmen. Vary dort, wo es inhaltlich nötig ist, sonst weglassen.
• Langzeit-Caching für Assets mit Dateinamen-Hash und immutable. Kurzlebiges Dokument-Caching am Edge über s-maxage oder Surrogate-Control.
• Validatoren nutzen. ETag und Last-Modified, plus 304 als Feature begreifen, nicht als technischen Reflex.
• Sicherheit vor Geschwindigkeit. Geschützte Inhalte nicht in Shared Caches. Cache-Keys gegen Poisoning und Deception absichern.

Wer diese fünf Punkte verinnerlicht, baut Websites, die schneller, billiger und stabiler laufen. Und nebenbei bessere Core Web Vitals liefern.

Caching ist am Ende nichts Mystisches. Es ist die Speisekammer Ihrer Anwendung. Wer weiß, was rein gehört und was rausgehört, isst gut. Wer alles reinwirft, was gerade da ist, riecht es irgendwann.