Service Worker API

Hinweis: Dieses Feature ist verfügbar in Web Workers.

Service Worker fungieren im Wesentlichen als Proxy-Server, die zwischen Webanwendungen, dem Browser und dem Netzwerk (wenn verfügbar) sitzen. Sie sollen unter anderem die Erstellung effektiver Offline-Erlebnisse ermöglichen, Netzwerk-Requests abfangen und geeignete Maßnahmen ergreifen, basierend darauf, ob das Netzwerk verfügbar ist, sowie die auf dem Server befindlichen Ressourcen aktualisieren. Zudem ermöglichen sie den Zugriff auf Push-Benachrichtigungen und Background-Sync-APIs.

Konzepte und Nutzung von Service Workern

Ein Service Worker ist ein ereignisgesteuerter worker, der für einen Origin und einen Pfad registriert ist. Er nimmt die Form einer JavaScript-Datei an, die die zugehörige Webseite/Site steuern kann, indem sie Navigations- und Ressourcenanforderungen abfängt und ändert und Ressourcen sehr granular cacht, um Ihnen die volle Kontrolle darüber zu geben, wie sich Ihre App in bestimmten Situationen verhält (am offensichtlichsten, wenn das Netzwerk nicht verfügbar ist).

Service Worker laufen im Worker-Kontext: Sie haben daher keinen Zugriff auf das DOM und laufen in einem anderen Thread als das Haupt-JavaScript, das Ihre App antreibt. Sie blockieren nicht und sind so konzipiert, dass sie vollständig asynchron sind. Daher können APIs wie synchrones XHR und Web Storage nicht innerhalb eines Service Workers verwendet werden.

Service Worker können JavaScript-Module nicht dynamisch importieren, und import() wird einen Fehler auslösen, wenn es im globalen Scope des Service Workers aufgerufen wird. Statische Importe mit der import Anweisung sind erlaubt.

Service Worker laufen aus Sicherheitsgründen nur über HTTPS. Am bedeutsamsten ist, dass HTTP-Verbindungen anfällig für böswillige Code-Injektionen durch man in the middle Angriffe sind, und solche Angriffe könnten schlimmer sein, wenn sie Zugriff auf diese mächtigen APIs erhalten. In Firefox sind Service Worker APIs auch versteckt und können nicht verwendet werden, wenn der Benutzer im privaten Surfen ist.

Hinweis: In Firefox können Sie zum Testen Service Worker über HTTP (unsicher) ausführen; aktivieren Sie einfach die Option Service Workers über HTTP aktivieren (wenn das Werkzeug geöffnet ist) im Optionen/Zahnradsymbol-Menü von Firefox Devtools.

Hinweis: Im Gegensatz zu früheren Versuchen in diesem Bereich wie AppCache, machen Service Worker keine Annahmen darüber, was Sie tun möchten, aber dann scheitern Sie, wenn diese Annahmen nicht genau richtig sind. Stattdessen geben Service Worker Ihnen viel granularere Kontrolle.

Hinweis: Service Worker nutzen intensiv Promises, da sie im Allgemeinen darauf warten, dass Antworten eingehen, danach reagieren sie mit einer Erfolgs- oder Fehlermeldung. Die Promises-Architektur ist dafür ideal.

Registrierung

Ein Service Worker wird zuerst mit der Methode ServiceWorkerContainer.register() registriert. Wenn dies erfolgreich ist, wird Ihr Service Worker auf den Client heruntergeladen und versucht, installiert/aktiviert zu werden (siehe unten) für URLs, auf die der Benutzer innerhalb des gesamten Origins oder eines von Ihnen festgelegten Teilbereichs zugegriffen hat.

Herunterladen, Installieren und Aktivieren

Zu diesem Zeitpunkt wird Ihr Service Worker den folgenden Lebenszyklus beobachten:

Herunterladen
Installieren
Aktivieren

Der Service Worker wird sofort heruntergeladen, wenn ein Benutzer zum ersten Mal auf eine von einem Service Worker kontrollierte Site/Seite zugreift.

Danach wird er aktualisiert, wenn:

Eine Navigation zu einer Seite im Geltungsbereich stattfindet.
Ein Ereignis auf dem Service Worker ausgelöst wird und er in den letzten 24 Stunden nicht heruntergeladen wurde.

Die Installation wird versucht, wenn festgestellt wird, dass die heruntergeladene Datei neu ist - entweder anders als ein bestehender Service Worker (byteweise verglichen) oder der erste Service Worker, der für diese Seite/Site entdeckt wird.

