HTTP-Caching-Leitfaden: Website beschleunigen ohne zusätzliche Infrastruktur

Serverracks in einem Rechenzentrum

Caching ist die einzelne wirkungsvollste Performance-Optimierung, die Sie vornehmen können. Eine gecachte Antwort wird in Mikrosekunden ausgeliefert, verursacht keine Kosten und erfordert keinerlei Serververarbeitung. Dennoch cachen die meisten Anwendungen entweder zu aggressiv (und liefern veraltete Inhalte) oder gar nicht (und verschwenden Bandbreite und Rechenleistung). Wenn Sie HTTP-Caching verstehen, wird es von einer Fehlerquelle zu einem echten Vorteil.

So funktioniert HTTP-Caching

Wenn ein Browser oder CDN eine Antwort empfängt, prüft er die Header, um zu entscheiden, ob und wie lange diese gecacht werden soll. Bei der nächsten Anfrage für dieselbe Ressource kann die gecachte Kopie ausgeliefert werden – ohne Ihren Server überhaupt zu kontaktieren.

Der Cache-Lebenszyklus hat zwei Phasen:

Frische – Ist die gecachte Kopie noch gültig? Wird durch Cache-Control: max-age oder Expires bestimmt.
Validierung – Falls veraltet: Können wir beim Server bestätigen, dass sich der Inhalt nicht geändert hat? Wird durch ETag oder Last-Modified bestimmt.

Cache-Control: die primäre Caching-Direktive

Cache-Control ist der mächtigste Caching-Header. Er ist eine kommagetrennte Liste von Direktiven:

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

Wichtige Direktiven

