Diese Übersetzung ist unvollständig. Bitte helfen Sie uns, diesen Artikel aus dem Englischen zu übersetzen
Dies ist eine experimentelle Technologie
Da diese Technologie noch nicht definitiv implementiert wurde, sollte die Browserkompatibilität beachtet werden. Es ist auch möglich, dass die Syntax in einer späteren Spezifikation noch geändert wird.
Service worker verhalten sich im Wesentlichen wie Proxy-Server, welche zwischen der Webanwendung bzw. dem Browser und dem Netzwerk (sofern dieses verfügbar ist) sitzen. Sie sollen u. a. das Erstellen wirksamer Offline-Erfahrungen ermöglichen und können Netzwerkanfragen abfangen und passende Maßnahmen abhängig davon ergreifen, ob das Netzwerk verfügbar ist und ob der Server veränderte Ressourcen enthält. Sie erlauben außerdem den Zugriff auf Push-Benachrichtigungen und background sync APIs.
Service worker Konzept und Nutzung
Service workers only run over HTTPS, for security reasons. Having modified network requests wide open to man in the middle attacks would be really bad.
Note: Service Workers win over previous attempts in this area such as AppCache because they don't make assumptions about what you are trying to do and then break when those assumptions are not exactly right; you have granular control over everything.
Note: Service workers make heavy use of promises, as generally they will wait for responses to come through, after which they will respond with a success or failure action. The promises architecture is ideal for this.
Ein service worker wird über die
ServiceWorkerContainer.register() Methode registriert. If successful, your service worker will be downloaded to the client and attempt installation/activation (see below) for URLs accessed by the user inside the whole origin, or inside a subset specified by you.
Download, Installation und Aktivierung
At this point, your service worker will observe the following lifecycle:
The service worker is immediately downloaded when a user first accesses a server worker–controlled site/page.
After that it is downloaded every 24 hours or so. It *may* be downloaded more frequently, but it must be downloaded every 24h to prevent bad scripts from being annoying for too long.
Installation is attempted when the downloaded file is found to be new — either different to an existing service worker (byte-wise compared), or the first service worker encountered for this page/site.
If this is the first time a service worker has been made available, installation is attempted, then after a successful installation it is activated.
If there is an existing service worker available, the new version is installed in the background, but not yet activated — at this point it is called the worker in waiting. It is only activated when there are no longer any pages loaded that are still using the old service worker. As soon as there are no more such pages still loaded, the new service worker activates (becoming the active worker).
You can listen out for the
InstallEvent; a standard action is to prepare your service worker for usage when this fires, for example by creating a cache using the built in storage API, and placing assets inside it that you'll want for running your app offline.
There is also an
activate event. The point where this event fires is generally a good time to clean up old caches and other things associated with the previous version of your service worker.
onactivate could take a while to complete, the service worker spec provides a
waitUntil method that, when called
onactivate, passes a promise. Functional events are not dispatched to the service worker until the promise successfully resolves.
Für eine komplette Anleitung die zeigt wie du dein erstes Beispiel erstellst, siehe Benutze Service Workers.
Service workers are also intended to be used for such things as:
- Background data synchronization
- Responding to resource requests from other origins
- Receiving centralized updates to expensive-to-calculate data such as geolocation or gyroscope, so multiple pages can make use of one set of data
- Client-side compiling and dependency management of CoffeeScript, less, CJS/AMD modules, etc. for dev purposes
- Hooks for background services
- Custom templating based on certain URL patterns
- Performance enhancements, for example pre-fetching resources that the user is likely to need in the near future, such as the next few pictures in a photo album.
In the future, service workers will be able to do a number of other useful things for the web platform that will bring it closer towards native app viability. Interestingly, other specifications can and will start to make use of the service worker context, for example:
- Background synchronization: Start up a service worker even when no users are at the site, so caches can be updated, etc.
- Reacting to push messages: Start up a service worker to send users a message to tell them new content is available.
- Reacting to a particular time & date
- Entering a geo-fence
- Represents the storage for
Responseobject pairs that are cached as part of the
- Represents the storage for
Cacheobjects. It provides a master directory of all the named caches that a
ServiceWorkercan access and maintains a mapping of string names to corresponding
- Represents the scope of a service worker client. A service worker client is either a document in a browser context or a
SharedWorker, which is controlled by an active worker.
- Represents a container for a list of
Clientobjects; the main way to access the active service worker clients at the current origin.
- Extends the lifetime of the
activateevents dispatched on the
ServiceWorkerGlobalScopeas part of the service worker lifecycle. This ensures that any functional events (like
FetchEvent) are not dispatched to the
ServiceWorkeruntil it upgrades database schemas, deletes outdated cache entries, etc.
- The event object of a
messageevent fired on a service worker (when a channel message is received on the
ServiceWorkerGlobalScopefrom another context) — extends the lifetime of such events.
- The parameter passed into the
FetchEventrepresents a fetch action that is dispatched on the
ServiceWorker. It contains information about the request and resulting response, and provides the
FetchEvent.respondWith()method, which allows us to provide an arbitrary response back to the controlled page.
- The parameter passed into the
InstallEventinterface represents an install action that is dispatched on the
ServiceWorker. As a child of
ExtendableEvent, it ensures that functional events such as
FetchEventare not dispatched during installation.
- Returns a
ServiceWorkerContainerobject, which provides access to registration, removal, upgrade, and communication with the
ServiceWorkerobjects for the associated document.
- The parameter passed into the
NotificationEventinterface represents a notification click event that is dispatched on the
- Represents a service worker. Multiple browsing contexts (e.g. pages, workers, etc.) can be associated with the same
- Provides an object representing the service worker as an overall unit in the network ecosystem, including facilities to register, unregister and update service workers, and access the state of service workers and their registrations.
- Represents the global execution context of a service worker.
- Contains information about an event sent to a
- Represents a service worker registration.
The SyncEvent interface represents a sync action that is dispatched on the
ServiceWorkerGlobalScopeof a ServiceWorker.
- Provides an interface for registering and listing sync registrations.
- Represents the scope of a service worker client that is a document in a browser context, controlled by an active worker. This is a special type of
Clientobject, with some additional methods and properties available.
|Service Workers||Arbeitsentwurf||Initial definition.|
|Feature||Chrome||Firefox (Gecko)||Internet Explorer||Opera||Safari (WebKit)|
|Basic support||40.0||44.0 (44.0)||Nicht unterstützt||24||Nicht unterstützt|
|install/activate events||40.0||44.0 (44.0)||Nicht unterstützt||(Ja)||Nicht unterstützt|
||40.0||44.0 (44.0)||Nicht unterstützt||Nicht unterstützt||Nicht unterstützt|
|39.0 (39.0)||Nicht unterstützt||Nicht unterstützt||Nicht unterstützt|
|Feature||Android||Chrome for Android||Firefox Mobile (Gecko)||Firefox OS||IE Phone||Opera Mobile||Safari Mobile|
|Basic support||40.0||44.0 (44.0)||(Ja)||Nicht unterstützt||(Ja)||Nicht unterstützt|
|install/activate events||Nicht unterstützt||40.0||44.0 (44.0)||(Ja)||Nicht unterstützt||(Ja)||Nicht unterstützt|
||Nicht unterstützt||40.0||44.0 (44.0)||(Ja)||Nicht unterstützt||Nicht unterstützt||Nicht unterstützt|
|caches/cache||Nicht unterstützt||40.0||39.0 (39.0)||(Ja)||Nicht unterstützt||Nicht unterstützt||Nicht unterstützt|
Note: For backwards compatibility, you could choose to use service workers and AppCache on the same web app to do equivalent things (if the AppCache will support doing those things, of course.) What happens in such a case is that browsers that don’t support Service Workers will use AppCache, and those that do will ignore the AppCache and let the service worker take over.