Hauptbereich
Agency
web-development

Caching und CDN verstehen — die Schichten, die Header und das schwere Problem

Redaktion ·

Caching ist die billigste Performance, die es gibt: Eine Antwort, die schon mal berechnet wurde, ein zweites Mal auszuliefern, kostet fast nichts. Genau deshalb ist das Web von oben bis unten mit Cache-Schichten durchzogen — und genau deshalb ist falsches Caching eine der hartnäckigsten Fehlerquellen überhaupt. Dieser Artikel erklärt die Schichten, die HTTP-Header, die Rolle des CDN und das eine Problem, das alles schwer macht: die Invalidierung.

Die Cache-Schichten

Zwischen dem Nutzer und deiner Datenbank liegen mehrere Stationen, die jeweils zwischenspeichern können. Von außen nach innen:

  • Browser-Cache — der Cache direkt im Browser des Nutzers. Lädt er eine Seite erneut, holt er Assets aus dem lokalen Speicher statt übers Netz. Privat, nur für diesen einen Nutzer.
  • CDN-/Edge-Cache — ein geografisch verteiltes Netz von Servern (siehe unten). Speichert Antworten nahe am Nutzer und entlastet deinen Ursprungsserver.
  • Server-/Application-Cache — auf deiner Seite: gerenderte Seiten, berechnete Ergebnisse, API-Antworten, die im RAM oder in einem Store wie Redis liegen, statt bei jeder Anfrage neu berechnet zu werden.
  • Datenbank-Cache — die unterste Schicht: häufige Query-Ergebnisse, die die Datenbank (oder ein Layer davor) vorhält, damit nicht jede Anfrage auf die Platte muss.

Je weiter außen ein Cache greift, desto größer die Ersparnis — eine im Browser gecachte Datei verursacht gar keinen Traffic. Je weiter innen, desto frischer die Daten, aber desto mehr Arbeit bis zur Auslieferung.

Wie HTTP-Caching-Header funktionieren

Die Kommunikation zwischen Server und Cache läuft über HTTP-Header. Die wichtigsten:

Cache-Control ist der zentrale Schalter. Die wichtigsten Direktiven:

  • max-age=<Sekunden> — wie lange die Antwort als „frisch” gilt. Innerhalb dieser Zeit wird sie ohne Rückfrage wiederverwendet.
  • public / private — public darf in geteilten Caches (CDN, Proxy) liegen, private nur im Browser des Nutzers (für personalisierte Inhalte).
  • no-cache — speichern erlaubt, aber vor jeder Wiederverwendung beim Server revalidieren. Nicht zu verwechseln mit:
  • no-store — gar nicht speichern. Für sensible Daten.

ETag und Last-Modified ermöglichen die Revalidierung. Der Server schickt mit der Antwort einen ETag (einen Hash des Inhalts) oder ein Änderungsdatum. Ist die gecachte Kopie abgelaufen, fragt der Client mit If-None-Match (bzw. If-Modified-Since) nach: „Habe ich noch die aktuelle Version?” Hat sich nichts geändert, antwortet der Server mit einem schlanken 304 Not Modified — kein erneuter Download des Inhalts. ETag ist dabei zuverlässiger als Last-Modified und hat bei der Revalidierung Vorrang.

stale-while-revalidate ist der elegante Kompromiss: Der Cache darf eine leicht veraltete Antwort sofort ausliefern und parallel im Hintergrund eine frische holen. Der Nutzer wartet nie auf die Revalidierung; das nächste Mal ist die Antwort aktuell. Ideal für Inhalte, bei denen ein paar Sekunden Veralterung egal sind.

Was ein CDN macht

Ein CDN (Content Delivery Network) ist ein weltweit verteiltes Netz von Edge-Servern. Statt dass jeder Nutzer deinen einen Ursprungsserver (etwa in Frankfurt) kontaktiert, wird die Anfrage an den nächstgelegenen Edge-Knoten geleitet — für einen Nutzer in Tokio also an einen Server in Japan.

Drei Hauptaufgaben:

  1. Statische Assets näher zum Nutzer. Bilder, CSS, JavaScript, Schriften liegen am Edge zwischengespeichert. Die kürzere physische Distanz senkt die Latenz und damit den TTFB spürbar.
  2. Lastabbau am Ursprung. Was der Edge ausliefert, muss dein Server nicht. Bei Traffic-Spitzen oder viralen Inhalten fängt das CDN den Großteil ab.
  3. Zusätzliche Aufgaben. Moderne CDNs übernehmen oft TLS-Terminierung, Kompression (Brotli/Gzip) und teils Sicherheitsfilter (DDoS-Schutz, WAF) — direkt am Edge, bevor die Anfrage den Ursprung erreicht.

