Service Worker API

Hinweis: Diese Funktion ist in Web Workers verfügbar.

Service Worker fungieren im Wesentlichen als Proxy-Server, die zwischen Webanwendungen, dem Browser und dem Netzwerk (wenn verfügbar) arbeiten. Sie sind unter anderem dazu gedacht, die Erstellung effektiver Offline-Erlebnisse zu ermöglichen, Netzwerk-Anfragen abzufangen und geeignete Maßnahmen zu ergreifen, je nachdem, ob das Netzwerk verfügbar ist, und Assets auf dem Server zu aktualisieren. Zudem ermöglichen sie den Zugriff auf Push-Benachrichtigungen und Hintergrund-Sync-APIs.

Konzepte und Nutzung von Service Worker

Ein Service Worker ist ein ereignisgesteuerter Worker, der für einen Ursprung und einen Pfad registriert ist. Er hat die Form einer JavaScript-Datei, die die mit ihr verbundene Webseite/-seite steuern kann, indem sie Navigations- und Ressourcenanfragen abfängt und modifiziert und in einem sehr granularen Umfang Ressourcen cached, um Ihnen die vollständige Kontrolle zu geben, wie Ihre App in bestimmten Situationen funktioniert (die offensichtlichste ist, wenn das Netzwerk nicht verfügbar ist).

Service Worker laufen in einem 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 sind nicht blockierend und wurden so konzipiert, dass sie vollständig asynchron laufen. Daher können APIs wie synchroner XHR und Web Storage nicht in einem Service Worker verwendet werden.

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

Service Worker sind nur in sicheren Kontexten verfügbar: Das bedeutet, dass ihre Dokumente über HTTPS bereitgestellt werden müssen, obwohl Browser http://localhost auch als sicheren Kontext behandeln, um die lokale Entwicklung zu erleichtern. HTTP-Verbindungen sind anfällig für die Einschleusung von schädlichem Code durch Man-in-the-Middle-Angriffe, und solche Angriffe könnten schlimmer sein, wenn der Zugriff auf diese mächtigen APIs erlaubt wäre.

Hinweis: In Firefox können Service Worker zu Testzwecken auch über HTTP (unsicher) ausgeführt werden; aktivieren Sie einfach die Option Service Workers über HTTP aktivieren (wenn das Toolbox geöffnet ist) in den Firefox-DevTools-Optionen-/Zahnradeinstellungen.

Hinweis: Anders als frühere Versuche in diesem Bereich, wie AppCache, treffen Service Worker keine Annahmen darüber, was Sie versuchen zu tun, um dann bei ungenauen Annahmen nicht zu funktionieren. Stattdessen bieten Service Worker eine viel feinere Kontrolle.

Hinweis: Service Worker nutzen Promises intensiv, da sie in der Regel auf Antworten warten, auf die sie dann mit einer Aktion bei Erfolg oder Misserfolg reagieren können. Die Promise-Architektur eignet sich ideal dafür.

Registrierung

Ein Service Worker wird zuerst mit der Methode ServiceWorkerContainer.register() registriert. Wenn erfolgreich, wird Ihr Service Worker zum Client heruntergeladen und versucht, Installation/Aktivierung (siehe unten) für URLs, die vom Benutzer innerhalb des gesamten Ursprungs oder eines von Ihnen angegebenen Subsets aufgerufen werden.

Herunterladen, installieren und aktivieren

An diesem Punkt folgt Ihr Service Worker dem folgenden Lebenszyklus:

  1. Herunterladen
  2. Installation
  3. Aktivierung

Der Service Worker wird sofort heruntergeladen, wenn ein Nutzer eine von einem Service Worker kontrollierte Seite zum ersten Mal besucht.

Danach wird er aktualisiert, wenn:

  • Eine Navigation zu einer im Gültigkeitsbereich liegenden Seite erfolgt.
  • Ein Ereignis für den Service Worker ausgelöst wird und er in den letzten 24 Stunden nicht heruntergeladen wurde.

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

Wenn es das erste Mal ist, dass ein Service Worker verfügbar gemacht wurde, 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 er der wartende Worker genannt. Er wird nur aktiviert, wenn keine Seiten mehr geladen sind, die den alten Service Worker noch nutzen. Sobald keine Seiten mehr zu laden sind, aktiviert sich der neue Service Worker (wird zum aktiven Worker). Eine schnellere Aktivierung kann mit ServiceWorkerGlobalScope.skipWaiting() erzielt werden und vorhandene Seiten können vom aktiven Worker mit Clients.claim() beansprucht werden.

Sie können auf das install-Ereignis horchen; eine Standardaktion besteht darin, Ihren Service Worker für die Nutzung vorzubereiten, wenn dieses Ereignis ausgelöst wird, beispielsweise durch das Erstellen eines Caches mit der eingebauten Speicher-API und das Ablegen von Assets darin, die Sie für den Offline-Betrieb Ihrer Anwendung benötigen.

Es gibt auch ein activate-Ereignis. Der Punkt, an dem dieses Ereignis eintritt, ist in der Regel ein guter Moment, um alte Caches und andere mit der vorherigen Version Ihres Service Workers verbundene Dinge aufzuräumen.

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

Hinweis: Da install/activate-Ereignisse einige Zeit in Anspruch nehmen könnten, bietet die Service Worker-Spezifikation eine waitUntil()-Methode. Sobald diese auf install- oder activate-Ereignissen mit einem Promise aufgerufen wird, warten Funktionsevents wie fetch und push bis das Promise erfolgreich aufgelöst ist.

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

Verwendung von statischem Routing zur Steuerung, wie Ressourcen abgerufen werden

