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 das Erstellen effektiver Offline-Erfahrungen ermöglichen, Netzwerk-Anfragen abfangen und entsprechende Maßnahmen basierend darauf ergreifen, ob das Netzwerk verfügbar ist und Assets, die sich auf dem Server befinden, aktualisieren. Sie ermöglichen auch den Zugriff auf Push-Benachrichtigungen und Background Sync APIs.

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

Konzepte und Nutzung von Service Workern

Ein Service Worker ist ein ereignisgesteuerter Worker, der gegen eine Origin und einen Pfad registriert wird. Er nimmt die Form einer JavaScript-Datei an, die die zugehörige Webseite bzw. -site steuern kann, indem er Navigations- und Ressourcenanfragen abfängt und modifiziert und Ressourcen auf sehr granulare Weise zwischenspeichert, um Ihnen komplette Kontrolle darüber zu geben, wie sich Ihre App in bestimmten Situationen verhält (die offensichtlichste ist, wenn das Netzwerk nicht verfügbar ist).

Service Worker laufen in einem Worker-Kontext: Daher haben sie keinen DOM-Zugriff und laufen in einem anderen Thread als das Haupt-JavaScript, das Ihre App antreibt. Sie sind nicht blockierend und dafür ausgelegt, vollständig asynchron zu sein. Infolgedessen können APIs wie das synchronisierte XHR und der Web Storage nicht innerhalb eines Service Workers verwendet werden.

Service Worker können keine JavaScript-Module dynamisch importieren, und import() löst einen Fehler aus, wenn es im globalen Scope 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 eine bösartige Code-Injektion durch Man-in-the-Middle-Angriffe, und solche Angriffe könnten schlimmer sein, wenn sie Zugang zu diesen mächtigen APIs hätten.

Hinweis: In Firefox können Sie für Tests Service Worker über HTTP (unsicher) betreiben; aktivieren Sie einfach die Option Enable Service Workers over HTTP (when toolbox is open) im Firefox DevTools-Optionen-/Zahnrad-Menü.

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

Hinweis: Service Worker machen starken Gebrauch von Promises, da sie im Allgemeinen darauf warten, dass Antworten eintreffen, nach denen sie mit einer Erfolg- oder Fehlschlagaktion reagieren. Die Architektur von Promises ist hierfür ideal.

Registrierung

Ein Service Worker wird zuerst mit der ServiceWorkerContainer.register()-Methode registriert. Bei Erfolg wird Ihr Service Worker zum Client heruntergeladen und versucht, die Installation/Aktivierung (siehe unten) für URLs, die vom Benutzer innerhalb der gesamten Origin oder eines von Ihnen angegebenen Subsets abgerufen werden, durchzuführen.

Herunterladen, installieren und aktivieren

An diesem Punkt folgt der Lebenszyklus Ihres Service Workers folgenden Schritten:

Herunterladen
Installieren
Aktivieren

Der Service Worker wird sofort heruntergeladen, wenn ein Benutzer erstmals eine von einem Service Worker gesteuerte Webseite/-seite aufruft.

Danach wird er aktualisiert, wenn:

Eine Navigation zu einer in-Scope-Seite 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 die heruntergeladene Datei als neu erkannt wird — entweder im Vergleich zu einem bestehenden Service Worker (byteweise verglichen) oder dem ersten Service Worker, der für diese Seite/Site gefunden wurde.

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 - in diesem Moment wird sie als wartender Worker bezeichnet. Sie wird erst aktiviert, wenn keine Seiten mehr geladen sind, die noch den alten Service Worker verwenden. Sobald keine weiteren Seiten mehr geladen sind, wird der neue Service Worker aktiviert (wird zum aktiven Worker). Die Aktivierung kann früher erfolgen, indem ServiceWorkerGlobalScope.skipWaiting() verwendet wird, und bestehende Seiten können durch den aktiven Worker mit Clients.claim() beansprucht werden.

Sie können auf das install-Ereignis hören; eine Standardaktion besteht darin, Ihren Service Worker bei der Auslösung auf die Nutzung vorzubereiten, zum Beispiel durch das Erstellen eines Caches mithilfe der eingebauten Speicher-API und das Platzieren der Assets darin, die Sie benötigen, um Ihre App offline auszuführen.

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 mit dem FetchEvent-Ereignis reagieren. Sie können die Antwort auf diese Anfragen nach Belieben ändern, indem Sie die FetchEvent.respondWith()-Methode verwenden.

Hinweis: Weil install- und activate-Ereignisse einige Zeit dauern können, stellt die Service Worker Spezifikation eine waitUntil()-Methode zur Verfügung. Sobald sie auf install oder activate-Ereignissen mit einem Promise aufgerufen wird, warten funktionale Ereignisse wie fetch und push, bis das Promise erfolgreich aufgelöst wird.

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

Statisches Routing zur Steuerung der Ressourcenabrufe verwenden

Service Worker können unnötige Leistungskosten verursachen — wenn eine Seite nach langer Zeit zum ersten Mal geladen wird, muss der Browser warten, bis der Service Worker gestartet und ausgeführt ist, 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 die Ressourcen sofort abrufen. Die InstallEvent.addRoutes()-Methode kann verwendet werden, um diesen Anwendungsfall und mehr zu implementieren.

