Browser zeigt nach dem Deployment die alte Version
Die neue Version ist online, der Browser zeigt die alte. Cache und Service Worker liefern hartnäckig weiter, was sie gespeichert haben.
Aufwand:
ca. 30 Min.
Das Symptom
Das Deployment ist durch, der Server liefert nachweislich die neue Version aus – und
der Browser zeigt stur die alte. Ein Neuladen hilft nicht. Ein hartes Neuladen
manchmal auch nicht. Auf dem Handy eines Kollegen ist alles korrekt.
Die „Layer 8“-Wahrheit
Der klassische Reflex an dieser Stelle: „Bei mir muss irgendwas kaputt sein“, gefolgt
vom Leeren sämtlicher Browserdaten. Das funktioniert dann tatsächlich – und ist
trotzdem keine Lösung, denn die Besucher der Seite werden das nicht tun. Sie werden
einfach die alte Version sehen und annehmen, es habe sich nichts geändert.
Zwei Schichten sind hier am Werk. Die erste ist der normale Cache, der brav tut, was
ihm gesagt wurde: Wenn die Auslieferungsregeln sagen, eine Datei sei eine Stunde
gültig, dann fragt der Browser eine Stunde lang nicht nach. Die zweite Schicht ist
tückischer. Ein Service Worker sitzt noch vor dem Cache, fängt die Anfrage ab und
beantwortet sie aus seinem eigenen Speicher – bei jedem gewöhnlichen Neuladen. Nur
ein erzwungenes Neuladen umgeht ihn, und das nur für diesen einen Aufruf: Beim nächsten
normalen Laden übernimmt er wieder, und selbst seine neue Fassung wartet, bis alle Tabs
der Seite geschlossen sind. Genau deshalb taucht die alte Version wieder auf, kaum dass
ein genervter Entwickler sie für erledigt hielt.
Die Lösung ist nicht, das Caching abzuschalten – das macht die Seite für alle
langsam, um ein Problem zu lösen, das nur beim Deployment auftritt. Die Lösung ist,
das Ausliefern der falschen Datei technisch unmöglich zu machen: Prüfsumme im
Dateinamen, langes Caching für diese Dateien, kein Caching für das HTML, das auf sie
zeigt. Dann kann der Browser gar nicht anders, als das Neue zu holen.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Zuerst prüfen, was der Server ausliefert
Bevor der Browser verdächtigt wird, muss klar sein, ob die neue Version überhaupt beim Server angekommen ist. Ein Abruf ohne Browser zeigt die Wahrheit – ist dort noch die alte Version, liegt es nicht am Cache.
curl -s -I https://example.com/
2.
Einen harten Neuladeversuch machen
Ein Neuladen unter Umgehung des Caches, oder ein Aufruf im privaten Fenster, zeigt schnell, ob der lokale Cache die Ursache ist. Das ist eine Diagnose, keine Lösung – die Besucher der Seite tun das nämlich nicht.
3.
An den Service Worker denken
Ein registrierter Service Worker liefert Inhalte aus seinem eigenen Speicher aus, auch bei jedem gewöhnlichen Neuladen. Ein erzwungenes Neuladen (Umschalt+Neu laden, Strg+Umschalt+R) umgeht ihn dagegen für diesen einen Aufruf. Zeigt die Seite danach die neue Version und beim nächsten normalen Aufruf wieder die alte, ist er der Verdächtige. Selbst seine neue Fassung wird erst aktiv, wenn alle Tabs der Seite geschlossen sind; Microsoft schreibt dazu: „It isn't sufficient to refresh the tab displaying the app, even if it's the only tab displaying the app.“ und nennt das ausdrücklich Standardverhalten der Webplattform.
4.
Dateinamen mit Prüfsumme verwenden
Die saubere Lösung ist nicht, Caching abzuschalten, sondern es unmöglich zu machen, die falsche Datei zu liefern: Jede gebaute Datei bekommt eine Prüfsumme im Namen. Ändert sich der Inhalt, ändert sich der Name – und der Browser muss neu laden.
5.
Die Cache-Regeln richtig setzen
Die Regel dahinter ist einfach: Dateien mit Prüfsumme im Namen dürfen sehr lange zwischengespeichert werden. Das HTML-Dokument, das auf sie verweist, darf das nicht. Wer beides gleich behandelt, bekommt genau dieses Problem.
6.
Den Cache des Anbieters leeren
Zwischen Server und Browser sitzt oft noch ein Zwischenspeicher des Hosters oder eines Auslieferungsnetzwerks. Auch dieser muss nach einem Deployment aufgeräumt werden, sonst liefert er die alte Version weiter.
Häufige Fragen (FAQ)
?Warum hilft nicht einmal ein hartes Neuladen?
Dann liegt die alte Version vermutlich gar nicht im Browser. Ein erzwungenes Neuladen umgeht nicht nur den Browser-Cache, sondern für diesen Aufruf auch einen Service Worker. Bleibt die alte Version trotzdem, liefert sie ein Zwischenspeicher davor aus – beim Hoster oder im Auslieferungsnetzwerk – oder der Server selbst, was Schritt 1 klärt. Anders liegt der Fall, wenn das harte Neuladen hilft und die alte Version beim nächsten normalen Aufruf zurückkehrt: Dann fängt ein Service Worker die Anfragen ab und beantwortet sie aus seinem eigenen Speicher. Ihn muss man gezielt aktualisieren oder abmelden.
?Soll ich Caching einfach ganz abschalten?
Nein. Damit wird jede Seite bei jedem Aufruf komplett neu geladen – langsam für die Nutzer und teuer für den Server. Der richtige Weg sind Dateinamen mit Prüfsumme: Caching bleibt aktiv, kann aber nie die falsche Datei ausliefern.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Die Konsole meldet einen CORS-Fehler und die Anfrage scheitert? Nicht der Browser ist schuld — der Server muss den Zugriff von deiner Herkunft erlauben.
SWLästigMixed Content: The page at … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.