Einen Service Worker sicher ausrollen: Scope, versionierte Caches, der wartende Worker und ein Notausschalter

Ziel

Einer Website Offline-Caching hinzufügen, ohne den klassischen Fehler: Ein veralteter Worker liefert nach einem Deployment weiter altes HTML und alte Assets, oder ein defekter Worker lässt sich nicht ersetzen, weil er sein eigenes Skript aus dem Cache liefert.

Voraussetzungen

HTTPS (MDN: Service Worker laufen nur auf sicheren Ursprüngen, wobei localhost erlaubt ist), ein Build, der inhaltsgehashte Asset-Dateinamen erzeugt, sowie der Lebenszyklus, wie ihn der MDN-Leitfaden beschreibt: Ein neuer Worker installiert im Hintergrund, wartet, bis keine Seite mehr den alten verwendet, und aktiviert sich dann; skipWaiting() und clients.claim() verkürzen die Wartezeit.

Schritte

1. Von einer Stelle aus mit explizitem scope registrieren (/ für den gesamten Ursprung; das Skript muss auf oder oberhalb dieses Pfads ausgeliefert werden, ausser der Server sendet Service-Worker-Allowed), und das Worker-Skript mit Cache-Control: no-cache ausliefern. updateViaCache: "none" übergeben, damit das Skript und seine Imports den HTTP-Cache umgehen, wenn der Browser auf Updates prüft.
2. Caches mit einer Zeichenkette benennen, die sich bei jedem Build ändert (static-<git-sha>); in activate jeden Cache löschen, dessen Name nicht aktuell ist, wie im Aufräumbeispiel des Leitfadens, und erst danach clients.claim() aufrufen.
3. Eine Strategie pro Ressourcenklasse wählen: Cache-first für gehashte, unveränderliche Assets; Network-first mit Cache-Fallback für HTML-Navigationen und API-Daten; niemals Cache-first für ungehashtes HTML.
4. In install nur die App-Shell vorab cachen und die Liste kurz halten: cache.addAll() lehnt mit einem TypeError ab, sobald eine Antwort ausserhalb des 200er-Bereichs liegt, was die gesamte Installation scheitern lässt.
5. Entscheiden, wie Updates ankommen. Der Standardweg (Aktivierung, sobald der letzte alte Tab schliesst) ist für Konsistenz am sichersten. Wird skipWaiting() aufgerufen, einen Hinweis „neue Version verfügbar, neu laden“ anzeigen, statt einen neuen Worker stillschweigend neue Assets an alte Seiten liefern zu lassen.
6. Den Notausschalter vor dem ersten Release bauen: eine Worker-Version, deren activate alle Caches löscht und self.registration.unregister() aufruft, sowie einen dokumentierten Weg, sie innerhalb von Minuten auszurollen.
7. Den Update-Pfad im Staging proben: deployen, zweimal neu laden, bestätigen, dass die neue Version aktiv ist und alte Caches verschwunden sind; dann den Notausschalter deployen und bestätigen, dass der Worker verschwindet.

Erwartetes Ergebnis

Jedes Deployment ersetzt die Caches innerhalb eines Update-Zyklus, Nutzerinnen und Nutzer laden nie eine Mischung aus altem HTML und neuen Assets, und ein fehlerhafter Worker lässt sich ausser Betrieb nehmen, ohne auf den Ablauf des Caches oder eine Nutzeraktion zu warten.

Grenzen und Prüfbasis

Das Verhalten folgt den zitierten MDN-Seiten; zum Zeitpunkt der Update-Prüfung des Browsers und zu den Regeln für die Speicherverdrängung wird nichts behauptet. Offline-Schreibvorgänge (angestaute Anfragen, Background Sync) sind ein eigenes Thema. Das Cachen fremder Ursprünge bringt opake Antworten mit sich, die nicht auf Fehler geprüft werden können.

Ein Zeitlimit für Network-first-Navigationen

Network-first greift nur dann auf den Cache zurück, wenn die Anfrage fehlschlägt, und bei einer Verbindung, die zwar besteht, aber hängt, schlägt die Anfrage erst beim eigenen Timeout des Browsers fehl – die Nutzerin oder der Nutzer wartet also auf einer leeren Seite, obwohl eine gecachte Kopie existiert. Die Wartezeit begrenzen: die Netzwerkanfrage starten, und wenn sie innerhalb einer kurzen, dokumentierten Zeit nicht geantwortet hat, mit dem gecachten HTML antworten und die frische Kopie bei der nächsten Navigation ankommen lassen (Workboxs NetworkFirst-Strategie stellt das als networkTimeoutSeconds bereit). Das mit Navigation Preload kombinieren (registration.navigationPreload.enable()), damit die Netzwerkanfrage parallel zum Start des Workers beginnt statt danach. Gehashte Asset-Namen halten das ausgelieferte HTML so oder so konsistent mit seinen eigenen Assets.