Caching: Was wo wie lange gespeichert wird

Drei Caching-Schichten

Web-Performance kennt drei wesentliche Caches, die zusammenarbeiten:

1. Browser-Cache - im Gerät, nach Cache-Control-Header
2. CDN/Edge-Cache - nah am User, geteilt zwischen vielen Usern
3. Application-Cache - auf dem Origin-Server, Redis/Memcached

Richtig kombiniert reduzieren sie die Server-Last und die Antwortzeiten massiv.

Cache-Control: die wichtigsten Direktiven

Direktive	Bedeutung	Wann nutzen
public	Auch CDNs dürfen cachen	Statische Assets
max-age=N	Frische in Sekunden	Immer setzen
immutable	Browser revalidiert nie	Hash-versionierte Assets
stale-while-revalidate=N	Stale-Response sofort, im Hintergrund aktualisieren	API-Responses mit Toleranz
private	Nur Browser, kein CDN	Persönliche Daten
no-cache	Immer revalidieren mit ETag	HTML-Dokumente
no-store	Gar nicht cachen	Auth-Tokens, Zahlungen

Typische Caching-Konfiguration

# Hash-versionierte JS/CSS (z.B. main.a4f7b3.js):
Cache-Control: public, max-age=31536000, immutable

# Bilder ohne Hash:
Cache-Control: public, max-age=604800

# HTML:
Cache-Control: no-cache

# API-Responses:
Cache-Control: public, max-age=60, stale-while-revalidate=300

Cache-Busting via Hash-Filenames

Asset-Filenames mit Content-Hash (main.a4f7b3.js) erlauben aggressives Caching: Datei ändert sich → neuer Hash → neuer Filename → Browser lädt frisch. Die alte Datei bleibt im Cache, aber wird nie wieder referenziert. Build-Tools wie Vite, Webpack, esbuild machen das automatisch.

Service Worker für Offline-First

Ein Service Worker abonniert sich beim Browser und kann Network-Requests abfangen. Klassisches Pattern: Cache-First für Assets, Network-First für API-Daten:

// Asset-Request: aus Cache, fallback Network
self.addEventListener('fetch', (e) => {
  if (e.request.url.includes('/assets/')) {
    e.respondWith(
      caches.match(e.request).then(r => r || fetch(e.request))
    );
  }
});

Vorsicht: Service Worker sind mächtig aber auch fehleranfällig. Update-Strategien (skipWaiting, clientsClaim) müssen sauber durchdacht sein.

Stale-While-Revalidate

SWR ist das Beste-aus-zwei-Welten Pattern: Server liefert sofort die alte (stale) Response aus dem Cache, und triggert im Hintergrund eine Aktualisierung. Der User wartet 0 ms, beim nächsten Request hat er den frischen Content. Geht über HTTP-Header (Cache-Control) und über Libraries wie SWR/React Query auf Client-Seite.