Ideen für weitere Anwendungsfälle

Service Worker sind auch dafür gedacht, für Dinge wie Folgendes verwendet zu werden:

Hintergrund-Datensynchronisation.
Antwort auf Ressourcenanforderungen aus anderen Ursprüngen.
Empfang zentralisierter Aktualisierungen für aufwändig zu berechnende Daten wie Geolokation oder Gyroskop, sodass mehrere Seiten einen Satz von Daten verwenden können.
Client-seitiges Kompilieren und Abhängigkeitsmanagement von CoffeeScript, Less, CJS/AMD-Modulen usw. für Entwicklungszwecke.
Hooks für Hintergrunddienste.
Benutzerdefiniertes Templating basierend auf bestimmten URL-Mustern.
Leistungsverbesserungen, beispielsweise vorab zu laden, was der Benutzer wahrscheinlich bald benötigt, z.B. die nächsten Bilder in einem Fotoalbum.
API-Mocking.

In Zukunft werden Service Worker in der Lage sein, verschiedene andere nützliche Dinge für die Webplattform zu tun, die es auf die native Anwendbarkeit bringen. Interessanterweise können und werden andere Spezifikationen beginnen, den Service Worker-Kontext zu nutzen, zum Beispiel:

Hintergrundsynchronisation: Einen Service Worker auch dann starten, wenn keine Benutzer auf der Seite sind, damit Caches aktualisiert werden können, usw.
Reaktion auf Push-Nachrichten: Einen Service Worker starten, um Benutzer eine Nachricht zu senden und Ihnen mitzuteilen, dass neue Inhalte verfügbar sind.
Reaktion auf eine bestimmte Zeit und Datum.
Eintreten in einen Geofence.

Schnittstellen

Cache: Repräsentiert den Speicher für Request/Response-Objektpaare, die als Teil des Lebenszyklus des ServiceWorker zwischengespeichert werden.
CacheStorage: Repräsentiert den Speicher für Cache-Objekte. Es bietet ein zentrales Verzeichnis von allen benannten Caches, auf die ein ServiceWorker zugreifen kann, und behält eine Zuordnung von String-Namen zu entsprechenden Cache-Objekten bei.
Client: Repräsentiert den Umfang eines Service Worker-Clients. Ein Service Worker-Client ist entweder ein Dokument in einem Browserkontext oder ein SharedWorker, das von einem aktiven Worker gesteuert wird.
Clients: Repräsentiert einen Container für eine Liste von Client-Objekten; die hauptsächliche Methode, um Zugriff auf die aktiven Service Worker-Clients am aktuellen Ursprung zu erhalten.
ExtendableEvent: Verlängert die Lebensdauer der install- und activate-Ereignisse, die auf dem ServiceWorkerGlobalScope als Teil des Lebenszyklus eines Service Workers ausgelöst werden. Es sorgt dafür, dass funktionale Ereignisse (wie FetchEvent) nicht an den ServiceWorker gesendet werden, bevor es Datenbankschemata aktualisiert und veraltete Cache-Einträge löscht usw.
ExtendableMessageEvent: Das Ereignis-Objekt eines message-Ereignisses, das auf einem Service Worker ausgelöst wird (wenn eine Kanalnachricht auf dem ServiceWorkerGlobalScope aus einem anderen Kontext eingeht) — 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 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 willkürliche Antwort an die gesteuerte Seite zurückzugeben.
InstallEvent: Der Parameter, der an eine install-Ereignis-Handler-Funktion übergeben wird, die InstallEvent-Schnittstelle repräsentiert eine Installationsaktion, die auf dem ServiceWorkerGlobalScope eines ServiceWorker ausgelöst wird. Als Kind von ExtendableEvent stellt sie sicher, dass funktionale Ereignisse wie FetchEvent während der Installation nicht ausgelöst werden.
NavigationPreloadManager: 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 assoziiert sein.
ServiceWorkerContainer: Bietet ein Objekt, das den Service Worker als gesamte Einheit im Netzwerk-Ökosystem repräsentiert, einschließlich Funktionen zum Registrieren, Deregistrieren und Aktualisieren von Service Workern sowie zum Zugriff 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 Umfang eines Service Worker-Clients, das ein Dokument in einem Browserkontext ist, gesteuert von einem aktiven Worker. Dies ist eine spezielle Art von Client-Objekt, mit einigen zusätzlichen Methoden und Eigenschaften verfügbar.

Erweiterungen zu anderen Schnittstellen

Window.caches und WorkerGlobalScope.caches: Gibt das CacheStorage-Objekt für den aktuellen Kontext zurück.
Navigator.serviceWorker und WorkerNavigator.serviceWorker: Gibt ein ServiceWorkerContainer-Objekt zurück, das Zugang zur Registrierung, Entfernung, Aktualisierung und Kommunikation mit den ServiceWorker-Objekten für das zugehörige Dokument bietet.

Spezifikationen

Specification
Service Workers

Siehe auch

Using Service Workers
Lebenszyklus eines Service Workers
Beispiel für einfachen Service Worker-Code
Web-APIs, die mit der Service Worker API zusammenhängen:

Help improve MDN

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

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