Was ist ein Service Worker? Lebenszyklus, Caching und Grenzen

Was ist ein Service Worker?

Ein Service Worker ist eine JavaScript-Datei, die der Browser getrennt von der Seite im Hintergrund ausführt und die Netzwerkanfragen von Seiten in ihrem Geltungsbereich abfangen kann. MDN beschreibt Service Worker als Proxyserver zwischen Webanwendung, Browser und Netzwerk. Da ein Service Worker Anfragen aus einem Cache beantworten kann, ermöglicht er die Offline-Nutzung und sehr schnelle wiederholte Aufrufe. Er ist die Grundlage von Progressive Web Apps.

So funktioniert er

Die Seite registriert den Worker mit navigator.serviceWorker.register('/sw.js'). Danach durchläuft er einen Lebenszyklus:

1. Install. Wird ausgelöst, wenn der Browser eine neue Worker-Datei findet. Hier legen Worker meist einen Cache an und speichern die Dateien, die die App offline braucht.
2. Waiting. Steuert noch ein älterer Worker offene Seiten, wartet der neue. Er wird erst aktiv, wenn keine Seite mehr die alte Version nutzt, es sei denn, er ruft skipWaiting() auf.
3. Activate. Ein guter Zeitpunkt, um alte Caches zu löschen. Ein erstmals installierter Worker steuert bereits geöffnete Seiten erst nach dem Neuladen, außer er ruft clients.claim() auf.
4. Fetch und weitere Ereignisse. Der Worker verarbeitet fetch-Ereignisse und entscheidet mit respondWith(), was zurückgegeben wird. Er kann auch Push-Nachrichten und Background-Sync-Ereignisse empfangen.
5. Update. Der Browser lädt die Worker-Datei bei einer Navigation zu einer Seite im Geltungsbereich erneut, außerdem wenn ein Ereignis eintritt und die Datei in den letzten 24 Stunden nicht geprüft wurde. Eine geänderte Datei wird als neue Version installiert.

Zwei Einschränkungen sind in der Praxis wichtig. Ein Service Worker läuft nur in einem sicheren Kontext, also über HTTPS (localhost gilt für die Entwicklung als sicher). Und er läuft in einem Worker-Kontext: kein DOM-Zugriff, kein synchrones XHR und kein Web Storage. Seiten kommunizieren mit ihm über postMessage(). Der Browser kann einen untätigen Worker beenden, deshalb wird Arbeit, die abgeschlossen werden muss, in event.waitUntil() eingepackt.

Gängige Caching-Muster

• Cache first, Netzwerk als Fallback. Die gespeicherte Kopie ausliefern, falls vorhanden, sonst laden. Gut für CSS, JS und Schriften mit Fingerprint im Dateinamen.
• Network first, Cache als Fallback. Erst das Netzwerk versuchen, offline den Cache nutzen. Gut für HTML, das aktuell sein soll.
• Stale while revalidate. Sofort aus dem Cache antworten und den Cache im Hintergrund aktualisieren. Gut für Inhalte, bei denen etwas Veraltetes in Ordnung ist.
• Offline-Fallback. Ist die Anfrage nicht im Cache und das Netzwerk fällt aus, wird eine vorbereitete Offline-Seite statt eines Fehlers geliefert.
• Navigation Preload. Die Netzwerkanfrage parallel zum Start des Workers beginnen, damit der Worker Navigationen nicht verzögert.

Beispiel

Eine Nachrichtenseite legt ihre App-Shell (HTML-Gerüst, CSS, JS) im install-Ereignis vorab im Cache ab. Bei jeder Anfrage liefert der Worker statische Dateien nach Cache-first und Artikelseiten nach Network-first aus, offline mit der zuletzt gespeicherten Kopie. Liefert das Team eine neue sw.js mit dem Cache-Namen v2 aus, löscht der activate-Handler den Cache v1.

Häufige Fehler

