Cache-Control — was ist das, Direktiven und Cache-Verwaltung

Was ist Cache-Control?

Cache-Control ist ein HTTP-Header, standardisiert in HTTP/1.1 (RFC 7234), der es dem Server ermöglicht, anzugeben, wie und wie lange Clients, Proxys und CDNs die Antwort zwischenspeichern dürfen. Im Gegensatz zu Expires (HTTP/1.0) verwendet Cache-Control Direktiven — Textbefehle, die durch Kommas getrennt werden: Cache-Control: public, max-age=3600, must-revalidate. Der Header bietet eine fein abgestimmte Kontrolle über jedes Glied der Caching-Kette.

Caching ist einer der grundlegenden Mechanismen für die Leistung von Web- und Mobilanwendungen. Ohne ihn würde jede Benutzeranfrage direkt zum Server gehen, was zu übermäßiger Last und Latenz führen würde. Cache-Control definiert drei Caching-Ebenen: Browser/Anwendung (privater Cache), Proxy-Server (gemeinsamer Cache) und CDN (verteilter Cache). Jede Ebene interpretiert die Direktiven unterschiedlich.

Eine falsche Cache-Control-Konfiguration ist eine der häufigsten Ursachen für Leistungsprobleme. Zu aggressives Caching führt dazu, dass Benutzer veraltete Daten sehen. Zu schwaches Caching führt zu übermäßigen Serveranfragen und langsamem Laden. Laut Akamai (2025) reduziert die Optimierung von Cache-Control für statische Inhalte die Serverlast um 70-90% und verbessert die Ladezeit für mobile Benutzer um 40-60%.

Geschichte des Headers

Cache-Control erschien in HTTP/1.1 (RFC 2616, 1999) als Ersatz für Expires. Expires hatte ein grundlegendes Problem: Es verwendete ein absolutes Datum, das von den Zeitzonen des Servers und des Clients abhing. Cache-Control löste dieses Problem, indem es auf relative Zeit umstellte (max-age in Sekunden ab dem Zeitpunkt des Antwortempfangs). Später wurden in RFC 7234 (2014) neue Direktiven hinzugefügt: immutable für statische Assets, stale-while-revalidate und stale-if-error für verzögerte Überprüfung.

Cache-Control Direktiven

Cache-Control umfasst mehr als 10 Direktiven, die in drei Gruppen unterteilt sind: Anfragedirektiven (Client → Server), Antwortdirektiven (Server → Client) und Erweiterungen. In der Praxis verwendet die mobile Entwicklung 6-7 Hauptantwortdirektiven, die 95% der Caching-Szenarien abdecken. Sehen wir uns jede mit Beispielen und Empfehlungen an.

max-age ist die wichtigste Direktive. Sie verbietet dem Client, für die angegebene Zeit eine Anfrage an den Server zu stellen. Für statische Assets (CSS, JS, Bilder) wird max-age normalerweise von 1 Tag bis 1 Jahr eingestellt. Für API-Antworten — von 0 Sekunden (immer aktuelle Daten) bis 5-10 Minuten (Referenzdaten). s-maxage ermöglicht es, unterschiedliche Lebensdauern für CDN und Browser festzulegen: Die CDN speichert eine Kopie für 1 Tag, der Browser für 1 Stunde.

no-cache vs no-store

Diese beiden Direktiven werden oft verwechselt. no-cache verbietet das Caching nicht — es erfordert eine Überprüfung der zwischengespeicherten Kopie bei jeder Verwendung durch eine bedingte Anfrage (If-Modified-Since oder If-None-Match). Wenn der Server mit 304 antwortet — verwendet der Client den Cache. Bei 200 — aktualisiert er ihn. no-store hingegen verbietet vollständig das Speichern der Antwort in einem Cache, einschließlich Festplatte und Arbeitsspeicher. Verwenden Sie no-store nur für sensible Daten — Tokens, Zahlungsdaten, persönliche Dokumente.

Cache-Control vs Expires

Der Expires-Header (HTTP/1.0) gibt ebenfalls die Lebensdauer der Ressource an, verwendet jedoch ein absolutes Datum: Expires: Thu, 03 Jul 2026 12:00:00 GMT. Cache-Control max-age verwendet die relative Zeit ab dem Zeitpunkt der Antwort. Der Unterschied ist für verteilte Systeme kritisch: Wenn sich Server und Client in verschiedenen Zeitzonen befinden, kann Expires falsch interpretiert werden. Cache-Control hat dieses Problem nicht — 3600 Sekunden sind immer 3600 Sekunden.

Wenn beide Header vorhanden sind, hat Cache-Control Priorität gegenüber Expires. Dies ist in RFC 7234 definiert: „Wenn eine Antwort ein Cache-Control-Feld mit der max-age-Direktive enthält, MUSS der Empfänger das Expires-Feld ignorieren.“ In der Praxis wird empfohlen, Expires für moderne Clients gar nicht zurückzugeben, da Cache-Control alle Expires-Szenarien abdeckt. Für die Abwärtskompatibilität mit alten Proxys und Browsern können jedoch beide Header zurückgegeben werden.

