hsb.horse
Ich habe mir den Header Cache-Control: max-age=3, must-revalidate genauer angesehen und schreibe mein Verständnis auf, solange es noch frisch ist.
Diese Konfiguration bedeutet: “Nutze den Cache nur sehr kurz, nämlich drei Sekunden, und validiere danach immer wieder gegen den Origin-Server.” Dieser Ansatz wird üblicherweise Micro-Caching genannt. Er wird oft genutzt, um Server bei plötzlichen Lastspitzen zu entlasten und Inhalte trotzdem nahezu in Echtzeit zu halten.
Bedeutung der einzelnen Direktiven
Am einfachsten ist es, beide Direktiven getrennt zu betrachten.
max-age=3
Damit wird Browsern und CDNs gesagt, dass der Inhalt nur drei Sekunden lang als frisch gilt. Während dieses Zeitfensters geht keine Anfrage an den Origin. Die Antwort wird direkt aus dem Cache geliefert.
must-revalidate
Sobald diese drei Sekunden abgelaufen sind, muss der Cache beim Origin nachvalidieren und darf ohne ausdrückliche Bestätigung keinen veralteten Inhalt ausliefern.
Ohne diese Direktive liefern manche Caches oder Konfigurationen unter Umständen alten Inhalt aus, wenn der Origin nicht erreichbar ist. must-revalidate verbietet dieses Verhalten ausdrücklich.
Zeitlicher Ablauf
Am verständlichsten wird es, wenn man den Ablauf beim Laden einer Seite simuliert.
| Zeitpunkt | Aktion | Verhalten | Statuscode |
|---|---|---|---|
| Erster Request | Seite aufrufen | Inhalt vom Origin laden und anzeigen | 200 OK |
| Direkt danach bis 3 Sekunden | Neu laden / navigieren | Keine Anfrage an den Origin. Browser oder CDN liefern aus dem Cache | 200 (from cache) |
| Nach 3 Sekunden | Neu laden / navigieren | Der Cache gilt als abgelaufen. Der Browser sendet eine bedingte Anfrage an den Origin | Netzwerkanfrage |
| → Unverändert | — | Der Server bestätigt, dass sich nichts geändert hat. Der vorhandene Cache wird erneut für 3 Sekunden gültig. Der Response-Body wird nicht neu übertragen | 304 Not Modified |
| → Verändert | — | Der Server liefert die neue Version | 200 OK |
Entscheidend ist der Fall 304 Not Modified nach Ablauf der drei Sekunden. Weil der eigentliche Inhalt nicht erneut geladen wird, bleiben sowohl Bandbreite als auch Latenz gering.
Vorteile dieser Einstellung
Dieser Header ist besonders nützlich, wenn Frische wichtig ist, aber gleichzeitig sehr viel Traffic anfällt. Drei Vorteile sind besonders wichtig.
Deutlich weniger Last auf dem Origin
Stellen wir uns eine Website mit 1.000 Requests pro Sekunde vor. Mit max-age=3 wird, besonders in Kombination mit einem CDN, ein großer Teil der Anfragen aus dem Cache bedient und der Origin muss nur einen kleinen Teil als Validierungsverkehr sehen.
Schon ein Drei-Sekunden-Cache kann unter hoher Last einen großen Unterschied machen.
Fast Echtzeit-Aktualisierung
Neue Informationen werden spätestens nach drei Sekunden sichtbar. Das ist nicht echtes Realtime-Verhalten, aber für viele Anwendungen ein brauchbarer Kompromiss.
Weniger Risiko, veraltete Informationen zu zeigen
Durch must-revalidate kann der Client nach Ablauf der Gültigkeit nicht heimlich mit alten Daten weitermachen. Wenn Genauigkeit wichtig ist, ist das relevant.
Konkrete Einsatzfälle
Ich habe versucht, die Fälle zu sortieren, in denen dieses Muster gut oder schlecht passt.
Geeignete Fälle
- Startseiten und Listen auf Nachrichtenseiten: neue Artikel sollen schnell sichtbar sein, aber wenige Sekunden Verzögerung sind akzeptabel, während Lastspitzen häufig auftreten
- Bestandsanzeigen im E-Commerce: einige Sekunden Verzögerung sind hinnehmbar, aber ausverkaufte Artikel dürfen nicht als verfügbar erscheinen.
must-revalidatehilft dabei - Landingpages für Events oder Kampagnen: direkt nach Veröffentlichung kann starker Traffic über soziale Netzwerke kommen. Micro-Caching fängt die erste Welle ab und erlaubt trotzdem schnelle Aktualisierung
- Zusammenfassungsansichten in Dashboards: nicht so empfindlich wie Echtzeit-Charts, aber aktuelle KPIs sollen sichtbar sein. Wenn das Polling drei Sekunden oder länger ist, kann das gut passen
- Listenartige API-Antworten: mit diesem Header kann die CDN-Schicht Antworten cachen und den Origin entlasten
Ungeeignete Fälle
- Statische Assets wie CSS, JS oder Bilder: sie ändern sich selten. Dateihashes zusammen mit
max-age=31536000,immutablesind meist besser - Blog-Detailseiten: sie werden nach Veröffentlichung normalerweise nicht oft aktualisiert, also ist ein deutlich längerer
max-agesinnvoller - Echtzeit-Chat oder WebSocket-Verkehr: HTTP-Caching passt hier nicht, und selbst drei Sekunden Verzögerung sind zu viel
- Nutzerspezifische Inhalte: bei Seiten wie einem persönlichen Dashboard ist gemeinsames CDN-Caching meist ungeeignet. Hier sollte man z. B.
privateprüfen
Dinge, auf die man achten sollte
Es gibt auch ein paar leicht zu übersehende Trade-offs.
Nach Ablauf kommt alle drei Sekunden wieder eine Anfrage
Nach jedem Drei-Sekunden-Fenster wird zwingend eine bedingte Anfrage gestellt. Im Vergleich zu längeren max-age-Werten fällt Netzwerklatenz dadurch stärker ins Gewicht. Gerade bei langsamen Verbindungen sollte man die UX im Blick behalten.
Verhalten im Offline-Fall
Wegen must-revalidate zeigt der Client wahrscheinlich einen Fehler an, wenn das Netzwerk weg ist oder der Origin ausfällt, selbst wenn noch ein abgelaufener Cache vorhanden ist. Anders gesagt: “Wenn ich die Frische nicht bestätigen kann, schlage ich lieber fehl, statt alte Daten zu zeigen.”
Wenn das zu streng ist, sollte man Direktiven wie stale-while-revalidate oder stale-if-error zusätzlich betrachten.
Zusammenfassung
Cache-Control: max-age=3, must-revalidate ist eine aggressive Balance für Situationen, in denen Frische wichtig ist, man den Origin aber nicht überlasten will.
Der Begriff “Micro-Caching” klingt größer als die eigentliche Maßnahme. Praktisch bedeutet er nur, für ein paar Sekunden zu cachen. Unter hoher Last können genau diese paar Sekunden aber eine sehr große Wirkung haben.
Bevor man diese Strategie einsetzt, sollte man prüfen, ob der Ziel-Use-Case wirklich dazu passt. Bei statischen Assets oder selten aktualisierten Seiten produziert sie sonst nur unnötige Revalidierungsanfragen.