Direktive	Bedeutung
`public`	Jeder Cache (Browser, CDN, Proxy) darf diese Antwort speichern
`private`	Nur der Browser des Endbenutzers darf cachen (keine CDNs)
`no-cache`	Muss vor jeder Verwendung beim Server revalidiert werden (nicht „nicht cachen")
`no-store`	Niemals cachen – für sensible Daten
`max-age=N`	Für N Sekunden cachen
`s-maxage=N`	CDN-spezifisches maximales Alter (überschreibt `max-age` für geteilte Caches)
`immutable`	Inhalt ändert sich nie – Revalidierung vollständig überspringen
`must-revalidate`	Bei veralteten Inhalten vor der Auslieferung revalidieren
`stale-while-revalidate=N`	Veraltete Inhalte für N Sekunden ausliefern, während im Hintergrund frische Inhalte abgerufen werden

⚠️ no-cache bedeutet NICHT „nicht cachen". Es bedeutet „cachen, aber immer prüfen, ob es noch gültig ist." Verwenden Sie no-store, wenn Sie etwas wirklich niemals cachen möchten.

Caching-Strategie nach Ressourcentyp

Verschiedene Ressourcen benötigen unterschiedliche Strategien:

Statische Assets mit Content-Hashing (CSS, JS, Bilder)

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

Wenn Ihr Build-Tool einen Hash zu Dateinamen hinzufügt (main.a3f9b2c.js), ändert sich die URL bei Inhaltsänderungen. Für immer cachen – jede neue Version erhält eine neue URL.

HTML-Seiten

Cache-Control: no-cache

Oder mit kurzem TTL:

Cache-Control: public, max-age=60, stale-while-revalidate=3600

HTML ändert sich häufig und verweist auf die gehashten Assets. Kurz cachen oder Revalidierung erzwingen.

API-Antworten

# Öffentliche Daten (z. B. Produktkatalog)
Cache-Control: public, max-age=300, stale-while-revalidate=600

# Benutzerspezifische Daten
Cache-Control: private, max-age=60

# Echtzeit-Daten (Aktienkurse, Live-Ergebnisse)
Cache-Control: no-store

Sensible Daten (Authentifizierung, Zahlungen)

Cache-Control: no-store

Niemals cachen. Punkt.

ETags und bedingte Anfragen

Wenn eine gecachte Antwort abläuft, verwirft der Browser sie nicht einfach – er fragt den Server, ob sie noch gültig ist. Das nennt sich Revalidierung.

ETags

Ein ETag ist ein Fingerabdruck des Antwortinhalts:

# Server sendet:
ETag: "a3f9b2c8d4e1"

# Nächste Anfrage des Browsers:
If-None-Match: "a3f9b2c8d4e1"

# Falls unverändert, antwortet der Server:
HTTP/1.1 304 Not Modified
(kein Body – spart Bandbreite)

# Falls geändert, antwortet der Server:
HTTP/1.1 200 OK
ETag: "b7c2d4e9a1f3"
(vollständige neue Antwort)

Eine 304 Not Modified-Antwort hat keinen Body – nur Header. Das spart die gesamte Bandbreite für das erneute Herunterladen des Inhalts.

Last-Modified

Ähnlich, verwendet aber einen Zeitstempel statt eines Hashes:

Last-Modified: Tue, 01 Apr 2026 10:00:00 GMT

# Browser sendet:
If-Modified-Since: Tue, 01 Apr 2026 10:00:00 GMT

ETags sind zuverlässiger (Zeitstempel können bei load-balancierten Servern ungenau sein).

Vary-Header: Cache pro Anfragevariante

Der Vary-Header teilt Caches mit, welche Anfrage-Header die Antwort beeinflussen:

Vary: Accept-Encoding

Dadurch wird eine separate Kopie für gzip- und br-Antworten gecacht. Häufige Verwendungen:

Vary: Accept-Encoding          # Separate Caches für komprimierte/unkomprimierte Inhalte
Vary: Accept-Language          # Separate Caches pro Sprache
Vary: Accept                   # Separate Caches für JSON- vs. HTML-Antworten

⚠️ Vary: Cookie oder Vary: Authorization deaktiviert das CDN-Caching effektiv – CDNs können benutzerspezifische Antworten nicht cachen.

stale-while-revalidate: Hintergrund-Aktualisierung

Eines der nützlichsten modernen Caching-Muster:

Cache-Control: max-age=60, stale-while-revalidate=600

In den ersten 60 Sekunden sofort aus dem Cache ausliefern (frisch)
Bei Anfragen zwischen 60–660 Sekunden: die veraltete Kopie sofort ausliefern, aber im Hintergrund eine frische Version abrufen
Nach 660 Sekunden: vor der Auslieferung muss revalidiert werden

Benutzer erhalten immer eine schnelle Antwort. Der Cache bleibt aktuell, ohne dass jemand auf einen Netzwerk-Roundtrip warten muss.

CDN-Caching-Überlegungen

CDNs (Cloudflare, CloudFront, Fastly) respektieren Cache-Control-Header, fügen aber eine eigene Komplexitätsebene hinzu:

s-maxage ermöglicht unterschiedliche TTLs für CDN und Browser:
```
Cache-Control: public, max-age=60, s-maxage=86400
```
Browser cacht für 1 Minute; CDN cacht für 24 Stunden.
Cache-Purging – Bei einem Deployment den CDN-Cache für aktualisierte Assets leeren. Die meisten CDNs bieten API-basiertes Purging an.
Cache-Keys – CDNs cachen basierend auf URL + Vary-Headern. Query-Strings sind normalerweise im Cache-Key enthalten.

Cache-Verhalten testen

Verwenden Sie unseren API Request Builder, um Response-Header zu prüfen und sicherzustellen, dass Ihr Caching korrekt funktioniert:

Senden Sie eine Anfrage und prüfen Sie die Cache-Control-, ETag- und Last-Modified-Header
Senden Sie dieselbe Anfrage erneut – prüfen Sie den Age-Header (Sekunden seit dem Cachen) und X-Cache: HIT
Prüfen Sie CF-Cache-Status (Cloudflare) oder X-Cache (CloudFront), um CDN-Caching zu bestätigen

In Chrome DevTools → Netzwerk-Tab → auf eine Ressource klicken → Header-Tab – achten Sie auf from disk cache oder from memory cache in der Antwort.

Nginx-Caching-Konfiguration

Konfigurieren Sie Caching-Header auf Nginx-Ebene für konsistentes Verhalten:

# Statische Assets – für immer cachen
location ~* \.(js|css|woff2|png|jpg|webp|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# HTML – immer revalidieren
location ~* \.html$ {
    add_header Cache-Control "no-cache";
}

# API – kurzer Cache mit stale-while-revalidate
location /api/ {
    add_header Cache-Control "public, max-age=60, stale-while-revalidate=600";
}

Verwenden Sie unseren Nginx Config Generator, um eine vollständige, optimierte Nginx-Konfiguration für Ihren Anwendungsfall zu erstellen.

Caching-Checkliste

Statische Assets (CSS/JS) verwenden inhaltsgehashte Dateinamen + max-age=31536000, immutable
HTML wird mit no-cache oder sehr kurzem max-age ausgeliefert
API-Antworten werden basierend auf der Aktualisierungshäufigkeit gecacht
Sensible Daten verwenden no-store
ETags oder Last-Modified für bedingte Anfragen aktiviert
stale-while-revalidate auf geeigneten API-Endpunkten
CDN-Caching-Header verifiziert und getestet

Richtiges HTTP-Caching lässt Ihre Website für wiederkehrende Besucher sofort erscheinen, reduziert Ihre Bandbreitenkosten und verringert die Serverlast – und das alles ohne zusätzliche Infrastruktur.