Service Worker können unnötige Leistungskosten verursachen – wenn eine Seite das erste Mal seit einiger Zeit geladen wird, muss der Browser warten, bis der Service Worker gestartet wird und läuft, um zu wissen, welche Inhalte geladen werden sollen und ob sie aus einem 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 Nutzungsideen

Service Worker sind auch für folgende Dinge gedacht:

  • Synchronisation von Daten im Hintergrund.
  • Anfragen nach Ressourcen von anderen Ursprüngen bearbeiten.
  • Zentralisierte Updates für kostenintensive Daten wie Geolokation oder Gyroskop empfangen, sodass mehrere Seiten einen einzigen Datensatz nutzen können.
  • Client-seitiges Kompilieren und Abhängigkeitsmanagement von CoffeeScript, Less, CJS/AMD-Modulen etc. zu Entwicklungszwecken.
  • Hooks für Hintergrundservices.
  • Benutzerdefiniertes Templating basierend auf bestimmten URL-Mustern.
  • Leistungsverbesserungen, beispielsweise Pre-Fetching von Ressourcen, die der Nutzer bald benötigen könnte, wie die nächsten Bilder in einem Fotoalbum.
  • API-Mocking.

In Zukunft werden Service Worker in der Lage sein, mehrere andere nützliche Dinge für die Webplattform zu tun, die sie näher an die Machbarkeit nativer Apps bringen. Interessanterweise können und werden andere Spezifikationen den Service Worker-Kontext nutzen, zum Beispiel:

  • Hintergrundsynchronisation: Starten Sie einen Service Worker, auch wenn keine Benutzer auf der Seite sind, damit Caches aktualisiert werden können, etc.
  • Reaktion auf Push-Nachrichten: Starten Sie einen Service Worker, um Nutzern eine Nachricht zu senden, die ihnen mitteilt, dass neue Inhalte verfügbar sind.
  • Reaktion auf eine bestimmte Zeit und Datum.
  • Eintritt in einen Geo-Zaun.

Schnittstellen

Cache

Repräsentiert den Speicher für Request / Response-Objektpaare, die als Teil des ServiceWorker-Lebenszyklus zwischengespeichert werden.

CacheStorage

Repräsentiert den Speicher für Cache-Objekte. Es bietet ein Hauptverzeichnis aller benannten Caches, die ein ServiceWorker zugänglich hat, und pflegt eine Zuordnung von Zeichenfolgenamen zu entsprechenden Cache-Objekten.

Client

Repräsentiert den Gültigkeitsbereich 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, um auf die aktiven Service Worker-Clients am aktuellen Ursprung zuzugreifen.

ExtendableEvent

Verlängert die Lebensdauer der install und activate-Ereignisse, die auf dem ServiceWorkerGlobalScope als Teil des Service Worker-Lebenszyklus ausgelöst werden. Dies stellt sicher, dass keine funktionalen Ereignisse (wie FetchEvent) an den ServiceWorker gesendet werden, bis er Datenbankschemata aktualisiert und veraltete Cache-Einträge löscht, usw.

ExtendableMessageEvent

Das Ereignisobjekt eines message-Ereignisses, das bei einem Service Worker ausgelöst wird (wenn eine Kanalnachricht im ServiceWorkerGlobalScope aus einem anderen Kontext empfangen wird) – verlängert die Lebensdauer solcher Ereignisse.

FetchEvent

Der Parameter, der an den onfetch-Handler übergeben wird, FetchEvent repräsentiert einen Abrufvorgang, der auf dem ServiceWorkerGlobalScope eines ServiceWorker ausgelöst wird. Es enthält Informationen über die Anfrage und die resultierende Antwort und bietet die Methode FetchEvent.respondWith(), die es uns ermöglicht, eine beliebige Antwort zurück an die kontrollierte Seite zu liefern.

InstallEvent

Der Parameter, der an eine install-Ereignishandlerfunktion übergeben wird, die InstallEvent-Schnittstelle repräsentiert einen Installationsvorgang, der auf dem ServiceWorkerGlobalScope eines ServiceWorker ausgelöst wird. Als Kind von ExtendableEvent stellt es sicher, dass funktionale Ereignisse wie FetchEvent während der Installation nicht ausgelöst werden.

Bietet Methoden zum Verwalten des Vorladens 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 verbunden sein.

ServiceWorkerContainer

Bietet ein Objekt, das den Service Worker als Gesamteinheit im Netzwerk-Ökosystem repräsentiert, einschließlich Einrichtungen zum Registrieren, Deregistrieren und Aktualisieren von Service Workern sowie zum Zugreifen auf den Status von Service Workern und deren Registrierungen.

ServiceWorkerGlobalScope

Repräsentiert den globalen Ausführungskontext eines Service Workers.

ServiceWorkerRegistration

Repräsentiert eine Service Worker-Registrierung.

WindowClient

Repräsentiert den Gültigkeitsbereich eines Service Worker-Clients, der ein Dokument in einem Browser-Kontext ist und von einem aktiven Worker kontrolliert wird. Dies ist eine spezielle Art von Client-Objekt, mit einigen zusätzlichen Methoden und Eigenschaften.

Erweiterungen zu anderen Schnittstellen

Window.caches und WorkerGlobalScope.caches

Gibt das CacheStorage-Objekt zurück, das dem aktuellen Kontext zugeordnet ist.

Gibt ein ServiceWorkerContainer-Objekt zurück, das Zugriff auf die Registrierung, Entfernung, Aktualisierung und Kommunikation mit den ServiceWorker-Objekten für das zugehörige Dokument bietet.

Spezifikationen

Specification
Service Workers

Siehe auch