Cache-Invalidierung — das schwere Problem

Es gibt einen alten Branchenspruch: Die zwei schwierigsten Dinge in der Informatik sind Cache-Invalidierung und das Benennen von Dingen. Der Witz hat einen wahren Kern.

Das Problem: Du willst lange Cache-Zeiten (für Performance), aber du willst auch, dass Nutzer die aktuelle Version sehen, sobald du etwas änderst. Diese beiden Ziele stehen im Konflikt. Setzt du max-age auf ein Jahr und änderst dann die Datei, sehen Nutzer mit gecachter Kopie tagelang die alte.

Die saubere Lösung für statische Assets heißt Cache Busting: Der Dateiname enthält einen Versions-Hash, etwa app.v123.css oder app.a1b2c3.js. Änderst du den Inhalt, ändert sich der Hash und damit die URL — der Browser sieht eine neue Datei und lädt sie. Die alte URL bleibt bedenkenlos ein Jahr gecacht, weil sie nie wieder denselben Inhalt zeigt.

Praktische Defaults (nach MDN, Stand 2026):

  • Versionierte statische Assets (mit Hash im Namen): Cache-Control: public, max-age=31536000, immutable — ein Jahr, nie revalidieren.
  • HTML-Dokumente (feste URL, kein Busting möglich): Cache-Control: no-cache plus ETag — immer revalidieren, aber bei Unverändert nur ein 304.
  • Personalisierte/dynamische Antworten: Cache-Control: no-cache, private.

Für CDN-Caches, die sich nicht über HTTP-Header allein leeren lassen, bieten Anbieter ein aktives Purge (per API oder Dashboard), um eine bestimmte URL sofort aus allen Edge-Knoten zu werfen.

Der Performance- und SEO-Effekt

Caching wirkt direkt auf die Kennzahlen, die Google misst. Ein niedriger TTFB — maßgeblich durch CDN und Server-Cache getrieben — ist der Startschuss für alle weiteren Ladephasen und fließt in die Core Web Vitals ein. Stabil schnelle Auslieferung, auch unter Last, verbessert die Nutzererfahrung und indirekt das Ranking. Caching ist damit kein reines Infrastruktur-Thema, sondern ein SEO-Hebel.

FAQ

Was ist der Unterschied zwischen no-cache und no-store? no-store verbietet das Speichern komplett — die Antwort landet in keinem Cache. no-cache erlaubt das Speichern, verlangt aber vor jeder Wiederverwendung eine Revalidierung beim Server. no-cache ist also nicht „nicht cachen”, sondern „cachen, aber immer nachfragen”.

Wofür sind ETag und Last-Modified gut? Für die Revalidierung. Ist eine gecachte Antwort abgelaufen, fragt der Client mit dem ETag nach, ob sie noch aktuell ist. Hat sich nichts geändert, antwortet der Server mit einem schlanken 304 statt den ganzen Inhalt erneut zu schicken — das spart Bandbreite und Zeit.

Brauche ich ein CDN, wenn mein Server schnell ist? Oft ja. Selbst ein schneller Server steht an einem Ort; Nutzer am anderen Ende der Welt zahlen die physische Latenz. Ein CDN liefert vom nächstgelegenen Edge-Knoten und fängt zusätzlich Lastspitzen ab. Für globales Publikum ist es fast immer sinnvoll.

Wie aktualisiere ich eine Datei, die mit max-age ein Jahr gecacht ist? Über Cache Busting: Gib der Datei bei jeder Änderung einen neuen Namen mit Versions-Hash (app.v124.css). Die neue URL wird frisch geladen, die alte bleibt harmlos im Cache. So kombinierst du lange Cache-Zeiten mit sofortiger Aktualisierung.

Was bringt stale-while-revalidate? Geschwindigkeit ohne spürbare Veralterung. Der Cache liefert sofort eine leicht veraltete Antwort und holt parallel im Hintergrund die frische. Der Nutzer wartet nie auf die Aktualisierung — beim nächsten Aufruf ist sie da. Ideal für Inhalte, bei denen Sekunden Verzögerung unkritisch sind.

Themenuebersicht

Web DevelopmentPerformance