Wenn dies das erste Mal ist, dass ein Service Worker verfügbar gemacht wird, wird die Installation versucht und nach einer erfolgreichen Installation wird er aktiviert.

Wenn ein bestehender Service Worker verfügbar ist, wird die neue Version im Hintergrund installiert, aber noch nicht aktiviert – zu diesem Zeitpunkt wird sie wartender Worker genannt. Sie wird erst aktiviert, wenn keine Seiten mehr geladen sind, die immer noch den alten Service Worker verwenden. Sobald keine Seiten mehr geladen werden, aktiviert sich der neue Service Worker (der aktive Worker). Die Aktivierung kann früher erfolgen mittels ServiceWorkerGlobalScope.skipWaiting() und bestehende Seiten können vom aktiven Worker mit Clients.claim() beansprucht werden.

Sie können das install Ereignis abhören; eine Standardaktion ist es, Ihren Service Worker bei dieser Auslösung für die Nutzung vorzubereiten, zum Beispiel, indem Sie einen Cache mit der integrierten Speicher-API erstellen und Ressourcen darin platzieren, die Sie für den Offline-Betrieb Ihrer App benötigen.

Es gibt auch ein activate Ereignis. Der Punkt, an dem dieses Ereignis ausgelöst wird, ist im Allgemeinen ein guter Zeitpunkt, um alte Caches und andere Dinge, die mit der vorherigen Version Ihres Service Workers assoziiert sind, aufzuräumen.

Ihr Service Worker kann auf Anfragen mit dem FetchEvent Ereignis reagieren. Sie können die Antwort auf diese Anfragen in beliebiger Weise ändern, indem Sie die Methode FetchEvent.respondWith() verwenden.

Hinweis: Da install/activate Ereignisse eine Weile dauern können, um abgeschlossen zu werden, stellt die Service Worker-Spezifikation eine waitUntil() Methode bereit. Sobald sie auf install oder activate Ereignissen mit einem Promise aufgerufen wird, warten funktionale Ereignisse wie fetch und push, bis der Promise erfolgreich aufgelöst wird.

Für ein vollständiges Tutorial, um zu zeigen, wie Sie Ihr erstes grundlegendes Beispiel aufbauen, lesen Sie Using Service Workers.

Verwendung von statischem Routing zur Steuerung der Ressourcenabrufe

Service Worker können unnötige Leistungskosten verursachen — wenn eine Seite das erste Mal seit einiger Zeit geladen wird, muss der Browser darauf warten, dass der Service Worker startet und ausgeführt wird, um zu wissen, welche Inhalte geladen werden sollen und ob sie aus dem Cache oder dem Netzwerk stammen sollen.

Wenn Sie bereits im Voraus wissen, wo bestimmte Inhalte abgerufen werden sollen, können Sie den Service Worker ganz umgehen und Ressourcen sofort abrufen. Die Methode InstallEvent.addRoutes() kann verwendet werden, um diesen Anwendungsfall und mehr zu implementieren.

Weitere Anwendungsbeispiele

Service Worker sind auch beabsichtigt für Dinge wie:

Synchronisierung von Hintergrunddaten.
Reagieren auf Ressourcenerfordernisse aus anderen Ursprüngen.
Zentrale Updates für Daten zu erhalten, deren Berechnung teuer ist, beispielsweise Geolokationen oder Gyroskope, damit mehrere Seiten ein Set von Daten verwenden können.
Client-seitige Kompilierung und Abhängigkeitsmanagement von CoffeeScript, Less, CJS/AMD-Modulen etc. für Entwicklungszwecke.
Hooks für Hintergrunddienste.
Benutzerdefinierte Templating basierend auf bestimmten URL-Mustern.
Leistungssteigerungen, z.B. Vorabladen von Ressourcen, die der Benutzer wahrscheinlich bald benötigt, wie die nächsten Bilder in einem Fotoalbum.
API-Mocking.

In Zukunft werden Service Worker in der Lage sein, weitere nützliche Dinge für die Web-Plattform zu erledigen, die sie der nativen App-Leistungsfähigkeit näherbringen. Interessanterweise können und werden andere Spezifikationen beginnen, den Service Worker-Kontext zu nutzen, beispielsweise:

Hintergrund-Synchronisation: Einen Service Worker starten, auch wenn keine Benutzer auf der Seite sind, damit Caches aktualisiert werden können, etc.
Reaktion auf Push-Nachrichten: Einen Service Worker starten, um Benutzern eine Nachricht zu senden, um ihnen mitzuteilen, dass neue Inhalte verfügbar sind.
Reaktion auf eine bestimmte Zeit und Datum.
Betreten eines Geofences.