• HTML nach Cache-first ausliefern, ohne Ausweg. Nutzer sehen die alte Seite, bis der Worker aktualisiert ist. Verwenden Sie für Dokumente Network-first und versionieren Sie Ihre Caches.
• waitUntil() vergessen. Der Worker kann beendet werden, bevor der Cache-Schreibvorgang fertig ist.
• Antworten nicht klonen. Ein Response-Body lässt sich nur einmal lesen, also vor dem Speichern und Zurückgeben klonen.
• skipWaiting() unbedacht einsetzen. Ein neuer Worker kann eine Seite übernehmen, die mit den alten Dateien geladen wurde.
• API-Antworten oder angemeldete Seiten sorglos cachen. Ein Worker-Cache folgt nicht von selbst den HTTP-Regeln zur Aktualität; das Ablaufen legen Sie fest. Die Header-Seite behandelt API-Caching.
• Den ersten Besuch ignorieren. Registrieren und Installieren kosten Bandbreite und CPU, bevor ein Vorteil bei Folgebesuchen existiert.

Service Worker, Cache-Schichten und Performance

Ein Service Worker ist eine Schicht unter mehreren. Der HTTP-Cache des Browsers folgt den Cache-Control-Headern, ein CDN liefert gemeinsame Kopien vom Edge, und der Cache-API-Speicher des Workers wird von Ihrem eigenen Code gesteuert. Ein Web Worker ist etwas anderes: Er verlagert Berechnungen vom Hauptthread, fängt aber keine Anfragen ab. In einer Single-Page-App kann ein Worker, der die App-Shell cacht, wiederholte Aufrufe beschleunigen. In den Core Web Vitals zeigt sich der Effekt nur, wenn Seiten aus dem Cache kommen. Messen Sie ihn also, statt ihn anzunehmen: Vergleichen Sie Folgebesuche mit Real User Monitoring und verfolgen Sie Labor-Werte über die Zeit mit geplanten Lighthouse-Audits. Caches verändern auch, was ein Performance-Test misst, wie unsere Leitfäden zu Lasttests für Progressive Web Apps und zur Cache-Invalidierung in Performance-Tests zeigen. Die vollständige API finden Sie in der MDN-Referenz zur Service Worker API.

Häufige Fragen: Service Worker

Brauche ich einen Service Worker?

Nur wenn Sie Offline-Unterstützung, Push-Benachrichtigungen oder programmatische Cache-Kontrolle wollen. Eine Seite, die ohnehin schnell lädt und wenige wiederkehrende Besucher hat, gewinnt für die zusätzliche Komplexität oft wenig.

Was ist der Unterschied zwischen Service Worker und Web Worker?

Ein Web Worker führt Skripte in einem Hintergrund-Thread aus, damit rechenintensive Aufgaben die Seite nicht blockieren. Ein Service Worker sitzt zwischen Seite und Netzwerk, kann Anfragen aus einem Cache beantworten und besteht über einen einzelnen Seitenaufruf hinaus.

Warum wird mein neuer Service Worker nicht wirksam?

Die neue Version wird installiert, wartet aber, bis keine offene Seite mehr die alte nutzt. Schließen Sie alle Tabs, oder rufen Sie skipWaiting() und clients.claim() auf, wenn Sie die Nachteile akzeptieren.

Braucht ein Service Worker HTTPS?

Ja. Service Worker stehen nur in sicheren Kontexten zur Verfügung. Browser behandeln auch http://localhost als sicher, damit Sie lokal entwickeln können.

Kann ein Service Worker das DOM der Seite sehen oder ändern?

Nein. Er hat keinen DOM-Zugriff und läuft in einem anderen Thread. Mit Seiten tauscht er Nachrichten über postMessage() aus.

Wie werde ich einen fehlerhaften Service Worker wieder los?

Liefern Sie eine Ersatz-sw.js aus, die ihre Caches im activate-Ereignis leert, oder melden Sie ihn von der Seite aus ab. Planen Sie diesen Notausschalter vor dem Release, denn ein Worker, der HTML cacht, kann veraltete Seiten weiter ausliefern.