JavaScript und CSS aktualisieren, ohne alte Cache-Versionen auszuliefern

HTML und versionierte Dateien getrennt behandeln

HTML ist ein kleines Manifest. Version A verweist auf app.4c21.js und site.19ab.css; B auf app.9d80.js und bei unveränderten Bytes weiterhin denselben CSS-Namen. Die Hashes sind erfundene Beispielnamen.

Unveränderte Dateien werden wiederverwendet, geänderte erhalten eine neue Cache-Identität. Ein Jahr lang gespeichertes HTML kann weiterhin alte URLs anfordern und die neue Veröffentlichung verbergen.

Cache-Direktiven passend zum Vertrag setzen

Für öffentliche Dateien, deren Bytes unter dieser URL nie wechseln, können langes max-age und immutable passen. Bei HTML erlaubt no-cache die Speicherung, verlangt aber Prüfung vor Wiederverwendung. no-store fordert dagegen keine Speicherung. Entscheide je Ressource.

Die Header zeigen eine mögliche Strategie. Prüfe tatsächliche öffentliche Antworten und die Konfiguration des CDN-Caches. Lokale Konfiguration beweist nicht, welche Regeln Browser und CDN erhalten.

Versioned public asset: /assets/app.9d80.js
Cache-Control: public, max-age=31536000, immutable

HTML document: /index.html
Cache-Control: no-cache

The URL /assets/app.9d80.js must continue to serve the same bytes.

Abfrageversionen nur mit passendem Cache-Schlüssel nutzen

/app.js?v=release-b kann eine andere Identität als /app.js?v=release-a haben, wenn alle beteiligten Caches den Parameter berücksichtigen. Ignoriert eine CDN-Regel Abfragen, können beide dasselbe Objekt liefern.

Zufallswerte bei jedem Aufruf verhindern sinnvolle Wiederverwendung. Ein stabiler Hash oder Versionswert ändert sich mit dem Inhalt. Fragmente wie /app.js#release-b gehen nicht in die HTTP-Anfrage und eignen sich dafür nicht.

Die Schicht mit alten Bytes finden

Vergleiche HTML, referenzierte URL und gelieferte Bytes. Bei altem Hash im Dokument prüfe dessen Aktualität. Bei neuer URL mit altem Inhalt prüfe Bereitstellung, Cache-Schlüssel und Ursprung. Stimmen Netzantworten, untersuche eine schon laufende Seite oder einen service worker.

Eine CDN-Leerung löscht keine frischen Antworten aus allen Browsern. Hartes Neuladen ist nur eine lokale Diagnose. Halte fest, welche Cache-Schicht du umgangen hast, damit der Erfolg reproduzierbar bleibt.

• Endgültige HTML-URL und referenzierte Skript- oder CSS-URL erfassen.
• Status, Content-Type, Cache-Control, ETag und Cache-Header prüfen.
• Erwartete Bytes statt einer HTML-Ersatzseite bestätigen.
• Cache-Regeln eines vorhandenen service workers separat prüfen.
• Frischen Besuch und eine über den Wechsel offene Seite testen.

Alte Seiten und Rückkehr zur Vorversion ermöglichen

Lade neue Dateien vor dem verweisenden HTML hoch oder schalte die gesamte Veröffentlichung atomar um. Behalte Vorgängerdateien für gespeichertes HTML und offene Tabs; Module können erst Stunden später angefragt werden.

Veröffentliche B mit Dateien von A und B, prüfe B und ermögliche den Rückweg zu A. Sofortiges Löschen von app.4c21.js beschädigt alte Dokumente. Neue Bytes unter diesem Namen verletzen den Inhaltsvertrag und machen Rücknahmen unberechenbar.

Wiederverwendung nach der Funktionsprüfung messen

Prüfe Erstbesuch, Wiederbesuch und neue Version: anfängliche Übertragung, zulässige Wiederverwendung und danach nur geänderte Dateien. Untersuche echte Transfers einschließlich Validierungsanfragen.

Cache-Ersparnis und Übertragungsrechner vergleichen ausdrückliche Annahmen zu Trefferrate, Anfragen und Größe. Sie ersetzen weder öffentliche Headerprüfung noch Messung der tatsächlichen Trefferrate.