1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
|
---
title: Service Worker API
slug: Web/API/Service_Worker_API
tags:
- API
- Offline
- Referenz
- Service-Worker
- Worker
translation_of: Web/API/Service_Worker_API
---
<div>
<p>{{ServiceWorkerSidebar}}</p>
<p>{{ SeeCompatTable() }}</p>
<p class="summary">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.</p>
</div>
<h2 id="Konzepte_von_Service-Workern_und_deren_Nutzung">Konzepte von Service-Workern und deren Nutzung</h2>
<p>Ein Service-Worker ist ein ereignisgesteuerter <a href="/de/docs/Web/API/Worker">Worker</a>, der an einem Ursprung und einem Pfad registriert ist. Sie ist eine JavaScript-Datei, die in Abhängigkeit zu einer Webseite steht, Anfragen von Ressourcen abfängt und cached. In manchen Situationen kann es das Verhalten der Webseite beeinflussen. Ein häufiger Anwendungsfall ist die Abfrage, ob ein Netzwerk verfügbar ist, oder nicht.</p>
<p>Ein Service-Worker läuft in einem Worker-Kontext. Es hat keinerlei Zugriff auf das DOM und läuft in einem separaten Thread, also isoliert vom JavaScript, dass die Hauptinteraktionslogik der Website steuert. Es läuft vollständig asynchron und verhindert die Ausführung anderer Scripte nicht. Daraus resultiert, dass APIs wie <a href="/en-US/docs/Web/API/XMLHttpRequest">XHR</a> oder <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage">LocalStorage</a> nicht in Service-Workern benutzt werden können.</p>
<p>Service-Worker laufen aus Sicherheitsgründen nur über das HTTPS-Protokoll. Veränderte Netzwerkanfragen könnten "Man in the middle"-Angriffe deutlich leichter machen.</p>
<div class="note">
<p><strong>Hinweis: </strong>Service-Worker haben in Bereichen wie <a href="http://alistapart.com/article/application-cache-is-a-douchebag">AppCache</a> gezeigt, dass sie dort besonders gut genutzt werden können, da sie keine Vermutungen darüber treffen, was Sie machen wollen und brechen ihre Aktionen entsprechend ab. Sie haben deshalb die Kontrolle über alles.</p>
</div>
<div class="note">
<p><strong>Hinweis</strong>: Service-Worker basieren auf <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promises</a>. Generell sind sie abhängig von Anfragen und sie werden mit einer erfolgreichen oder einer fehlerhaften Aktion antworten. Die Architektur ist deshalb ideal dafür.</p>
</div>
<h3 id="Registrierung">Registrierung</h3>
<p>Ein Service-Worker wird über die {{domxref("ServiceWorkerContainer.register()")}}-Methode registriert. Falls sie erfolgreich war, wird Ihr Service-Worker vom Client heruntergeladen und versucht eine Installation/Aktivierung (siehe unten) für URLs, die innerhalb der Quelle liegen oder die URLs, die Sie vorgeben.</p>
<h3 id="Download_Installation_und_Aktivierung">Download, Installation und Aktivierung</h3>
<p>Ihr Service-Worker muss folgenden Lebenszyklus durchlaufen:</p>
<ol>
<li>Download</li>
<li>Installation</li>
<li>Aktivierung</li>
</ol>
<p>Der Service-Worker wird sofort mit heruntergeladen, sobald der Nutzer erstmals eine von Service-Workern kontrollierte Seite aufruft.</p>
<p>Danach wird es alle 24 Stunden neu heruntergeladen. Es kann auch in kürzeren Abständen heruntergeladen werden, aber die 24 Stunden können <strong>nicht </strong>überschritten werden. Damit sollen die Ladezeiten kürzer werden.</p>
<p>Eine Installation wird versucht, wenn die heruntergeladene Datei neu ist, also Unterschiede byteweise verglichen mit dem bestehenden Service-Worker aufweist oder es der erste Service-Worker ist, der für diese Seite heruntergeladen wurde.</p>
<p>Wenn ein Service-Worker erstmals verfügbar ist, wird eine Installation versucht. Nach einer erfolgreichen Installation ist es aktiviert.</p>
<p>Wenn bereits ein bestehender Service-Worker installiert wurde, wird die neue Version im Hintergrund installiert, aber noch nicht aktiviert. Zu diesen Zeitpunkt wartet der Worker, bis alle Seiten heruntergeladen wurden, die noch den alten Service-Worker nutzen. Sobald alle Seiten geladen worden sind, wird der neue Service-Worker aktiviert.</p>
<p>Sie können ein Ereignishandler für das {{domxref("InstallEvent")}} erstellen. Standardmäßig wird der Worker für den Einsatz vorbereitet, wenn das Event feuert. Zum Beispiel beim erstellen eines Caches, bei der die Built-In Storage API verwendet wird und Assets hineingeladen werden, damit die App offline verwendet werden kann.</p>
<p>Außerdem existiert ein <code>activate</code>-Event. Wenn es feuert, ist es ein guter Zeitpunkt die alten Caches und andere Daten zu bereinigen, die mit der vorherigen Version ihres Workers zusammenhängen.</p>
<p>Ihr Service-Worker kann mit dem {{domxref("FetchEvent")}} auf Anfragen antworten. Sie können die Antworten auf die Anfragen verändern, wie Sie wollen. Nutzen Sie dazu die {{domxref("FetchEvent.respondWith") }}-Methode.</p>
<div class="blockIndicator note">
<p><strong>Hinweis:</strong> Weil <code>oninstall</code>/<code>onactivate </code>eine Weile benötigen, um ihre Aktionen abzuschließen, ist es empfehlenswert, eine <code>waitUntil</code>-Methode bereitzustellen, die, wenn <code>oninstall </code>oder<code> onactivate</code> gefeuert werden, ein <code>Promise</code> geliefert wird. Events, die der Funktion dienen, werden dem Service-Worker nicht enthalten und der <code>Promise</code> wird erfolgreich ausgeführt.</p>
</div>
<p>Für eine komplette Anleitung, die zeigt, wie Sie Ihr erstes Beispiel erstellen, siehe <a href="/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers">Using Service Workers</a>.</p>
<h2 id="Weitere_Anwendungsbereiche">Weitere Anwendungsbereiche</h2>
<p>Service-Worker werden auch benutzt für:</p>
<ul>
<li>die Synchronisation von Hintergrunddaten</li>
<li>um auf Anfragen anderer Quellen zu antworten</li>
<li>Um Updates von Daten zu erhalten, die sehr teuer in der Kalkulation sind, wie z. B. Standort-Daten, die dann in einem Datensatz verwendet werden können.</li>
<li>Das clientseitige Kompilieren von CoffeeScript aus Entwicklergründen</li>
<li>Hooks für Hintergrunddienste</li>
<li>Zum Erstellen benutzerdefinierter Templates anhand von URL-Mustern</li>
<li>Performancebeschleunigung wie z. B. das Vorladen von Bildern</li>
</ul>
<p>In Zukunft werden Service-Worker zu weiteren nützlichen Dingen fähig sein, die sie näher an eine native App bringen. Andere Spezifikationen können und werden den Service-Worker-Kontext benutzen. Zum Beispiel:</p>
<ul>
<li><a href="https://github.com/slightlyoff/BackgroundSync">Hintergrund-Synchronisation</a>: Ein Service-Worker kann gestartet werden, wenn keine Nutzer auf der Seite sind, um den Cache zu aktualisieren usw.</li>
<li><a href="/en-US/docs/Web/API/Push_API">Auf Push-Benachrichtigungen reagieren</a>: Ein Service-Worker kann Benachrichtigungen an Nutzer senden, um mitzuteilen, dass neuer Inhalt verfügbar ist,</li>
<li><span class="tlid-translation translation" lang="de"><span title="">Auf eine bestimmte Uhrzeit und ein bestimmtes Datum reagieren</span></span></li>
<li>Damit kann geofencing betrieben werden</li>
</ul>
<h2 id="Schnittstellen">Schnittstellen</h2>
<dl>
<dt>{{domxref("Cache") }}</dt>
<dd>Repräsentiert einen Speicher für {{domxref("Request")}} / {{domxref("Response")}}-Objeltpaare, die als ein Teil des {{domxref("ServiceWorker")}}-Lifecycles agieren.</dd>
<dt>{{domxref("CacheStorage") }}</dt>
<dd>Repräsentiert einen Speicher für {{domxref("Cache")}}-Objekte. Es ist das Hauptverzeichnis für {{domxref("ServiceWorker")}}. Es beinhaltet alle benannten Caches basierend auf Strings, auf die der Worker zugreifen kann.</dd>
<dt>{{domxref("Client") }}</dt>
<dd>Repräsentiert den Gültigkeitsbereich von einem Service-Worker-Client. Ein Service-Worker-Client ist entweder ein Dokument in einem Browser-Kontext oder ein {{domxref("SharedWorker")}}, welches von einem aktiven Worker gesteuert wird.</dd>
<dt>{{domxref("Clients") }}</dt>
<dd>Repräsentiert einen Container von {{domxref("Client")}}-Objekten; die hauptsächtliche Methode, um die aktiven Service-Worker-Clients anzusteuern.</dd>
<dt>{{domxref("ExtendableEvent") }}</dt>
<dd>Erweitert die Lebensdauer der <code>install </code>und <code>activate</code>-Events, die vom {{domxref("ServiceWorkerGlobalScope")}} entfernt werden als teil des Service-Worker-Lebenszyklus. Dies versichert, dass einige Events wie z. B. das {{domxref("FetchEvent")}} nicht vom {{domxref("ServiceWorker")}}, solange sie veraltete Cache-Einträge löschen usw.</dd>
<dt>{{domxref("ExtendableMessageEvent") }}</dt>
<dd>Das Event-Objekt von einem {{event("message_(ServiceWorker)","message")}}-Event, welches von einem Service-Worker gefeuert wird.</dd>
<dt>{{domxref("FetchEvent") }}</dt>
<dd>Die Parameter, die dem {{domxref("ServiceWorkerGlobalScope.onfetch")}}-Handler übergeben werden. <code>FetchEvent </code>repräsentiert eine Fetch-Aktion, die vom {{domxref("ServiceWorkerGlobalScope")}} eines {{domxref("ServiceWorker")}} entfernt wird. Es beinhaltet Information über die Anfrage und der daraus resultierenden Antwort, und stellt die {{domxref("FetchEvent.respondWith", "FetchEvent.respondWith()")}}-Methode bereit. Es ermöglicht eine willkürliche Antwort, die zurück zur kontrollierten Seite gesendet wird.</dd>
<dt>{{domxref("InstallEvent") }}</dt>
<dd>The parameter passed into the {{domxref("ServiceWorkerGlobalScope.oninstall", "oninstall")}} handler, the <code>InstallEvent</code> interface represents an install action that is dispatched on the {{domxref("ServiceWorkerGlobalScope")}} of a {{domxref("ServiceWorker")}}. As a child of {{domxref("ExtendableEvent")}}, it ensures that functional events such as {{domxref("FetchEvent")}} are not dispatched during installation. </dd>
<dt>{{domxref("Navigator.serviceWorker") }}</dt>
<dd>Returns a {{domxref("ServiceWorkerContainer")}} object, which provides access to registration, removal, upgrade, and communication with the {{domxref("ServiceWorker")}} objects for the <a href="https://html.spec.whatwg.org/multipage/browsers.html#concept-document-window">associated document</a>.</dd>
<dt>{{domxref("NotificationEvent") }}</dt>
<dd>The parameter passed into the {{domxref("ServiceWorkerGlobalScope.onnotificationclick", "onnotificationclick")}} handler, the <code>NotificationEvent</code> interface represents a notification click event that is dispatched on the {{domxref("ServiceWorkerGlobalScope")}} of a {{domxref("ServiceWorker")}}.</dd>
<dt>{{domxref("ServiceWorker") }}</dt>
<dd>Represents a service worker. Multiple browsing contexts (e.g. pages, workers, etc.) can be associated with the same <code>ServiceWorker</code> object.</dd>
<dt>{{domxref("ServiceWorkerContainer") }}</dt>
<dd>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.</dd>
<dt>{{domxref("ServiceWorkerGlobalScope") }}</dt>
<dd>Represents the global execution context of a service worker.</dd>
<dt>{{domxref("ServiceWorkerMessageEvent")}}</dt>
<dd>Contains information about an event sent to a {{domxref("ServiceWorkerContainer")}} target. </dd>
<dt>{{domxref("ServiceWorkerRegistration") }}</dt>
<dd>Represents a service worker registration.</dd>
<dt>{{domxref("SyncEvent")}} {{non-standard_inline}}</dt>
<dd>
<p>The SyncEvent interface represents a sync action that is dispatched on the {{domxref("ServiceWorkerGlobalScope")}} of a ServiceWorker. </p>
</dd>
<dt>{{domxref("SyncManager")}} {{non-standard_inline}}</dt>
<dd>Provides an interface for registering and listing sync registrations.</dd>
<dt>{{domxref("WindowClient") }}</dt>
<dd>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 {{domxref("Client")}} object, with some additional methods and properties available.</dd>
</dl>
<h2 id="Spezifikationen">Spezifikationen</h2>
<table class="standard-table">
<tbody>
<tr>
<th scope="col">Spezifikation</th>
<th scope="col">Status</th>
<th scope="col">Kommentar</th>
</tr>
<tr>
<td>{{SpecName('Service Workers', '')}}</td>
<td>{{Spec2('Service Workers')}}</td>
<td>Initial definition.</td>
</tr>
</tbody>
</table>
<h2 id="Browser-Kompatibilität">Browser-Kompatibilität</h2>
<div>{{ CompatibilityTable() }}</div>
<div id="compat-desktop">
<table class="compat-table">
<tbody>
<tr>
<th>Feature</th>
<th>Chrome</th>
<th>Firefox (Gecko)</th>
<th>Internet Explorer</th>
<th>Opera</th>
<th>Safari (WebKit)</th>
</tr>
<tr>
<td>Basic support</td>
<td>{{CompatChrome(40.0)}}</td>
<td>{{ CompatGeckoDesktop("44.0") }}</td>
<td>{{ CompatNo() }}</td>
<td>24</td>
<td>{{ CompatNo() }}</td>
</tr>
<tr>
<td>install/activate events</td>
<td>{{ CompatChrome(40.0) }}</td>
<td>{{ CompatGeckoDesktop("44.0") }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatVersionUnknown() }}</td>
<td>{{ CompatNo() }}</td>
</tr>
<tr>
<td>fetch event/request/<br>
<code>respondWith()</code></td>
<td>{{CompatChrome(40.0)}}</td>
<td>{{ CompatGeckoDesktop("44.0") }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatNo() }}</td>
</tr>
<tr>
<td>caches/cache</td>
<td>
<p class="p1">{{CompatChrome(42.0)}}</p>
</td>
<td>{{ CompatGeckoDesktop("39.0") }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatNo() }}</td>
</tr>
</tbody>
</table>
</div>
<div id="compat-mobile">
<table class="compat-table">
<tbody>
<tr>
<th>Feature</th>
<th>Android</th>
<th>Chrome for Android</th>
<th>Firefox Mobile (Gecko)</th>
<th>Firefox OS</th>
<th>IE Phone</th>
<th>Opera Mobile</th>
<th>Safari Mobile</th>
</tr>
<tr>
<td>Basic support</td>
<td></td>
<td>{{CompatChrome(40.0)}}</td>
<td>{{ CompatGeckoMobile("44.0") }}</td>
<td>{{ CompatVersionUnknown }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatVersionUnknown() }}</td>
<td>{{ CompatNo() }}</td>
</tr>
<tr>
<td> install/activate events</td>
<td>{{ CompatNo() }}</td>
<td>{{CompatChrome(40.0)}}</td>
<td>{{ CompatGeckoMobile("44.0") }}</td>
<td>{{ CompatVersionUnknown }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatVersionUnknown() }}</td>
<td>{{ CompatNo() }}</td>
</tr>
<tr>
<td>fetch event/request/<br>
<code>respondWith()</code></td>
<td>{{ CompatNo() }}</td>
<td>{{CompatChrome(40.0)}}</td>
<td>{{ CompatGeckoMobile("44.0") }}</td>
<td>{{ CompatVersionUnknown }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatNo() }}</td>
</tr>
<tr>
<td>caches/cache</td>
<td>{{ CompatNo() }}</td>
<td>{{CompatChrome(40.0)}}</td>
<td>{{ CompatGeckoMobile("39.0") }}</td>
<td>{{ CompatVersionUnknown }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatNo() }}</td>
<td>{{ CompatNo() }}</td>
</tr>
</tbody>
</table>
</div>
<div class="note">
<p><strong>Note</strong>: 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.</p>
</div>
<h2 id="Siehe_auch">Siehe auch</h2>
<ul>
<li><a href="https://serviceworke.rs">ServiceWorker Cookbook</a></li>
<li><a href="/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers">Using Service Workers</a></li>
<li><a href="https://github.com/mdn/sw-test">Service workers basic code example</a></li>
<li><a href="https://jakearchibald.github.io/isserviceworkerready/">Is ServiceWorker ready?</a></li>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promises</a></li>
<li><a href="/en-US/docs/Web/Guide/Performance/Using_web_workers">Using web workers</a></li>
</ul>
|