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) liegen. Sie dienen unter anderem dazu, die Erstellung effektiver Offline-Erlebnisse zu ermöglichen, Netzwerk-Anfragen abzufangen und basierend auf der Verfügbarkeit des Netzwerks geeignete Maßnahmen zu ergreifen sowie Assets auf dem Server zu aktualisieren. Zudem ermöglichen sie den Zugriff auf Push-Benachrichtigungen und Hintergrund-Sync-APIs.

Hinweis: Service Worker sind eine Art von Web Worker. Sehen Sie sich Web Workers für allgemeine Informationen über Workertypen und Einsatzmöglichkeiten an.

Konzepte und Verwendung von Service Workern

Ein Service Worker ist ein ereignisgesteuerter Worker, der gegen eine Origin und einen Pfad registriert ist. Er besteht aus einer JavaScript-Datei, die die zugehörige Webseite oder -site steuern kann. Dabei werden Navigations- und Ressourcenzugriffe abgefangen und modifiziert, sowie Ressourcen sehr granular zwischengespeichert, um Ihnen die vollständige Kontrolle darüber zu geben, wie Ihre App in bestimmten Situationen reagiert (die offensichtlichste davon ist, wenn das Netzwerk nicht verfügbar ist).

Service Worker laufen in einem Worker-Kontext: Daher haben sie keinen Zugriff auf das DOM und laufen auf einem anderen Thread als das Haupt-JavaScript, das Ihre App antreibt. Sie sind nicht blockierend und für vollständige Asynchronität ausgelegt. Daher können APIs wie synchrones XHR und Web Storage nicht innerhalb eines Service Workers verwendet werden.

Service Worker können keine JavaScript-Module dynamisch importieren, und import() wird einen Fehler verursachen, 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 ihr Dokument über HTTPS bereitgestellt wird, obwohl Browser auch http://localhost als sicheren Kontext behandeln, um die lokale Entwicklung zu erleichtern. HTTP-Verbindungen sind anfällig für bösartige Code-Injektionen durch Manipulator-in-the-Middle (MITM)-Angriffe, und solche Angriffe könnten schlimmer sein, wenn diese leistungsstarken APIs Zugriff gewähren.

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

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

Hinweis: Service Worker verwenden intensiv Promises, da sie im Allgemeinen auf Antworten warten werden, nach denen sie mit einer erfolgten oder fehlgeschlagenen Aktion reagieren. Die Architektur von Promises ist ideal dafür.

Registrierung

Ein Service Worker wird zunächst über die Methode ServiceWorkerContainer.register() registriert. Bei Erfolg wird Ihr Service Worker auf den Client heruntergeladen und versucht, eine Installation/Aktivierung (siehe unten) für vom Benutzer in der gesamten Origin oder einem von Ihnen angegebenen Teilbereich aufgerufene URLs vorzunehmen.

Download, Installation und Aktivierung

An diesem Punkt folgt Ihr Service Worker dem folgenden Lebenszyklus:

Download
Installation
Aktivierung

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

Danach wird er aktualisiert, wenn:

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

Eine Installation wird versucht, wenn festgestellt wird, dass die heruntergeladene Datei neu ist – entweder abweichend von einem bestehenden Service Worker (byteweise verglichen) oder der erste Service Worker, der auf dieser Seite/Site entdeckt wurde.

Wenn dies 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 vorhandener Service Worker verfügbar ist, wird die neue Version im Hintergrund installiert, aber noch nicht aktiviert – zu diesem Zeitpunkt wird sie als wartender Worker bezeichnet. Sie wird erst aktiviert, wenn keine weiteren Seiten geladen sind, die noch den alten Service Worker verwenden. Sobald keine weiteren Seiten geladen werden müssen, aktiviert sich der neue Service Worker (wird zum aktiven Worker). Die Aktivierung kann früher erfolgen, indem ServiceWorkerGlobalScope.skipWaiting() verwendet wird und bestehende Seiten vom aktiven Worker mit Clients.claim() beansprucht werden können.

Sie können das install-Ereignis abhören; eine Standardaktion besteht darin, Ihren Service Worker bei dessen Auslösung zur Nutzung vorzubereiten, zum Beispiel durch Erstellen eines Caches mit der eingebauten Speicher-API und dem Platzieren von Assets darin, die Sie für den Offline-Betrieb Ihrer App benötigen.

Es gibt auch ein activate-Ereignis. Der Zeitpunkt, an dem dieses Ereignis ausgelöst wird, ist im Allgemeinen eine gute Gelegenheit, alte Caches und andere mit der vorherigen Version Ihres Service Workers verknüpfte Dinge zu bereinigen.

Ihr Service Worker kann auf Anfragen über das FetchEvent-Ereignis reagieren. Sie können die Antwort auf diese Anfragen beliebig modifizieren, indem Sie die Methode FetchEvent.respondWith() verwenden.

Hinweis: Da install-/activate-Ereignisse eine Weile dauern können, bis sie abgeschlossen sind, bietet die Service Worker-Spezifikation eine waitUntil()-Methode. Sobald sie für install oder activate-Ereignisse mit einem Promise aufgerufen wird, werden funktionale Ereignisse wie fetch und push warten, bis das Promise erfolgreich aufgelöst ist.

Für ein vollständiges Tutorial, das zeigt, wie Sie Ihr erstes einfaches Beispiel aufbauen, lesen Sie Verwendung von Service Worker.

Verwendung von statischem Routing, um zu kontrollieren, wie Ressourcen abgerufen werden

Service Worker können unnötige Leistungskosten verursachen – wenn eine Seite nach längerer Zeit zum ersten Mal geladen wird, muss der Browser warten, bis der Service Worker hochfährt 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 vollständig umgehen und Ressourcen sofort abrufen. Die Methode InstallEvent.addRoutes() kann verwendet werden, um diese und andere Anwendungsfälle zu implementieren.

Weitere Anwendungsideen

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

Hintergrund-Datensynchronisation.
Beantworten von Ressourzanfragen von anderen Origin.
Zentrale Updates für teuer zu berechnende Daten wie Geolocation oder Gyroskop erhalten, damit mehrere Seiten einen Datensatz nutzen können.
Clientseitige Kompilierung und Abhängigkeitsverwaltung von CoffeeScript, Less, CJS/AMD-Modulen usw. für Entwicklungszwecke.
Hooks für Hintergrunddienste.
Benutzerdefinierte Templating basierend auf bestimmten URL-Mustern.
Leistungssteigerungen, beispielsweise das 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 Webplattform zu tun, die sie näher an die Machbarkeit nativer Apps bringen. Interessanterweise können und werden andere Spezifikationen beginnen, den Service Worker-Kontext zu nutzen, z.B.:

Background Synchronization: Einen Service Worker starten, auch wenn keine Benutzer auf der Seite sind, damit Caches aktualisiert werden können usw.
Auf Push-Nachrichten reagieren: Einen Service Worker starten, um Benutzern eine Nachricht zu senden, dass neue Inhalte verfügbar sind.
Auf ein bestimmtes Datum und eine bestimmte Uhrzeit reagieren.
Einen Geofence betreten.

Schnittstellen

Cache: Repräsentiert den Speicher für Request / Response Objektpaare, die als Teil des Lebenszyklus eines ServiceWorker zwischengespeichert werden.
CacheStorage: Repräsentiert den Speicher für Cache Objekte. Es liefert ein Hauptverzeichnis aller benannten Caches, auf die ein ServiceWorker zugreifen kann, und pflegt eine Zuordnung von Zeichenfolgennamen zu entsprechenden Cache Objekten.
Client: Repräsentiert den Anwendungsbereich eines Service Worker-Clients. Ein Service Worker-Client ist entweder ein Dokument in einem Browserkontext oder ein SharedWorker, der von einem aktiven Worker gesteuert wird.
Clients: Repräsentiert einen Container für eine Liste von Client Objekten; die Hauptmethode, um auf die aktiven Service Worker-Clients an der aktuellen Origin zuzugreifen.
ExtendableEvent: Verlängert die Lebensdauer der install und activate Ereignisse, die auf den ServiceWorkerGlobalScope gesendet werden, als Teil des Lebenszyklus des Service Workers. Dies stellt sicher, dass keine funktionalen Ereignisse (wie FetchEvent) an den ServiceWorker gesendet werden, bevor es Datenbankschemata aktualisiert, veraltete Cacheeinträge löscht usw.
ExtendableMessageEvent: Das Ereignisobjekt eines message Ereignisses, das auf einen Service Worker ausgelöst wird (wenn eine Kanalnachricht im ServiceWorkerGlobalScope von einem anderen Kontext empfangen wird) — verlängert die Lebensdauer solcher Ereignisse.
FetchEvent: Der Parameter, der an den onfetch Handler übergeben wird, FetchEvent repräsentiert eine Abrufaktion, die auf dem ServiceWorkerGlobalScope eines ServiceWorker ausgelöst wird. Es enthält Informationen über die Anfrage und die resultierende Antwort sowie die Methode FetchEvent.respondWith(), die es uns ermöglicht, eine beliebige Antwort an die kontrollierte Seite zurückzugeben.
InstallEvent: Der Parameter, der an eine install Event-Handler-Funktion übergeben wird, die InstallEvent Schnittstelle repräsentiert eine Installationsaktion, 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 gesendet werden.
NavigationPreloadManager: Bietet Methoden zur Verwaltung des Preloadens von Ressourcen mit einem Service Worker.
ServiceWorker: Repräsentiert einen Service Worker. Mehrere Browsing-Kontexte (z.B. Seiten, Worker etc.) können mit demselben ServiceWorker Objekt assoziiert sein.
ServiceWorkerContainer: Bietet ein Objekt, das den Service Worker als Gesamteinheit im Netzwerksystem darstellt, einschließlich Möglichkeiten zur Registrierung, Abmeldung und Aktualisierung von Service Workern sowie zum Zugriff auf den Status von Service Workern und ihren Registrierungen.
ServiceWorkerGlobalScope: Repräsentiert den globalen Ausführungskontext eines Service Workers.
ServiceWorkerRegistration: Repräsentiert eine Service Worker-Registrierung.
WindowClient: Repräsentiert den Anwendungsbereich eines Service Worker-Clients, der ein Dokument in einem Browserkontext ist, kontrolliert von einem aktiven Worker. 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 mit dem aktuellen Kontext verknüpft 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 zugehörige Dokument bietet.

Spezifikationen

Spezifikation
Service Workers Nightly

Siehe auch

Verwendung von Service Workern
Service Worker Lebenszyklus
Beispielcode für grundlegende Service Worker
Lokaler Netzwerkzugriff
Web-APIs, die mit der Service Worker API in Zusammenhang stehen:

Help improve MDN

Erfahren Sie, wie Sie beitragen können Diese Seite wurde automatisch aus dem Englischen übersetzt.

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