Was ist ein Service Worker?

Was ist ein Service Worker?

Ein Service Worker ist eine JavaScript-Datei, die im Hintergrund einer Webseite läuft, getrennt vom Haupt-Browser-Thread. Seine Kern-Power ist das Abfangen und Modifizieren von Network-Requests, die die Seite macht. Diese eine Fähigkeit erschließt Offline-Support, Push-Benachrichtigungen, Background-Sync und dramatisch schnellere Repeat-Load-Performance — Features, die vorher native Apps erforderten.

Service Worker wurden 2015 standardisiert und in Chrome 40, Firefox 44, Safari 11.1 (mit Verzögerungen) und Edge von Anfang an ausgeliefert. Sie sind die Grundlage von Progressive Web Apps (PWAs): Web-Apps, die zum Home-Screen installieren, offline funktionieren und nativ wirken. Auch Sites, die nicht auf PWAs zielen, nutzen Service Worker für Performance — teure Responses cachen, kritische Assets vorladen, API-Calls deduplizieren.

Was Service Worker können (und nicht)

Service Worker laufen in einem speziellen Kontext mit strikten Fähigkeiten und Limitierungen:

Können:

• Network-Requests abfangen. Das fetch-Event feuert für jeden Request, den die Seite macht — HTML, CSS, JS, Bilder, API-Calls. Der Worker entscheidet: aus Cache servieren, Request modifizieren, vom Netzwerk holen oder Fallback wenn offline.
• Responses programmatisch cachen. Service Worker haben Zugriff auf die Cache-API — ein separater Cache-Storage vom Browser-HTTP-Cache, mit expliziter programmatischer Kontrolle.
• Push-Benachrichtigungen. Push-Messages von einem Server empfangen, auch wenn die Seite geschlossen ist, dann Benachrichtigungen für den Nutzer anzeigen.
• Background-Sync. Arbeit verschieben, bis der Nutzer Konnektivität hat. API-Calls offline queuen, senden wenn das Netzwerk zurückkehrt.
• Background-Fetch. Lang laufende Downloads, die auch nach dem Schließen der Seite weiterlaufen.

Können nicht:

• Direkt aufs DOM zugreifen. Service Worker laufen in einem separaten Kontext. Sie kommunizieren mit Seiten nur via postMessage.
• Synchrone APIs nutzen (XHR sync, localStorage). Async-only Umgebung. fetch und IndexedDB stattdessen nutzen.
• Beliebig State über Restarts persistieren. Der Browser kann den Worker jederzeit beenden, wenn er idle ist. IndexedDB oder Cache für State nutzen, nicht Modul-Variablen.
• Auf unsicheren Origins laufen. Service Worker erfordern HTTPS (außer localhost für Entwicklung).

Der Service-Worker-Lifecycle (5 Stufen)

1. Register. Seite ruft navigator.serviceWorker.register('/sw.js') auf. Browser lädt die Worker-Datei herunter.
2. Install. Browser feuert das install-Event. Worker pre-cached typischerweise hier kritische Assets.
3. Activate. Browser feuert activate-Event. Worker übernimmt die Kontrolle über Seiten bei der nächsten Navigation (nutze clients.claim(), um sofort zu übernehmen).
4. Run / handle Events. Worker handelt fetch, push, sync etc., wenn sie feuern. Browser kann den Worker zwischen Events beenden, um Speicher zu sparen.
5. Update. Wenn der Nutzer wiederkommt, prüft der Browser, ob sich sw.js geändert hat (Byte für Byte). Wenn ja, installiert die neue Version, wartet aber, bis alle Seiten der alten Version geschlossen sind, bevor sie aktiviert. Force-Update mit skipWaiting().

Häufige Service-Worker-Patterns

Cache-first für statische Assets

Für CSS, JS, Fonts, Bilder, die sich selten ändern: aus Cache servieren, auf Netzwerk zurückfallen, Cache im Hintergrund aktualisieren. Seite lädt sofort bei Repeat-Visits.

Network-first mit Cache-Fallback für HTML

Für dynamische HTML-Seiten, die frisch sein sollen: zuerst Netzwerk versuchen (mit kurzem Timeout), auf Cache zurückfallen, wenn offline oder langsam. Nutzer sieht frischen Content online, gecachten Content nicht.

Stale-while-revalidate für API-Calls

Gecachte API-Response sofort servieren, dann frisch im Hintergrund holen und Cache aktualisieren. Nutzer sieht sofortige Daten mit eventueller Konsistenz.

Network-only für Mutations

POST/PUT/DELETE-Requests umgehen den Cache komplett — sie müssen das Netzwerk treffen oder für Background-Sync queuen.

Offline-first mit Shell + dynamischem Content

App-Shell (HTML, CSS, JS-Bundle) bei Install pre-cachen. Dynamischen Content vom Netzwerk mit Cache-Fallback holen. Site funktioniert vollständig offline für gecachten Content, degradiert graceful für neuen Content.

