Im Browser-Cache gespeichertes CSS und JavaScript aktualisieren

Wenn ein Deployment CSS oder JavaScript ändert, die URL aber gleich bleibt, können manche Browser eine noch gültige Kopie wiederverwenden. Neue Header kommen erst an, wenn der Browser diese URL erneut anfordert: Der Server kann eine Antwort, die der Client noch für frisch hält, nicht aus der Ferne leeren.

Prüfen Sie zuerst im Tab Netzwerk / Network der Entwicklerwerkzeuge des Browsers, welche URL geladen wird, ihren Status, Cache-Control, Age, ETag und ob der Browser, ein Service Worker oder ein CDN antwortet. So unterscheiden Sie den HTTP-Cache von anderen Ebenen.

Die URL des Assets ändern

Die zuverlässige Lösung ist, jede Version unter einer neuen URL zu veröffentlichen. Verwenden Sie vorzugsweise Dateinamen mit einem Hash des Inhalts:

<link rel="stylesheet" href="https://static.example.com/css/app.abc123.css">
<script src="https://static.example.com/js/app.abc123.js"></script>

Sie können der URL auch eine Version hinzufügen, zum Beispiel /css/app.css?v=20260825, sofern Ihre Anwendung und die zwischengeschalteten Caches Query-Parameter berücksichtigen.

Liefern Sie das nicht versionierte HTML mit Cache-Control: no-cache aus, damit es revalidiert wird und auf die neuen Assets verweist. no-cache erlaubt das Speichern, verlangt aber eine Validierung vor der Wiederverwendung. Behalten Sie ETag oder Last-Modified bei: Damit kann der Server mit 304 Not Modified antworten, ohne eine identische Ressource erneut zu übertragen.

Assets mit Hash können eine lange Ablaufzeit haben, weil sich ihre URL mit dem Inhalt ändert. Wenn ein CDN oder ein Service Worker im Spiel ist, aktualisieren Sie auch dessen Manifest oder führen Sie die gezielte Bereinigung dieser Ebene aus. Lassen Sie globale no-store-Regeln nicht wochenlang bestehen, entfernen Sie keine Validatoren und verwenden Sie Pragma nicht als allgemeinen Ersatz für Cache-Control.

Lesen Sie die Anleitung zu HTTP-Cache und versionierten URLs und die Referenz zu Cache-Control.

Verhindern, dass ein Deployment offene Sitzungen unterbricht

Veröffentlichen Sie zuerst die neuen Dateien und danach das HTML, das auf sie verweist. Behalten Sie die Assets der vorherigen Version für eine Übergangszeit: Ein offener Tab kann sie weiterhin anfordern. Wenn Sie sie sofort löschen, kann das 404-Fehler verursachen, obwohl neue Besuche funktionieren.

Wenn die Anwendung einen Service Worker verwendet, testen Sie eine Aktualisierung mit einem alten und einem neuen offenen Tab. Dynamisches oder privates HTML kann eine andere Richtlinie benötigen als öffentliches HTML; wenden Sie keinen globalen Header an, ohne Sitzungen und sensible Daten zu prüfen.

Prüfen Sie nach dem Deployment die endgültige URL, den empfangenen Inhalt und die Version. Eine 304-Antwort kann korrekt sein, wenn sich die Ressource nicht geändert hat; für sich allein ist sie kein Anzeichen für einen fehlerhaften Cache.