Schnittstellen

Cache: Repräsentiert den Speicher für Request / Response Objektpaare, die als Teil des Lebenszyklus von ServiceWorker zwischengespeichert werden.
CacheStorage: Repräsentiert den Speicher für Cache Objekte. Es bietet ein zentrales Verzeichnis aller benannten Caches, auf die ein ServiceWorker zugreifen kann, und pflegt eine Zuordnung von Stringnamen zu den entsprechenden Cache Objekten.
Client: Repräsentiert den Bereich eines Service Worker-Clients. Ein Service Worker-Client ist entweder ein Dokument in einem Browser-Kontext oder ein SharedWorker, das von einem aktiven Worker gesteuert wird.
Clients: Repräsentiert einen Container für eine Liste von Client Objekten; der Hauptweg zum Zugriff auf die aktiven Service Worker-Clients am aktuellen Origin.
ExtendableEvent: Verlängert die Lebensdauer der install und activate Ereignisse, die auf dem ServiceWorkerGlobalScope als Teil des Service Worker-Lebenszyklus gesendet werden. Dies stellt sicher, dass funktionale Ereignisse (wie FetchEvent) nicht an den ServiceWorker gesendet werden, bis er Datenbankschemata aktualisiert und veraltete Cache-Einträge löscht usw.
ExtendableMessageEvent: Das Ereignisobjekt eines message Ereignisses, das auf einem Service Worker gesendet wird (wenn eine Nachricht auf dem ServiceWorkerGlobalScope von einem anderen Kontext empfangen wird) — verlängert die Lebensdauer solcher Ereignisse.
FetchEvent: Der Parameter, der in den onfetch Handler übergeben wird, FetchEvent repräsentiert eine Abrufaktion, die auf dem ServiceWorkerGlobalScope eines ServiceWorker gesendet wird. Es enthält Informationen über die Anfrage und die resultierende Antwort und bietet die Methode FetchEvent.respondWith(), die es uns erlaubt, eine beliebige Antwort zurück an die kontrollierte Seite zu liefern.
InstallEvent: Der Parameter, der in eine install Ereignishandlerfunktion übergeben wird, die InstallEvent Schnittstelle repräsentiert eine Installationsaktion, die auf dem ServiceWorkerGlobalScope eines ServiceWorker gesendet wird. Als Kind von ExtendableEvent stellt es sicher, dass funktionale Ereignisse wie FetchEvent während der Installation nicht gesendet werden.
NavigationPreloadManager: Bietet Methoden zum Verwalten der Vorladung von Ressourcen mit einem Service Worker.
ServiceWorker: Repräsentiert einen Service Worker. Mehrere Browsing-Kontexte (z.B. Seiten, Worker usw.) können mit demselben ServiceWorker Objekt assoziiert sein.
ServiceWorkerContainer: Bietet ein Objekt, das den Service Worker als Gesamteinheit im Netzwerk-Ökosystem repräsentiert, einschließlich Einrichtungen zur Registrierung, Deregistrierung und Aktualisierung von Service Workern sowie zum Zugriff auf den Zustand von Service Workern und deren Registrierung.
ServiceWorkerGlobalScope: Repräsentiert den globalen Ausführungskontext eines Service Workers.
ServiceWorkerRegistration: Repräsentiert eine Registrierung eines Service Workers.
WindowClient: Repräsentiert den Bereich eines Service Worker-Clients, der ein Dokument in einem Browser-Kontext ist, das von einem aktiven Worker gesteuert wird. Dies ist ein spezieller Typ von Client Objekt mit einigen zusätzlichen Methoden und Eigenschaften.

Erweiterungen auf andere Schnittstellen

Window.caches und WorkerGlobalScope.caches: Gibt das CacheStorage Objekt zurück, das mit dem aktuellen Kontext assoziiert ist.
Navigator.serviceWorker und WorkerNavigator.serviceWorker: Gibt ein ServiceWorkerContainer Objekt zurück, das Zugriff auf Registrierung, Entfernung, Upgrade und Kommunikation mit den ServiceWorker Objekten für das assoziierte Dokument bietet.

Spezifikationen

Specification
Service Workers

Siehe auch

Using Service Workers
Service Worker Lifecycle
Service workers basic code example
Web-APIs, die mit der Service Worker API verwandt sind: