Der Fix ist live – aber nicht bei allen: Service-Worker-Updates richtig prüfen

Ein Fehler wird behoben, das Deployment ist grün und im eigenen Browser sieht alles korrekt aus. Trotzdem melden einzelne Nutzer Stunden oder Tage später noch denselben Fehler. Nach einem „Website-Daten löschen“ funktioniert es plötzlich.

Das ist kein mystischer Browserzustand. Bei Websites mit Service Worker existiert neben HTTP-Cache und CDN eine weitere persistente Schicht, die Requests abfangen und Antworten aus der Cache Storage API liefern kann. Wenn Update-Lifecycle und Cache-Strategie nicht bewusst geplant sind, können unterschiedliche Nutzer real unterschiedliche Frontend-Versionen sehen.

Deployment und Auslieferung sind zwei verschiedene Ereignisse

Ein neues Bundle auf dem Server bedeutet nicht automatisch, dass ein bereits installierter Service Worker sofort ersetzt wird.

Die Service-Worker-Spezifikation kennt pro Registrierung unter anderem einen installierenden, einen wartenden und einen aktiven Worker. Wird eine neue Worker-Version gefunden, kann sie im Hintergrund installiert werden und anschließend im Status „waiting“ verbleiben. Standardmäßig wird sie erst aktiviert, wenn keine Clients mehr die bisherige Version verwenden. Bei langlebigen Tabs kann das überraschend lange dauern.

Das ist Absicht: Der Browser verhindert damit, dass zwei Worker-Versionen gleichzeitig dieselbe Anwendung kontrollieren. Für Anwendungen mit vielen offenen Tabs ist genau dieser Schutz aber etwas, das im Release-Prozess berücksichtigt werden muss.

Drei Cache-Ebenen, die man auseinanderhalten sollte

Bei der Fehlersuche lohnt sich eine klare Trennung:

1. HTTP- und CDN-Cache: Hier wirken Response-Header wie Cache-Control, Revalidierung und gegebenenfalls ein vorgeschaltetes CDN.
2. Service-Worker-Update: Der Browser prüft die Worker-Datei auf Änderungen und verwaltet deren Installations- und Aktivierungszustand. Die Registrierung selbst ist persistent, bis sie explizit entfernt wird.
3. Cache Storage: Der Service Worker kann eigene benannte Caches anlegen und dort HTML, JavaScript, CSS, Bilder oder API-Antworten speichern. Diese Daten verschwinden nicht automatisch nur deshalb, weil ein neues Deployment stattgefunden hat.

Wer lediglich den Server-Cache leert, löst deshalb nicht zwingend ein Problem in der Cache Storage eines bereits registrierten Workers.

Sieben Fragen für einen belastbaren Audit

1. Gibt es überhaupt noch einen Service Worker?

Das klingt banal, ist aber ein häufiger Handover-Fehler. Eine frühere PWA-Version, ein altes Framework-Plugin oder eine längst entfernte Offline-Funktion kann eine Registrierung hinterlassen. Laut W3C bleibt eine Service-Worker-Registrierung persistent, bis sie explizit deregistriert wird.

Prüfen sollte man deshalb nicht nur den aktuellen Quellcode, sondern im Browser die tatsächlich vorhandenen Registrierungen und deren Scope.

2. Welcher Worker ist aktiv, welcher wartet?

Ein sauberer Release-Prozess sollte sichtbar machen können, ob installing, waiting oder active gesetzt ist. Ein wartender Worker ist kein theoretischer Zustand: Er erklärt konkret, warum ein neues Deployment auf dem Server liegt, aber ein bestehender Tab noch die vorherige Version nutzt.

Gerade bei SaaS-Anwendungen lohnt es sich, diesen Zustand in einer reproduzierbaren Teststrecke mit mehreren Tabs zu prüfen.

3. Wie wird ein Update aktiviert?

skipWaiting() kann einen wartenden Worker zur sofortigen Aktivierung auffordern. clients.claim() kann dafür sorgen, dass der neue aktive Worker bestehende Clients übernimmt.

Beides ist nützlich, aber „immer sofort übernehmen“ ist nicht automatisch die richtige Strategie. Wenn eine bereits geladene Seite noch alten JavaScript-Code ausführt, während ein neuer Worker plötzlich andere Assets oder API-Caching-Regeln bedient, kann ein Mischzustand entstehen. Bei Anwendungen mit Formularen oder ungespeicherten Eingaben ist ein kontrollierter Hinweis „Neue Version verfügbar“ plus Reload oft robuster als ein unsichtbarer Wechsel.

4. Sind Cache-Namen und Assets versioniert?

Ein neuer Worker sollte alte Cache-Generationen erkennen und gezielt entfernen können. MDN empfiehlt, alte Cache-Versionen im activate-Ereignis aufzuräumen.

Besonders kritisch wird es, wenn HTML langfristig gecacht wird und darin Dateinamen referenziert werden, die nach einem Deployment nicht mehr vorhanden sind. Dann lädt der Nutzer ein altes Dokument, das neue oder bereits gelöschte Chunks erwartet – ein klassischer Weg zu sporadischen „Chunk load“-Fehlern.