Expires hat sich hauptsächlich für statische Inhalte auf Nginx und Apache erhalten — diese Server fügen automatisch beide Header hinzu. Wenn Ihr Projekt Expires ohne Cache-Control begegnet, ersetzen Sie es durch Cache-Control mit max-age: Die Genauigkeit der Cache-Steuerung verbessert sich und die Abhängigkeit von der Zeitzone wird beseitigt. Für die Migration reicht es aus, den Server so zu konfigurieren, dass er Cache-Control anstelle von Expires hinzufügt.

# Nginx: Cache-Control für statische Dateien
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# Verschiedene Richtlinien für verschiedene Inhaltstypen
location /api/config {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

location /api/static-data {
    expires 5m;
    add_header Cache-Control "public, max-age=300";
}

In der Nginx-Konfiguration werden statische Dateien (CSS, JS, Bilder) mit Cache-Control für 30 Tage mit dem Attribut immutable festgelegt — dieses Attribut teilt dem Browser mit, dass sich die Ressource unter dieser URL nie ändert (Versionierung über Hash im Dateinamen). API-Endpunkte verwenden no-cache für dynamische Daten und public mit kurzem max-age für Referenzdaten — häufig angefragte und selten wechselnde Listen.

Caching in mobilen Anwendungen

In mobilen Anwendungen spielt Cache-Control aufgrund der Einschränkungen mobiler Netzwerke eine besondere Rolle: hohe Latenz, instabile Verbindung, Datenlimits. Richtiges Caching ermöglicht es, Daten sofort anzuzeigen, sogar offline, und sie im Hintergrund zu aktualisieren. OkHttp auf Android und URLSession auf iOS verfügen über integrierte Caching-Systeme, die Cache-Control berücksichtigen.

OkHttp verwendet CacheInterceptor, der Cache-Control aus der Antwort liest und das Caching automatisch verwaltet. Wenn der Server Cache-Control: max-age=3600 zurückgibt, stellt OkHttp eine Stunde lang keine Anfrage an den Server. Nach Ablauf von max-age sendet OkHttp eine bedingte Anfrage mit If-Modified-Since und If-None-Match. Cache-Konfiguration in OkHttp: OkHttpClient.Builder().cache(Cache(directory, maxSize)).

fun createCachedClient(cacheDir: File): OkHttpClient {
    return OkHttpClient.Builder()
        .cache(Cache(cacheDir, 10L * 1024 * 1024))
        .addNetworkInterceptor { chain ->
            val response = chain.proceed(chain.request())
            response.newBuilder()
                .header("Cache-Control",
                    "public, max-age=300")
                .removeHeader("Pragma")
                .build()
        }
        .build()
}

Der Code erstellt einen OkHttpClient mit einem 10 MB Cache und überschreibt Cache-Control über NetworkInterceptor. Wenn der Server kein Cache-Control zurückgibt oder Expires verwendet, fügt der Interceptor public, max-age=300 (5 Minuten) hinzu. Der Interceptor entfernt den veralteten Pragma-Header (HTTP/1.0) für die Kompatibilität. Das Caching auf iOS funktioniert ähnlich über URLCache.shared mit den Einstellungen memoryCapacity und diskCapacity.

Offline-Modus und stale-while-revalidate

Die Direktive stale-while-revalidate ermöglicht es, dem Benutzer einen veralteten Cache anzuzeigen, während die Anwendung im Hintergrund neue Daten abruft. Dies sorgt für einen sofortigen Reaktionseffekt: Der Benutzer sieht den Inhalt sofort, und nach einer Sekunde wird er auf die aktuelle Version aktualisiert. Unterstützt von OkHttp ab Version 3.10 und URLCache auf iOS 14+. Beispiel: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 Stunde aktueller Cache, dann 5 Minuten Anzeige veralteter Daten mit Hintergrundaktualisierung.

Cache-Control Konfigurationsbeispiele

Verschiedene Ressourcentypen erfordern unterschiedliche Caching-Strategien. Sehen wir uns optimale Konfigurationen für typische Szenarien in der mobilen Entwicklung an. Für statische Inhalte mit einem Hash im Dateinamen (bundle.abc123.js) können Sie max-age bis zu 1 Jahr mit immutable einstellen. Für API-Listen, die selten aktualisiert werden (Verzeichnisse, Kategorien) — max-age von 5 Minuten bis 1 Stunde mit stale-while-revalidate.

Wichtig ist, die Sicherheit zu beachten: Für Antworten, die persönliche Benutzerdaten enthalten, immer private setzen. Ohne diese Direktive kann ein öffentlicher Proxy (z. B. im Unternehmen) die Antwort zwischenspeichern und einem anderen Benutzer ausliefern. Für Authentifizierungstokens und Zahlungsinformationen verwenden Sie no-store — selbst ein privater Cache sollte diese Daten nicht auf der Festplatte speichern.

Cache-Debugging

Um die Korrektheit von Cache-Control zu überprüfen, verwenden Sie den Age-Header (wie viele Sekunden der Cache gespeichert wurde) und X-Cache (Hit/Miss auf CDN). Im Browser — der Tab Netzwerk, die Spalte Size zeigt „von Festplattencache“ oder „304 Not Modified“. Wenn eine Ressource zwischengespeichert werden sollte, aber jedes Mal geladen wird, überprüfen Sie, ob der Server Cache-Control: no-cache oder Pragma: no-cache zusammen mit Ihren Direktiven hinzufügt.