Ein Service Worker ist ein JavaScript-Skript, das der Browser unabhängig von einer geöffneten Webseite ausführt. Er hat keinen Zugriff auf die sichtbare Seite, sitzt aber an einer mächtigen Stelle: zwischen der Anwendung und dem Netzwerk. Jede Anfrage, die eine Seite in seinem Gültigkeitsbereich stellt, läuft an ihm vorbei. Er kann sie unverändert durchlassen, aus einem Zwischenspeicher beantworten, umleiten oder eine eigene Antwort erzeugen. Dazu empfängt er Push-Nachrichten, auch wenn die Anwendung gerade nicht geöffnet ist. Ohne Service Worker gäbe es keine Progressive Web Apps im heutigen Sinn.
Wo der Service Worker sitzt
Man kann sich den Service Worker als programmierbaren Proxy im Browser vorstellen. Eine Webseite fordert ein Stylesheet, ein Bild oder Daten von einer Schnittstelle an; das Ereignis landet zuerst beim Service Worker. Dieser entscheidet nach Regeln, die die Entwickler festlegen, woher die Antwort kommt. Weil er so viel Kontrolle hat, verlangen Browser zwingend eine verschlüsselte Verbindung über HTTPS; einzige Ausnahme ist die lokale Entwicklung. Ein Service Worker gilt zudem nur für einen bestimmten Pfadbereich der Website, seinen sogenannten Scope.
Der Lebenszyklus: registrieren, installieren, aktivieren
Die Webseite registriert den Service Worker beim ersten Besuch. Der Browser lädt das Skript und löst das Ereignis «install» aus — der typische Moment, um die wichtigsten Dateien der Anwendung vorab in den Zwischenspeicher zu legen. Danach folgt «activate», in dem alte Zwischenspeicher aufgeräumt werden. Erst dann übernimmt der Service Worker die Kontrolle über Anfragen, standardmässig ab dem nächsten Seitenaufruf.
Wichtig für den Betrieb: Ändert sich das Skript auch nur um ein Byte, installiert der Browser die neue Version, aktiviert sie aber erst, wenn keine Seite mehr mit der alten Version geöffnet ist. Das verhindert, dass zwei Versionen gleichzeitig Anfragen beantworten, führt aber in der Praxis dazu, dass Nutzer manchmal länger eine veraltete Anwendung sehen. Mit gezielten Befehlen lässt sich die neue Version sofort aktivieren; das muss aber zur Anwendung passen, damit nicht eine alte Seite plötzlich auf neue Dateien trifft.
Caching-Strategien im Vergleich
Die zentrale Entwurfsentscheidung ist, wie der Service Worker mit dem Zwischenspeicher umgeht. Bei «Cache zuerst» wird eine gespeicherte Antwort sofort ausgeliefert und das Netzwerk nur gefragt, wenn nichts vorhanden ist — ideal für unveränderliche Dateien wie versionierte Skripte und Schriften. Bei «Netzwerk zuerst» wird zuerst der Server gefragt und der Zwischenspeicher nur bei fehlender Verbindung genutzt — passend für Inhalte, die aktuell sein müssen. «Stale-while-revalidate» liefert sofort die gespeicherte Version und aktualisiert sie im Hintergrund für den nächsten Aufruf, ein guter Kompromiss für Inhalte, bei denen eine kurze Verzögerung akzeptabel ist.
In einer gut gebauten Anwendung gelten diese Strategien nicht pauschal, sondern je Art der Anfrage. Statische Dateien, Seitenrahmen, Daten-Schnittstellen und Bilder bekommen jeweils eigene Regeln.
Push-Nachrichten und Hintergrundaufgaben
Weil der Service Worker unabhängig von der Seite läuft, kann er Push-Nachrichten empfangen und als Benachrichtigung anzeigen. Auf Android und in Desktop-Browsern ist das seit Langem verbreitet; auf iOS können installierte Web-Apps seit iOS 16.4 Push empfangen. Die Einwilligung des Nutzers ist dabei Pflicht, sowohl technisch durch den Browser als auch datenschutzrechtlich. Weitergehende Hintergrundfunktionen wie das spätere Nachsenden von Daten bei wiederhergestellter Verbindung sind nicht in allen Browsern verfügbar; eine robuste Anwendung prüft deshalb beim nächsten Öffnen selbst, ob noch Daten zu übertragen sind.
Typische Fehler im Betrieb
Der häufigste Fehler ist ein Service Worker, der zu viel zwischenspeichert. Antworten, die persönliche Daten enthalten oder von der Anmeldung abhängen, gehören nicht ungeprüft in einen gemeinsamen Zwischenspeicher. Ebenso problematisch ist fehlende Versionierung: Werden Zwischenspeicher nicht benannt und beim Aktivieren aufgeräumt, sammeln sich alte Dateien an, und Nutzer sehen eine Mischung aus alter und neuer Anwendung.
Ein zweiter Fehler betrifft die Erwartung an die Dauerhaftigkeit. Browser dürfen gespeicherte Daten unter Speicherdruck entfernen, und Safari löscht Speicher von Websites, mit denen der Nutzer längere Zeit nicht interagiert hat, sofern die Website nicht als Web-App installiert ist. Ein Zwischenspeicher ist deshalb eine Beschleunigung und eine Brücke für Funklöcher, kein verlässlicher Datenspeicher.
Service Worker und Datenschutz
Ein Service Worker kann Inhalte auf dem Gerät ablegen, und genau das ist datenschutzrechtlich relevant. Werden Personendaten zwischengespeichert, gehört das in das Datenschutzkonzept: welche Daten, wie lange, und wie sie beim Abmelden entfernt werden. Bei sensiblen Anwendungen etwa im Gesundheitswesen werden lokal gespeicherte Daten zusätzlich verschlüsselt und nach dem Abgleich gelöscht.
Service Worker in modernen Web-Frameworks
In Projekten mit Next.js oder vergleichbaren Frameworks wird der Service Worker selten von Hand geschrieben. Build-Werkzeuge erzeugen eine Liste der Dateien, die vorab gespeichert werden sollen, und versehen sie mit Versionskennungen. Das nimmt viel Fehlerpotenzial weg, ersetzt aber nicht die Entscheidung, welche Inhalte überhaupt offline verfügbar sein sollen. Besonders heikel sind serverseitig erzeugte Seiten: Werden sie zu aggressiv zwischengespeichert, sieht ein Nutzer Inhalte, die längst nicht mehr gelten, oder eine Seite, die nicht zur aktuell geladenen Anwendung passt. Bewährt hat sich, statische Dateien dauerhaft zu speichern, Seiten über das Netzwerk zu laden und bei fehlender Verbindung eine eigens gestaltete Offline-Seite zu zeigen, die erklärt, was ohne Netz möglich ist.
Prüfen und Fehler finden
Die Entwicklerwerkzeuge der gängigen Browser zeigen, welcher Service Worker registriert ist, in welchem Zustand er sich befindet und was in den Zwischenspeichern liegt. Dort lassen sich Verbindungsabbrüche simulieren, alte Versionen abmelden und Speicher leeren. Für die Qualitätssicherung lohnt sich ein fester Testablauf: erster Besuch, zweiter Besuch ohne Netz, Veröffentlichung einer neuen Version, erneuter Besuch mit noch geöffneter alter Seite. Die meisten Fehler, die Nutzer später melden, zeigen sich bereits in diesem einfachen Durchgang.
Wie wir Service Worker einsetzen
Bei Innopulse ist der Service Worker Teil jeder PWA, die wir bauen — aber nie als Standardkonfiguration aus einer Vorlage. Wir legen pro Anfragetyp fest, welche Strategie gilt, versionieren Zwischenspeicher konsequent und testen den Update-Fall ausdrücklich, weil er in der Praxis die meisten Probleme verursacht. Wer eine Offline-fähige Web-App plant, sollte diese Entscheidungen ins Konzept aufnehmen, nicht erst in die letzte Entwicklungswoche.