5. Welche Strategie gilt für HTML, Assets und APIs?

„Cache first“ ist für unveränderliche, gehashte Assets etwas völlig anderes als für HTML oder API-Antworten. Chrome beschreibt beispielsweise network first als sinnvolle Strategie für Inhalte, bei denen online die aktuelle Version bevorzugt werden soll und der Cache als Offline-Fallback dient.

Ein Audit sollte daher nicht nur feststellen, dass gecacht wird, sondern was, wie lange und mit welcher Fallback-Logik.

6. Kann die Worker-Datei selbst zuverlässig aktualisiert werden?

Bei der Registrierung gibt es mit updateViaCache eine Einstellung dafür, ob der HTTP-Cache bei Updates des Workers und importierter Worker-Skripte berücksichtigt wird. Der Standardwert ist imports.

Zusätzlich kann ServiceWorkerRegistration.update() aktiv nach einer neuen Version suchen. MDN dokumentiert, dass dabei die Worker-Datei erneut abgerufen und eine neue Version installiert wird, wenn sie sich byteweise unterscheidet.

Das ersetzt keine sinnvolle Cache-Konfiguration, zeigt aber, dass die Update-Kette selbst Teil des Audits sein muss.

7. Wurde ein echter Mehrtab-Release getestet?

Der wertvollste Test ist selten „Seite neu laden und schauen, ob sie geht“.

Ein sinnvoller Release-Test sieht eher so aus: alte Version in zwei Tabs öffnen, neue Version deployen, einen Tab navigieren, Update-Zustand beobachten, den zweiten Tab offenlassen, anschließend Aktivierung und Reload testen. Danach Cache Storage, aktive Worker-Version und geladene Asset-Versionen kontrollieren.

So findet man Lifecycle-Probleme, die ein einzelner frischer Browser niemals zeigen würde.

Typische Red Flags

Hinweise auf Update- oder Cache-Drift sind unter anderem:

• Support empfiehlt regelmäßig „Hard Reload“ oder „Website-Daten löschen“.
• Fehler treten nur bei einigen Bestandsnutzern auf, nicht in frischen Inkognito-Sessions.
• Ein neuer Worker bleibt dauerhaft im Status waiting.
• Alte Cache-Namen sammeln sich über viele Releases an.
• HTML wird aggressiv gecacht, während referenzierte JavaScript-Chunks bei Releases ersetzt oder gelöscht werden.
• skipWaiting() und clients.claim() wurden aus einem Boilerplate übernommen, ohne das Versionsverhalten der Anwendung zu testen.
• Eine PWA-Funktion wurde entfernt, aber die alte Registrierung wird nicht migriert oder deregistriert.
• Es gibt keine sichtbare Release-Version, mit der Support und Entwicklung feststellen können, welchen Stand ein Nutzer tatsächlich ausführt.

Ein robusteres Deployment-Muster

Für viele Webanwendungen ist ein konservatives Muster leichter zu betreiben: gehashte statische Assets dürfen langfristig gecacht werden; HTML und kritische API-Daten bekommen eine bewusst frische Strategie; Cache-Namen sind versioniert; alte Generationen werden beim Aktivieren bereinigt; ein wartender Worker wird erkannt; und bei einem relevanten Update bekommt der Nutzer eine kontrollierte Möglichkeit zum Reload.

Wer sofort aktiviert, sollte gezielt testen, ob alte Dokumente mit dem neuen Worker kompatibel bleiben. Wer einen Reload verlangt, sollte vorher ungespeicherte Zustände berücksichtigen.

Entscheidend ist nicht die eine universelle Strategie, sondern dass das Verhalten definiert, testbar und im Betrieb beobachtbar ist.

Was Website-Pflichtencheck dabei prüfen würde

Bei einem technischen Website-Check betrachten wir nicht nur Lighthouse-Werte oder sichtbare Frontend-Fehler. Bei Service-Worker-basierten Websites prüfen wir unter anderem Registrierung und Scope, aktive und wartende Worker, Cache-Storage-Inhalte, Versionierung und Cleanup, Caching-Strategien für HTML und Assets, Update-Verhalten über mehrere Tabs sowie die Frage, ob alte Releases nach einem Deployment weiter ausgeliefert werden können.

Wenn Nutzer Fehler melden, die sich intern nicht reproduzieren lassen, lohnt sich diese Ebene besonders. Ein reproduzierbarer Update-Test ist meist hilfreicher als die nächste Runde „Cache einmal leeren“.

Quellen

• W3C: Service Workers — https://www.w3.org/TR/service-workers/
• MDN: Using Service Workers — https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
• MDN: ServiceWorkerRegistration.update() — https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/update
• MDN: ServiceWorkerRegistration.updateViaCache — https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/updateViaCache
• Chrome for Developers: Handling service worker updates with immediacy — https://developer.chrome.com/docs/workbox/handling-service-worker-updates