CDN Caching verstehen – TTL, Cache-Control und Purge

Ein CDN beschleunigt deine Website, weil Inhalte nahe am Nutzer aus Edge-Standorten geliefert werden. Ob das wirklich funktioniert, entscheidet weniger der CDN-Anbieter als deine Cache-Regeln. Sind TTL, Cache Keys und Header sauber, bekommst du konstante Ladezeiten, eine hohe Hit-Rate und weniger Origin-Last.

Viel geht schief, wenn HTML und APIs unbedacht gecached werden, Cookies unnötig in den Cache-Schlüssel rutschen oder Versionierung fehlt. In diesem Leitfaden richtest du dein Caching systematisch ein: Du verstehst, wie ein Edge-Cache denkt, wählst passende TTLs je Inhaltstyp, definierst präzise Cache Keys und setzt Revalidierung so, dass Seiten schnell bleiben und trotzdem aktuell sind.

Wie ein CDN entscheidet, ob es cachen darf

Ein Edge prüft bei jeder Antwort des Origins die relevanten Response-Header. Die wichtigsten sind Cache-Control, ETag, Last-Modified und optional Vary. Gleichzeitig bestimmt ein Cache Key, ob zwei Anfragen als gleich gelten. Er enthält mindestens Host und Pfad, optional auch Query-Parameter, Cookies oder Headers.

• Cache-Control regelt ob und wie lange gecached wird. Wichtige Direktiven: public, private, max-age, s-maxage, no-store, no-cache, must-revalidate, stale-while-revalidate, stale-if-error.
• s-maxage überschreibt max-age in Shared Caches wie CDNs. Browser respektieren weiter max-age.
• ETag und Last-Modified erlauben Conditional Requests. Ist nichts geändert, liefert der Origin 304 Not Modified und spart Bandbreite.
• Vary erweitert den Cache Key, z. B. Vary: Accept-Encoding oder Vary: Accept-Language. Vorsicht: Ein zu breites Vary zerstört die Hit-Rate.

TTL nach Inhaltstyp – dein Grundgerüst

Statische Assets – lange TTL, Versionierung Pflicht

Für CSS, JS, Bilder, Fonts solltest du lange bis sehr lange TTLs setzen. Das geht nur sicher mit Dateinamen-Hashing. Jeder Build erzeugt neue Dateinamen, alte bleiben gültig.

Header-Beispiel für Assets:

Cache-Control: public, max-age=31536000, immutable
ETag: "sha256-3f2a9..."

• immutable sagt dem Browser: nicht revalidieren.
• Mit Hash-Namen steuerst du Aktualisierungen explizit, Purge brauchst du kaum.

HTML – kurz cachen, entspannt revalidieren

HTML ändert öfter. Ziel: schnell bleiben, aber nicht veralten. Nutze kurze s-maxage und stale-while-revalidate.

Header-Beispiel für HTML:

Cache-Control: public, max-age=60, s-maxage=120, stale-while-revalidate=30, must-revalidate
ETag: "W/\"home-2025-08-01\""

• Edge darf 120 s cachen, Browser 60 s.
• Ist die TTL abgelaufen, liefert der Edge noch bis zu 30 s die stale Version aus und aktualisiert parallel.
• must-revalidate sorgt dafür, dass nach Ablauf immer geprüft wird.

APIs – differenziert vorgehen

Für GET mit idempotenten Antworten kannst du cachen, wenn die Daten eine sinnvolle Gültigkeit haben. Für personalisierte oder sensible Antworten gilt: kein Shared Cache.

Cachebar:

Cache-Control: public, s-maxage=300, max-age=60, stale-if-error=600
ETag: "items-v42"

Nicht cachebar:

Cache-Control: private, no-store

• Vermeide Vary: Cookie, wenn Cookies den Inhalt nicht ändern.
• Prüfe, ob Authorization die Antwort wirklich beeinflusst. Wenn ja, nicht im Edge cachen.

Cache Keys präzise definieren

Ein schlanker Cache Key erhöht die Hit-Rate. Nutze Allowlisten statt alles zu übernehmen.

Prinzipien:

• Query-Parameter: Nur jene in den Key, die die Antwort wirklich verändern, z. B. ?lang=de.
• Cookies: Meist ignorieren. Wenn nötig, whiteliste einzelne Cookies.
• Headers: Nur gezielt, z. B. Accept-Encoding oder Accept-Language.

Beispiel-Regelset:

• /assets/: Key = Host + Pfad, keine Querys, keine Cookies.
• /api/search: Key = Host + Pfad + q + lang, alle anderen Parameter ignorieren.
• /admin/: gar nicht cachen.