Service Worker und Core Web Vitals

Service Worker können Core Web Vitals dramatisch bei Repeat-Visits verbessern — aber beim ersten Besuch fügen sie kleinen Overhead hinzu (Worker registrieren, sw.js laden). Implikationen:

• LCP verbessert sich dramatisch bei Repeat-Visits. Pre-gecachte Hero-Bilder und kritisches CSS laden sofort.
• FCP verbessert sich bei Repeat-Visits. Pre-gecachte HTML-Shell rendert vor dem Netzwerk-Roundtrip.
• First-Visit-Kosten sind real. Worker registrieren und installieren, Assets pre-cachen, zusätzliches JavaScript parsen — alles fügt Kosten in der ersten Session hinzu. Nicht over-engineeren.
• CLS unbeeinflusst. Service Worker wirken sich nicht auf Layout-Stabilität aus, in beide Richtungen.
• INP kann sich verbessern. Pre-gecachte interaktive Responses (z.B. gecachte Suchvorschläge) reduzieren Server-Roundtrip-Latenz bei Nutzerinteraktionen.

Service Worker vs. andere Caching-Layer

Moderne Web-Apps haben mehrere Caching-Layer. Service Worker sitzen an einer spezifischen Stelle:

• Browser-HTTP-Cache: Implizit, kontrolliert von Cache-Control-Headern. Browser entscheidet, was wann gecacht wird. Keine JavaScript-Kontrolle.
• Service-Worker-Cache-API: Explizit, kontrolliert von JS. Überlebt Page-Reloads. Programmatische Kontrolle darüber, was zu cachen und servieren.
• CDN-Cache: Edge-Server. Schnell, aber über alle Nutzer geteilt. Updates via Cache-Invalidierung.
• HTTP/2-Push (deprecated): Server pusht Ressourcen. 2022 aus Chrome entfernt, weil es Service Worker nicht überholte.

FAQ: Service Worker

Brauche ich einen Service Worker für meine Site?

Wenn deine Site content-heavy ist und Nutzer oft zurückkommen, ja — Repeat-Visit-Performance-Gewinne sind groß. Wenn Nutzer einmal besuchen und nie wiederkommen, zahlt sich der First-Visit-Overhead nicht aus. Reine Marketing-Sites mit niedrigen Return-Rates profitieren nicht zwingend.

Was ist der Unterschied zwischen einem Service Worker und einem Web Worker?

Beide laufen in Background-Threads. Web Worker handeln CPU-gebundene Arbeit parallel zum Haupt-Thread (Bildverarbeitung, Berechnung). Service Worker fangen spezifisch Network-Requests ab und persistieren über Page-Loads. Andere APIs, andere Lifecycles.

Warum dauern Service-Worker-Updates so lange zu deployen?

Standardmäßig installiert eine neue Worker-Version, wartet aber, bis ALLE Seiten, die die alte Version laufen, geschlossen sind, bevor sie aktiviert. Für Nutzer mit der Site ewig in einem Tab kann das Tage dauern. Force-Update mit skipWaiting() im Install-Handler — aber Vorsicht, kann Assets und Code Mid-Session mismatchen.

Wie debugge ich einen Service Worker?

Chrome DevTools → Application → Service Workers zeigt registrierte Worker, aktuellen State, Fehler. Network-Tab zeigt, welche Requests aus dem SW-Cache serviert wurden (achte auf das kleine Zahnrad-Icon). Lighthouse-Audits enthalten PWA-/Service-Worker-Checks.

Funktionieren Service Worker in Safari?

Ja, seit iOS 11.3 / Safari 11.1. Implementierung war historisch schwächer (Background-Sync verzögert, Push-Notifications limitiert bis iOS 16.4). Teste PWA-Features immer auf echtem Safari, nicht nur Chrome.

Kann ein Service Worker meine Site brechen?

Ja, einfach. Ein buggy Worker, der immer gecachte Responses zurückgibt (auch alte), erstellt eine permanent kaputte UX, von der schwer zu erholen ist — Nutzer sehen Fixes erst, wenn der Worker sich selbst aktualisiert. Schließe immer einen Kill-Switch ein: einen Check, der den Worker auf einem Flag deaktiviert, das dein Server kontrolliert.

Wie LoadFocus Service-Worker-Impact misst

LoadFocus führt Lighthouse-basierte Page-Speed-Tests von echten Chrome-Instanzen in 25+ Regionen aus, die First-Visit- und Repeat-Visit-Metriken separat erfassen. Service-Worker-Effektivität zeigt sich als große Lücke zwischen Cold-Load- und Warm-Load-LCP. Plane Audits, um zu validieren, dass der Worker tatsächlich in Production funktioniert — kaputte Service-Worker-Registrierungen sind ein stiller Killer, der in Single-Page-Lighthouse-Runs nicht auftaucht.