Deployment erfolgreich – warum sehen Nutzer trotzdem die alte Website?

Ein Deployment ist grün. Die Startseite sieht bei Ihnen korrekt aus. Trotzdem melden Kundinnen, Kollegen oder der Vertrieb: „Ich sehe noch die alte Version.“

Das ist oft kein exotischer Browserfehler, sondern ein Cache- und Release-Problem. Alte HTML-Dokumente treffen auf neue Assets, ein CDN liefert unterschiedliche Versionen aus oder personalisierte Antworten landen unter dem falschen Cache-Schlüssel. Die Website ist erreichbar – aber nicht zuverlässig aktuell.

Warum ein erfolgreicher Build noch keinen erfolgreichen Release beweist

Zwischen Repository und Browser liegen mehrere Ebenen: Hosting, Reverse Proxy, CDN, Shared Cache, Browser-Cache und eventuell ein Service Worker. Jede Ebene kann Antworten speichern. Das ist grundsätzlich sinnvoll, wird aber riskant, wenn die Regeln nicht zur Art des Inhalts passen.

Ein typischer Fehler:

1. index.html wird zu lange gecacht.
2. Ein Deployment erzeugt neue JavaScript-Dateien mit neuen Hashes.
3. Einige Nutzer erhalten weiterhin das alte HTML.
4. Die darin referenzierten alten Assets wurden bereits entfernt.
5. Die Seite lädt unvollständig, bleibt weiß oder verliert Funktionen.

Das Gegenteil ist ebenfalls möglich: neues HTML trifft auf alte, nicht versionierte Dateien unter derselben URL.

Die einfache Regel, die viele Setups verletzen

Veränderliche Dokumente und unveränderliche Assets brauchen unterschiedliche Cache-Strategien.

Für versionierte Dateien wie app.8f3a1c.js ist ein langer Cache sinnvoll. Ändert sich der Inhalt, ändert sich die URL. MDN beschreibt dieses Cache-Busting-Muster als Grundlage dafür, solche Ressourcen lange und mit immutable zu speichern.

HTML, API-Antworten, Konfigurationen und personalisierte Seiten brauchen bewusstere Regeln. no-cache bedeutet nicht „niemals speichern“, sondern dass eine gespeicherte Antwort vor Wiederverwendung validiert werden muss. Für wirklich sensible Inhalte kann no-store angemessen sein.

Eine pauschale Regel für die ganze Domain ist deshalb meist falsch.

Fünf Warnzeichen für eine fragile Cache-Strategie

1. Dateien ändern sich, die URL aber nicht

Wenn /assets/app.js bei jedem Deployment überschrieben wird und lange im Cache liegt, können alte und neue Versionen unkontrolliert nebeneinander existieren.

2. HTML wird genauso lange gecacht wie statische Assets

Ein Jahr Cache-Laufzeit ist für gehashte Assets plausibel. Für regelmäßig aktualisiertes HTML ist das meist gefährlich.

3. Niemand kennt die ausgelieferten Header

„Unser CDN regelt das“ ist keine belastbare Antwort. Entscheidend sind Cache-Control, Age, ETag, Last-Modified, Vary und gegebenenfalls zusätzliche Cache-Status-Header.

4. Sprach- oder Inhaltsvarianten teilen sich denselben Cache-Eintrag

Wenn eine Antwort von Accept-Language, Accept-Encoding oder anderen Request-Headern abhängt, muss der Cache wissen, welche Merkmale den Inhalt beeinflussen. Der Vary-Header steuert diese Trennung. Fehlt er, kann die falsche Variante ausgeliefert werden.

5. Alte Assets werden sofort gelöscht

Selbst bei sauber gehashten Dateien können alte HTML-Dokumente noch eine Zeit lang im Umlauf sein. Werden deren Assets sofort entfernt, entstehen vermeidbare 404- und Chunk-Load-Fehler.

Praktischer Cache-Check nach jedem Deployment

Prüfen Sie nicht nur, ob eine URL Status 200 liefert. Prüfen Sie den Release als Nutzerfluss.

