Was ermöglicht dir ein Service Worker, und worauf würdest du achten, bevor du einen einbaust?

Ein Service Worker ist ein Proxy zwischen Seite und Netzwerk, er kann also gecachte Antworten ausliefern, offline funktionieren, eine Shell vorcachen und Background Sync oder Push behandeln. Die Vorsicht gilt dem Lifecycle: er kontrolliert Seiten erst nach der Aktivierung, ein alter Worker liefert weiter alte Assets aus, bis er ersetzt wird, und eine schlechte Cache-Regel kann Nutzer auf einem kaputten Build festnageln. Versioniere immer deine Caches und liefere einen klaren Update-Pfad mit.

Er sitzt als eigener Worker zwischen Seite und Netzwerk, kann also Fetches abfangen und entscheiden, ob er aus einem Cache antwortet. Das gibt mir Offline-Support, eine sofortige Shell bei Wiederbesuchen, Background Sync für eingereihte Aktionen und Push-Benachrichtigungen. Vorsichtig bin ich beim Lifecycle, denn daher kommen die Vorfälle. Ein neuer Worker installiert sich, wartet dann, bis jeder kontrollierte Tab weg ist, bevor er aktiviert wird, Nutzer können also viel länger auf altem Code sitzen, als man denkt. Und wenn ich das HTML mit einer Cache-First-Regel cache und dann einen kaputten Worker ausliefere, habe ich zurückkehrende Nutzer effektiv lahmgelegt, weil sie den Fix nie laden. Ich versioniere deshalb Cache-Namen und lösche alte beim activate, halte HTML network-first und nur gehashte Assets cache-first, und ich behalte immer einen Notausstieg, der deregistriert und Caches leert. Geht es nur um Tempo bei Wiederbesuchen und nicht um echten Offline-Betrieb, hole ich mir das lieber über Cache-Header und ein CDN und spare mir die ganze Problemklasse.