Service Worker API

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

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.

Hinweis: Service Worker sind eine Art von Web Worker. Siehe Web Worker für allgemeine Informationen über Workertypen und Anwendungsfälle.

Konzepte und Nutzung von Service Workern

Ein Service Worker ist ein ereignisgesteuerter Worker, 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 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 werfen, wenn es im globalen Scope des Service Workers aufgerufen wird. Statische Importe mit der import-Anweisung sind erlaubt.

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

Hinweis: In Firefox können Sie für Testzwecke Service Worker über HTTP (unsicher) ausführen; aktivieren Sie einfach die Option Enable Service Workers over HTTP (when toolbox is open) im Optionen-/Zahnradmenü der Firefox-Entwicklerwerkzeuge.

Hinweis: Anders als frühere Versuche in diesem Bereich, wie AppCache, gehen Service Worker nicht von Annahmen darüber aus, was Sie versuchen zu tun, sondern geben dann nach, wenn diese Annahmen nicht genau richtig sind. Stattdessen geben Service Worker Ihnen eine viel granularere Kontrolle.

Hinweis: Service Worker machen intensiv Gebrauch von Promises, da sie im Allgemeinen auf Antworten warten müssen, nach denen sie mit einer Erfolgs- oder Fehlermeldung reagieren. Die Promise-Architektur ist ideal dafür.

Registrierung

Ein Service Worker wird zuerst mit der Methode ServiceWorkerContainer.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:

Herunterladen
Installieren
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 als wartender 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 der aktive Worker). Die Aktivierung kann früher durch Nutzung von ServiceWorkerGlobalScope.skipWaiting() erfolgen und bestehende Seiten können vom aktiven Worker beansprucht werden, indem Clients.claim() verwendet wird.

Sie können auf das install 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 ein activate 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 dem FetchEvent Ereignis reagieren. Sie können die Antwort auf diese Anforderungen auf jede gewünschte Weise modifizieren, 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 zur Verfügung. Sobald diese in install oder activate-Ereignissen mit einem Promise aufgerufen wird, werden funktionale Ereignisse wie fetch und push warten, bis das Promise erfolgreich gelöst wurde.

Für ein vollständiges Tutorial, um zu zeigen, wie Sie Ihr erstes einfaches Beispiel aufbauen können, lesen Sie Using 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 Methode InstallEvent.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ü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, auf die ein ServiceWorker zugreifen kann, und pflegt eine Zuordnung von Namen zu den entsprechenden Cache Objekten.
Client: Repräsentiert den Geltungsbereich eines Service Worker Clients. Ein Service Worker Client ist entweder ein Dokument in einem Browser-Kontext oder ein SharedWorker, der 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 Lebenszeit der install und activate-Ereignisse, die im 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 auf einem Service Worker ausgelöst wird (wenn eine Kanalnachricht im ServiceWorkerGlobalScope aus einem anderen Kontext empfangen wird) — verlängert die Lebenszeit solcher Ereignisse.
FetchEvent: Der Parameter, der an den onfetch Handler übergeben wird, FetchEvent repräsentiert eine fetch-Aktion, die im 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 einen install Ereignishandler übergeben wird, die InstallEvent-Schnittstelle stellt eine Installationsaktion dar, die im 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.
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 demselben ServiceWorker-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 von Client Objekt, mit einigen zusätzlichen Methoden und Eigenschaften, die verfügbar sind.

Erweiterungen anderer Schnittstellen

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

Spezifikationen

Specification
Service Workers Nightly

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:

Help improve MDN

Learn how to contribute Diese Seite wurde automatisch aus dem Englischen übersetzt.

Übersetzung auf GitHub anzeigen • Fehler mit dieser Übersetzung melden