Revalidierung – frisch bleiben ohne Lastspitzen

Wenn der Edge eine abgelaufene Ressource anfragt, kann er mit If-None-Match oder If-Modified-Since revalidieren. Das spart CPU am Origin. Kombiniere das mit stale-while-revalidate, damit Nutzer nie warten.

Ablauf in Worten:

1. Nutzer trifft auf abgelaufene HTML-Seite am Edge.
2. Edge liefert stale HTML unmittelbar, startet aber parallel die Revalidierung.
3. Origin antwortet 304 oder 200 mit neuem ETag.
4. Edge aktualisiert den Cache. Der nächste Nutzer bekommt frisch.

Stale-Optionen – Verfügbarkeit sichern

• stale-while-revalidate überbrückt kurze Zeit zur Aktualisierung.
• stale-if-error liefert alte Inhalte, wenn der Origin Fehler bringt oder nicht erreichbar ist.
• Beides schützt bei Deploys, Trafficspitzen und Origin-Aussetzern, ohne manuell einzugreifen.

Versionierung und Purge – ohne Risiko deployen

Die robusteste Strategie ist Cache Busting über Hash-Dateinamen. Du setzt für Assets sehr lange TTLs und veröffentlichst bei Änderungen neue Dateinamen. Purge brauchst du nur für HTML oder fehlerhafte Inhalte.

Wenn Purge nötig ist:

• Gezielt invalidieren nach Pfad oder Tags/Surrogate Keys, nicht den ganzen Cache.
• Soft Purge bevorzugen: markiert als abgelaufen, Edge revalidiert beim nächsten Zugriff, statt den Cache schlagartig zu leeren.

Personalisierung und Sicherheit

Personalisierte Bereiche gehören nicht in den Shared Cache. Setze Cache-Control: private, no-store. Achte darauf, dass Tokens und Session-Cookies nicht in Vary oder Cache Keys landen, wenn die Antwort nicht personalisiert ist. So vermeidest du Cache Poisoning und Datenlecks.

Typische Fehlkonfigurationen – und saubere Fixes

Problem: HTML mit max-age=0 ohne s-maxage – Ergebnis ist jeder Request ein MISS.
Fix: s-maxage setzen und stale-while-revalidate aktivieren.

Problem: Vary: Cookie global – der Edge erzeugt pro Cookie-Kombination ein neues Objekt.
Fix: Cookies aus dem Cache Key entfernen, nur unvermeidbare Cookies whitelisten.

Problem: LIKE-Parameter im Key, die die Antwort nicht verändern, z. B. utm_source.
Fix: Query-Parameter mit Allowlist, Marketing-Parameter ignorieren.

Problem: Assets ohne Dateinamen-Hash und lange TTL – Nutzer sehen alte Dateien.
Fix: Build auf Hashing umstellen und immutable setzen.

Monitoring – messen, nicht raten

Behalte Hit-Rate, TTFB, Origin-Request-Rate, 304-Quote und Fehler im Blick. Eine fallende Hit-Rate deutet auf zuviel Key-Fragmentierung oder zu kurze TTLs hin. Steigt die Origin-Last, prüfe stale-while-revalidate, s-maxage und Bypass-Regeln. Dokumentiere in Kurzform, welche Regel für welchen Pfad gilt, damit Team und zukünftiges Du die Logik sofort verstehen.

Mini-Blueprint für deinen Start

1. /assets/: Hash-Dateinamen, public, max-age=31536000, immutable, Key nur Host+Pfad.
2. /html: public, max-age=60, s-maxage=120, stale-while-revalidate=30, ETag aktiv.
3. /api:
   • Cachebar: s-maxage=300, ETag, Key mit relevanten Parametern.
   • Sensibel: private, no-store.
4. Cache Key: Allowlist für Querys, Cookies ignorieren, Accept-Language nur wenn nötig.
5. Purge: Nur gezielt.
6. Messen: Hit-Rate und TTFB eine Woche beobachten, dann nachjustieren.

Fazit

Ein verlässliches CDN-Setup basiert auf drei Bausteinen: klare Cache-Control-Regeln, passende TTLs pro Inhalt und präzise Cache Keys. Mit Versionierung per Hash-Dateinamen, stale-while-revalidate und gezieltem Purge bekommst du schnelle Antworten ohne Überraschungen. Miss deine Kennzahlen, dokumentiere die Regeln kurz und halte das System einfach. So wird Caching von einer Unsicherheit zu einer starken Konstante deiner Performance.