Cache und Inhaltsstempel.
Cache-Header geben an, wie lange eine Ressource gespeichert werden darf; der Inhaltsstempel sorgt dafür, dass sich mit der Ressource auch ihre Adresse ändert.
Eine Ressource kein zweites Mal zu laden ist immer besser, als sie schnell zu laden. Der Cache leistet das, und richtig aufgesetzt drückt er die Netzkosten wiederholter Besuche auf fast null. Falsch aufgesetzt verbreiten sich entweder die Aktualisierungen nicht, oder der Cache arbeitet gar nicht.
Die Spannung passt in einen Satz: Ein langer Cache ist schnell, aber Aktualisierungen verbreiten sich nicht; ein kurzer ist frisch, aber langsam. Die meisten Teams wählen einen Wert in der Mitte und sammeln beide Nachteile zugleich ein.
Der Stempel: die Lösung, die die Spannung beseitigt
Die richtige Lösung ist nicht der Mittelwert, sondern das vollständige Beseitigen der Spannung. Die Methode: Die Adresse der Ressource trägt einen aus ihrem Inhalt abgeleiteten Stempel. Ändert sich der Inhalt, ändert sich der Stempel, also die Adresse — und der Browser sieht eine neue Ressource und lädt sie.
Steht das, kann die Cache-Dauer nahezu unendlich sein — ein Jahr ist ein typischer Wert. Ändert sich die Ressource nie, wird sie nie neu geladen; ändert sie sich, lädt sie sofort unter ihrer neuen Adresse. Weder veralteter Inhalt noch unnötiges Laden.
Dass der Stempel aus dem Inhalt kommt, ist kritisch. Wird eine zufällige Versionsnummer oder die Build-Zeit verwendet, ändert sich die Adresse bei jedem Deployment, auch wenn der Inhalt gleich blieb — und der Cache ist verschenkt. Der Stempel muss aus den eigenen Bytes der Datei berechnet werden.
Auf dieser Website arbeitet der Stempel genau so: Jeder Stil- und Skriptlink trägt einen aus dem Dateiinhalt berechneten Stempel. Ändert sich die Datei nicht, ändert sich die Adresse nicht; ändert sie sich, ganz sicher.
Leitet sich der Stempel nicht aus dem Inhalt ab, ist der Cache bei jedem Deployment verschenkt.
Warum er nötig ist, wurde gemessen
Diese Regel kam nicht als Theorie, sondern als Regel nach einem Vorfall hinzu. Als lang gecachte Dateien ohne Stempel ausgeliefert wurden, konnte neues HTML auf alte Stile treffen — der Nutzer sah die aktualisierte Seite im alten Gewand.
Das ist die heimtückischste Art von Cache-Fehler: keine Fehlermeldung, die Seite funktioniert, sie sieht nur falsch aus. Und es geschieht nur bei Nutzern, die die Website VORHER besucht haben — die Entwicklung testet im privaten Fenster und sieht nie etwas.
Seit der Stempel steht, ist diese Fehlerklasse strukturell unmöglich. HTML und Stil können sich nicht mehr trennen, denn das HTML trägt die gestempelte Adresse des Stils.
Welche Politik für welche Ressource
- Gestempelte Stile und Skripte — sehr langer Cache, die Unveränderlich-Markierung. Ein Jahr ist typisch.
- HTML-Seiten — kurzer oder validierender Cache. Die Seite selbst lässt sich nicht stempeln, denn ihre Adresse muss dauerhaft sein.
- Bilder — gestempelt lang; ungestempelt mittel.
- Schriften — sehr lang. Sie ändern sich selten.
- Sitemap und robots — kurz. Sie können häufige Aktualisierung brauchen.
- API-Antworten — je nach Fall; meist ungecacht.
Der zweite Punkt zeigt eine Grenze: Die HTML-Seite lässt sich nicht stempeln, denn ihre Adresse ist die dem Nutzer gegebene und muss dauerhaft sein. Seiten bekommen deshalb entweder eine kurze Dauer oder einen Validierungsmechanismus — der Browser fragt, und sagt der Server „unverändert“, wird nicht geladen.
Auf dieser Website ist die Politik nach dieser Trennung gebaut: gestempelte Ressourcen lang und unveränderlich markiert, Seiten kurz. Die zwei Gruppen sind getrennt definiert und mischen sich nicht.
Die Unveränderlich-Markierung
Zusätzlich zur langen Cache-Dauer gibt es eine besondere Markierung, die erklärt, dass sich die Ressource nie ändern wird. Sie sagt dem Browser: Diese Ressource muss nicht einmal neu validiert werden — liegt sie im Cache, verwende sie direkt.
Der Unterschied ist fein, aber real. Ohne die Markierung kann der Browser beim Neuladen der Seite eine Anfrage senden, ob die Ressource noch gültig ist; der Server antwortet „unverändert“, geladen wird nicht — aber ein Umlauf ist verbraucht. Mit der Markierung geschieht diese Anfrage gar nicht.
Die Markierung gehört nur auf gestempelte Ressourcen. Eine Ressource mit fester Adresse unveränderlich zu nennen blockiert die Verbreitung von Aktualisierungen vollständig — und es bleibt keine Lösung, als dass der Nutzer den Cache von Hand leert. Zusammen mit dem Stempel ist sie völlig sicher: Ändert sich der Inhalt, ändert sich auch die Adresse, und die alte Ressource wird nie wieder angefragt.
Auf dieser Website sind die Stil- und Skriptdateien gestempelt UND unveränderlich markiert. Zusammen heißt das: null Netzverkehr für diese Ressourcen bei wiederholten Besuchen.
Eine praktische Checkliste
Übersetzt man diese Seite in einen Prüfschritt, ist an der Cache-Politik Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.
- Sind Stile und Skripte gestempelt?
- Leitet sich der Stempel aus dem Inhalt ab — nicht aus der Build-Zeit.
- Bekommen die Gestempelten langen Cache und die Unveränderlich-Markierung?
- Gilt für die HTML-Seiten eine kurze oder validierende Politik?
- Sind Sitemap und robots kurz?
- Ist die Politik an einer Stelle definiert — verstreute Definitionen driften auseinander.
Der zweite Punkt ist der kritischste: Leitet sich der Stempel nicht aus dem Inhalt ab, ist der Cache bei jedem Deployment verschenkt, und die lange Dauer bedeutet nichts.
Leitet sich der Stempel nicht aus dem Inhalt ab, ist der Cache bei jedem Deployment verschenkt.
Eine Fallerinnerung zum Schluss: Auf dieser Website kam die Stempelregel nicht als Theorie, sondern als Regel nach einem Vorfall hinzu. Als lang gecachte Dateien ohne Stempel ausgeliefert wurden, konnte neues HTML auf alte Stile treffen, und der Nutzer sah die aktualisierte Seite im alten Gewand.
Solche Fehler sind besonders heimtückisch, weil sie nur bei Nutzern auftreten, die die Website VORHER besucht haben. Die Entwicklung testet im privaten Fenster, alles wirkt richtig, und die echten Nutzer sehen die kaputte Seite. Seit der Stempel steht, ist diese Fehlerklasse strukturell unmöglich — das HTML trägt die gestempelte Adresse des Stils, die zwei können sich nicht trennen.
Eine letzte Konfigurationsnotiz: Die Cache-Politik sollte an einer einzigen Stelle definiert sein. Über Schichten verstreute Definitionen — Server, Edge-Netz, Anwendung — driften mit der Zeit auseinander, und welche gewinnt, wird unklar. Auf dieser Website lebt die Politik in einer einzigen Header-Datei, mit klar getrennten Gruppen: gestempelte Ressourcen lang und unveränderlich, Seiten kurz. Die Trennung liest sich auf einen Blick — und diese Lesbarkeit ist das, was die Person, die nach einem Jahr zur Datei zurückkehrt, am meisten braucht.