Service Worker agieren 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-Anfragen abfangen und geeignete Maßnahmen basierend auf der Verfügbarkeit des Netzwerks treffen sowie Assets auf dem Server aktualisieren. Sie ermöglichen ebenfalls den Zugriff auf Push-Benachrichtigungen und Hintergrund-Synchronisations-APIs.

Konzepte und Nutzung von Service Workern

Ein Service Worker ist ein ereignisgesteuerterWorker, der gegen einen Ursprung und einen Pfad registriert ist. Er nimmt die Form einer JavaScript-Datei an, die die mit ihr verknüpfte Webseite/Website steuern kann, indem sie Navigations- und Ressourcenanforderungen abfängt und modifiziert und Ressourcen in sehr granularer Weise zwischenspeichert, um Ihnen die vollständige Kontrolle darüber zu geben, wie Ihre App in bestimmten Situationen (die offensichtlichste ist, wenn das Netzwerk nicht verfügbar ist) reagiert.

Service Worker laufen in einem Worker-Kontext: sie haben daher keinen DOM-Zugriff und laufen auf einem anderen Thread als das Haupt-JavaScript, das Ihre App betreibt. Sie sind nicht blockierend und darauf ausgelegt, vollständig asynchron zu arbeiten. Folglich können APIs wie synchronesXHR undWeb Storage nicht innerhalb eines Service Workers verwendet werden.

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

Service Worker sind nur insicheren Kontexten verfügbar: das bedeutet, dass ihr Dokument über HTTPS bereitgestellt wird, obwohl Browserhttp://localhost ebenfalls als sicheren Kontext behandeln, um die lokale Entwicklung zu erleichtern. HTTP-Verbindungen sind anfällig für bösartige Code-Injektionen durchMan-in-the-Middle-Angriffe, und solche Angriffe könnten schlimmer sein, wenn sie Zugang zu diesen leistungsstarken APIs erhalten.

Registrierung

Ein Service Worker wird zuerst mit der MethodeServiceWorkerContainer.register() registriert. Wenn dies erfolgreich ist, wird Ihr Service Worker zum Client heruntergeladen und versucht, für die vom Benutzer innerhalb des gesamten Ursprungs oder eines von Ihnen spezifizierten Teilbereichs aufgerufenen URLs installiert/aktiviert zu werden (siehe unten).

Herunterladen, Installieren und Aktivieren

An diesem Punkt wird der Lebenszyklus Ihres Service Workers wie folgt ablaufen:

1. Herunterladen
2. Installieren
3. Aktivieren

Der Service Worker wird sofort heruntergeladen, wenn ein Benutzer eine von einem Service Worker kontrollierte Seite/Site das erste Mal aufruft.

Danach wird er aktualisiert, wen:

• Eine Navigation zu einer Seite innerhalb des Geltungsbereichs erfolgt.
• 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 (Byte-weise verglichen), oder der erste für diese Seite/Site gefundene Service Worker ist.

Wenn dies das erste Mal ist, dass ein Service Worker zur Verfügung gestellt wurde, wird die Installation versucht. Nach einer erfolgreichen Installation wird er aktiviert.

Wenn ein vorhandener Service Worker vorhanden ist, wird die neue Version im Hintergrund installiert, aber noch nicht aktiviert — an diesem Punkt wird er alswartender Worker bezeichnet. Er wird erst dann aktiviert, wenn keine neu geladenen Seiten mehr vorhanden sind, die weiterhin den alten Service Worker verwenden. Sobald keine Seiten mehr zu laden sind, aktiviert sich der neue Service Worker (er wird deraktive Worker). Die Aktivierung kann früher durch Nutzung vonServiceWorkerGlobalScope.skipWaiting() erfolgen und bestehende Seiten können vom aktiven Worker beansprucht werden, indemClients.claim() verwendet wird.

Sie können auf dasinstall Ereignis lauschen; eine Standardaktion ist, Ihren Service Worker für die Nutzung vorzubereiten, wenn dies ausgelöst wird, indem Sie zum Beispiel einen Cache mit der integrierten Speicher-API erstellen und Assets darin platzieren, die Sie für den Offline-Betrieb Ihrer App benötigen.

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

Ihr Service Worker kann auf Anforderungen mit demFetchEvent Ereignis reagieren. Sie können die Antwort auf diese Anforderungen auf jede gewünschte Weise modifizieren, indem Sie die MethodeFetchEvent.respondWith() verwenden.

Für ein vollständiges Tutorial, um zu zeigen, wie Sie Ihr erstes einfaches Beispiel aufbauen können, lesen SieUsing Service Workers.

Verwendung von statischem Routing, um zu kontrollieren, 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 und ausgeführt wird, 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, woher bestimmte Inhalte bezogen werden sollen, können Sie den Service Worker ganz umgehen und Ressourcen sofort abrufen. Die MethodeInstallEvent.addRoutes() kann verwendet werden, um diese Anwendungsfälle und mehr zu implementieren.

Weitere Ideen für Anwendungsfälle

Service Worker sollen auch für Dinge wie folgende verwendet werden:

• Hintergrunddaten-Synchronisation.
• Reaktion auf Ressourcenanforderungen aus anderen Ursprüngen.
• Empfang zentralisierter Updates für Daten, deren Berechnung teuer ist, wie z. B. Geolokalisierung oder Gyroskop, sodass mehrere Seiten einen Satz Daten nutzen können.
• Client-seitige Kompilierung und Abhängigkeitsmanagement von CoffeeScript, Less, CJS/AMD-Modulen usw. für Entwicklungszwecke.
• Hooks für Hintergrunddienste.
• Benutzerdefinierte Templating basierend auf bestimmten URL-Mustern.
• Leistungsverbesserungen, z. B. Vorabrufen 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, mehrere andere nützliche Dinge für die Web-Plattform zu tun, die sie der Anwendungsfähigkeit nativer Apps näher bringen werden. Interessanterweise können und werden andere Spezifikationen anfangen, den Service Worker-Kontext zu nutzen, zum Beispiel:

• Hintergrund-Synchronisierung: Starten eines Service Workers, auch wenn keine Benutzer auf der Webseite sind, sodass Caches aktualisiert werden können usw.
• Reagieren auf Push-Nachrichten: Starten eines Service Workers, um Benutzern eine Nachricht zu senden, dass neue Inhalte verfügbar sind.
• Reagieren auf ein bestimmtes Datum & Uhrzeit.
• Eintritt in einen Geofence.

Schnittstellen

Cache

Repräsentiert den Speicher fürRequest /Response Objektpaare, die als Teil desServiceWorker Lebenszyklus zwischengespeichert werden.

CacheStorage

Repräsentiert den Speicher fürCache Objekte. Es bietet ein Hauptverzeichnis aller benannten Caches, auf die einServiceWorker zugreifen kann, und pflegt eine Zuordnung von Namen zu den entsprechendenCache Objekten.

Client

Repräsentiert den Geltungsbereich eines Service Worker Clients. Ein Service Worker Client ist entweder ein Dokument in einem Browser-Kontext oder einSharedWorker, der von einem aktiven Worker gesteuert wird.

Clients

Repräsentiert einen Container für eine Liste vonClient Objekten; der Hauptweg, um auf die aktiven Service Worker Clients am aktuellen Ursprung zuzugreifen.

ExtendableEvent

Verlängert die Lebenszeit derinstall undactivate-Ereignisse, die imServiceWorkerGlobalScope als Teil des Service Worker-Lebenszyklus ausgelöst werden. Dies stellt sicher, dass keine funktionalen Ereignisse (wieFetchEvent) an denServiceWorker gesendet werden, bis er Datenbankschemata aktualisiert und veraltete Cache-Einträge löscht usw.

ExtendableMessageEvent

Das Ereignisobjekt einesmessage Ereignisses, das auf einem Service Worker ausgelöst wird (wenn eine Kanalnachricht imServiceWorkerGlobalScope aus einem anderen Kontext empfangen wird) — verlängert die Lebenszeit solcher Ereignisse.

FetchEvent

Der Parameter, der an denonfetch Handler übergeben wird,FetchEvent repräsentiert eine fetch-Aktion, die imServiceWorkerGlobalScope einesServiceWorker ausgelöst wird. Es enthält Informationen über die Anfrage und die resultierende Antwort und bietet die MethodeFetchEvent.respondWith(), die es uns ermöglicht, eine beliebige Antwort zurück an die kontrollierte Seite zu liefern.

InstallEvent

Der Parameter, der an eineninstall Ereignishandler übergeben wird, dieInstallEvent-Schnittstelle stellt eine Installationsaktion dar, die imServiceWorkerGlobalScope einesServiceWorker ausgelöst wird. Als Kind vonExtendableEvent stellt es sicher, dass funktionale Ereignisse wieFetchEvent während der Installation nicht ausgelöst werden.

NavigationPreloadManager

Bietet Methoden zur Verwaltung der Vorabladen von Ressourcen mit einem Service Worker.

ServiceWorker

Repräsentiert einen Service Worker. Mehrere Browser-Kontexte (z. B. Seiten, Worker usw.) können mit demselbenServiceWorker-Objekt verbunden sein.

ServiceWorkerContainer

Bietet ein Objekt, das den Service Worker als eine gesamte Einheit im Netzwerk-Ökosystem darstellt, einschließlich Einrichtungen zum Registrieren, Abregistrieren und Aktualisieren von Service Workern sowie zum Zugriff auf den Zustand 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 Geltungsbereich eines Service Worker Clients, das ein Dokument in einem Browser-Kontext ist, das von einem aktiven Worker gesteuert wird. Dies ist eine spezielle Art vonClient Objekt, mit einigen zusätzlichen Methoden und Eigenschaften, die verfügbar sind.

Erweiterungen anderer Schnittstellen

Window.caches undWorkerGlobalScope.caches

Gibt dasCacheStorage Objekt zurück, das mit dem aktuellen Kontext verbunden ist.

Navigator.serviceWorker undWorkerNavigator.serviceWorker

Gibt einServiceWorkerContainer Objekt zurück, das Zugriff auf die Registrierung, Entfernung, Aktualisierung und Kommunikation mit denServiceWorker Objekten für dasverbundene Dokument bietet.

Spezifikationen

Siehe auch

• Using Service Workers
• Lebenszyklus von Service Workern
• Grundlegendes Code-Beispiel für Service Worker
• Web-APIs, die mit der Service Worker API verwandt sind:
  • Hintergrund-Fetch-API
  • Hintergrund-Synchronisations-API
  • Inhalts-Index-API
  • Cookie-Store-API
  • Benachrichtigungs-API
  • Zahlungsabwickler-API
  • Push-API
  • Web Periodic Background Synchronization API