Dokumente

• Liefert HTML eine passende Revalidierungsstrategie?
• Ändert sich der Inhalt nach dem Deployment tatsächlich?
• Sind ETag oder Last-Modified konsistent?
• Enthält personalisiertes HTML versehentlich public?
• Werden sensible Antworten angemessen privat oder nicht speicherbar ausgeliefert?

Statische Assets

• Haben Dateinamen einen Inhalts- oder Build-Hash?
• Werden gehashte Dateien mit langer Laufzeit und gegebenenfalls immutable ausgeliefert?
• Bleiben alte Assets während eines sicheren Übergangs verfügbar?
• Verweisen HTML und Manifest auf existierende Dateien?

CDN und Varianten

• Zeigt Age unerwartet alte Antworten?
• Ist der Cache-Key vollständig?
• Passt Vary zu Sprach-, Kompressions- oder Inhaltsvarianten?
• Werden Fehlerseiten oder Auth-Antworten versehentlich öffentlich gecacht?
• Ist eine gezielte Invalidierung möglich?

Browser und Service Worker

• Wird ein vorhandener Service Worker zuverlässig aktualisiert?
• Können Nutzer in einer alten App-Shell hängen bleiben?
• Funktioniert der Wechsel in einem normalen Browserfenster, nicht nur nach Hard Reload?
• Wurde ohne eingeloggten Admin-Status und auf einer zweiten Verbindung geprüft?

Hard Reload ist keine Lösung

Wenn ein Fehler nur verschwindet, nachdem Nutzer den Cache manuell leeren, ist der Release-Prozess kaputt.

Ein Hard Reload kann bei der Diagnose helfen. Er beweist aber nicht, dass normale Besucher automatisch die korrekte Version erhalten. Die relevante Frage lautet: Erhält ein wiederkehrender Besucher nach dem Deployment eine konsistente Version?

So wird Caching release-sicher

Ein belastbarer Ansatz umfasst meist:

1. Gehashte, unveränderliche Assets. Neuer Inhalt bekommt eine neue URL.
2. Kurze oder validierungspflichtige HTML-Caches. Dokumente dürfen Releases nicht tagelang verstecken.
3. Atomare Deployments. HTML und Assets gehören zu demselben Release.
4. Übergangszeit für alte Assets. Alte Dokumente dürfen nicht sofort ins Leere zeigen.
5. Explizite Cache-Keys. Sprache, Kompression und andere Varianten werden korrekt getrennt.
6. Gezielte Invalidierung. Nur betroffene Inhalte werden geleert.
7. Release-Smoketests. Tests laden HTML, prüfen referenzierte Assets und zentrale Nutzerflüsse ohne erzwungenen Reload.
8. Beobachtbarkeit. 404-Spitzen, Chunk-Load-Fehler und auffällige Cache-Status werden erfasst.

Was Website-Pflichtencheck dabei prüft

Ein Website-Pflichtencheck betrachtet nicht nur einen einzelnen Header. Entscheidend ist das Zusammenspiel aus Hosting, CDN, Build-Ausgabe, HTML, Assets, API-Antworten, Service Worker und Deployment-Prozess.

Wir prüfen unter anderem:

• welche Inhalte öffentlich, privat oder gar nicht gecacht werden
• ob gehashte Assets wirklich unveränderlich sind
• ob alte Releases sicher auslaufen können
• ob ETag, Vary und Revalidierung sinnvoll eingesetzt werden
• ob personalisierte oder sensible Antworten in Shared Caches gelangen könnten
• ob ein Release ohne Hard Reload konsistent funktioniert
• ob Fehler nach Deployments sichtbar und reproduzierbar werden

Caching soll Ihre Website schneller machen. Es darf nicht dafür sorgen, dass Nutzer in verschiedenen Versionen derselben Website leben.

Wenn „bei mir funktioniert es“ regelmäßig mit „bitte Cache leeren“ endet, brauchen Sie keinen besseren Support-Satz. Sie brauchen einen überprüfbaren Cache- und Release-Prozess.