At Your Service

Einführung in Service Worker

At Your Service

Mit Service Workern ist es möglich, per JavaScript bestimmte Dienste auch dann auszuführen, wenn der Nutzer die dazugehörige Website gar nicht geöffnet hat. Eine kleine Einführung in eine Technologie mit großem Potential.

Prognosen, insbesondere die Zukunft betreffend, sind ja bekanntermaßen so eine Sache. Dennoch ist zu konstatieren, dass in naher Zukunft alle modernen Browser eine Technologie unterstützen werden, die Websites und -applikationen mit großen Schritten in Richtung »nativer Applikation« führen wird: Service Worker. Diese

ermöglichen das kontrollierte Speichern und Bereithalten von Website-Inhalten auf den Endgeräten der Nutzer.
geben Websites die Fähigkeit zu »erkennen«, wenn kein Netzwerk verfügbar ist, und lassen sie etwaige Datenübertragungen auf einen späteren Zeitpunkt verschieben.
bilden darüber hinaus die Grundlage für Push Notifications. Was sich hinter diesen Website-gesteuerten Mitteilungen verbirgt, beschrieb Sascha Postner bereits 2015 bei den Webkrauts.

Hier ein paar Beispiele aus der Praxis:

Screenshot von trivago.de mit Hinweis: Das Portal hält die Datenübertragung zurück, bis das Netzwerk wieder verfügbar ist — trivago.de hält die Datenübertragung zurück, bis das Netzwerk wieder verfügbar ist.

Screenshot: Eigene Offline-Fehlermeldung auf matthiasott.com — Eigene Offline-Fehlermeldung auf matthiasott.com

Screenshot: Ein Beispiel für eine Push Notification aus einem Webkrauts-Artikel von 2015 — Ein Beispiel für eine Push Notification

Service Worker gehören zur Familie der Web Worker und sind JavaScripts, die nicht auf das DOM zugreifen können und sollen. Stattdessen verwalten sie den Zwischenspeicher des Browsers (jedoch nicht den berühmten Browsercache), ausgehende Netzwerk-Requests und machen beide programmatisch steuerbar.

Verpflichtend ist neben einem modernen Browser allerdings eine https-Umgebung, da wir es mit dem Modifizieren von Netzwerk-Anfragen zu tun haben – nichts, was über eine ungesicherte Verbindung passieren sollte. Darüber hinaus braucht der geneigte Webschaffende Kontrolle über den Ablageort des Workers innerhalb der URL-Struktur der Website, denn dieser bestimmt seinen maximalen Einflussbereich (mehr zum Service Worker-»Scope« unten im Artikel).

Ein einfaches Beispielszenario

Stellt euch vor, ihr seid mit folgenden Anforderungen konfrontiert:

Assets (CSS, JavaScript, Bilder etc.) sollen in den Cache geladen werden, um grundsätzlich die Ladezeiten der Website zu verbessern und auf sie im Offline-Fall zurückzugreifen.
Weiterhin soll der Speicher ebenfalls alle besuchten Dokumente innerhalb des Service-Worker-Scopes aufnehmen.
Sofern der Benutzer offline ist und ein noch nicht gecachtes Dokument besucht, soll eine eigene Fehlerseite ausgegeben werden.

Um diese Aufgaben zu meistern, müsst ihr euch mit den wichtigsten Events im Lebenszyklus eines Service Worker vertraut machen: Registrierung und Installation, sowie das Abfangen von Netzwerk-Anfragen (Fetch). Darüber hinaus ist das Aktivierungs-Ereignis interessant – bietet es doch die Möglichkeit, veraltete Cache- oder Service-Worker-Versionen zu entfernen und sich somit beim Erneuern von z.B. CSS- oder JavaScript-Dateien nicht selbst zu überlisten.

Registrierung

Ein Promise-Objekt bildet eine asynchrone Berechnung ab und existiert in drei Zuständen: Zum Start seines Lebenszyklus ist ein Promise pending, also weder erfolgreich (fullfilled) noch gescheitert (rejected). Im Beispielcode dieses Artikels fangen wir den Erfolgsfall mit einem Callback als erstem Parameter von .then(), und den Misserfolgsfall mit einem Callback als erstem Parameter von .catch() ab. Vertiefende Informationen zu Promises bietet unter anderem MDN.

Zunächst fragt ihr ab, ob der Browser Service Worker überhaupt unterstützt. Ist das gegeben, wird das im Folgenden sw.js genannte Script registriert. Im Beispiel ist der Gültigkeitsbereich des Workers ausschließlich der Ordner /test, alle Dateien und Unterverzeichnisse darin. Beachtet hierbei, dass ihr die Angabe scope zwar weglassen könnt, ein Service Worker aber niemals in Ordnern »oberhalb« seines Ablageorts wirken kann.

Der Registrierungs-Vorgang liefert eine Promise (siehe Infokasten) zurück und macht den Erfolgs- und Misserfolgsfall handhabbar. Im Beispiel vermeldet die Konsole die gute oder schlechte Nachricht und schickt die Systemmeldungen gleich mit:

if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js', { scope: '/test/' }).then(
function (reg) {
console.log('Service Worker registiert', reg)
},
function (err) {
console.log('Fehler: ', err)
}
);
}

Installation

Ist das Script erfolgreich registriert und erkennt der Browser den Service Worker als neu (weil er der erste ist, oder weil er einen Unterschied zwischen dem aktiven und dem neuregistrierten feststellt), kann es mit dem nächsten Schritt, der Installation, weitergehen. Dies ist üblicherweise die Gelegenheit für das Befüllen des sogenannten »Static Cache«, beispielsweise:

this.addEventListener('install', function(event) {
event.waitUntil(
caches.open('meinCacheVersion1').then(function(cache) {
return cache.addAll([
'/test/',
'/test/index.html',
'/test/style.css',
'/test/bundle.js',
'/test/logo.jpg',
'/test/sorry-offline.html',
]);
})
);
});

Nun stehen diese Assets theoretisch dem Website-Besucher selbst im Offline-Fall zur Verfügung. Praktisch muss aber noch die Netzwerkanfrage abgefangen und Inhalte aus meinCacheVersion1 zurückgeliefert werden. Das passiert mit dem -Event.

Fetch

In einer idealen Welt befindet sich die angeforderte Ressource in unserem Static Cache:

this.addEventListener('fetch', function(event) {
// Reagiere auf Anfragen mit passenden Ressourcen aus dem Cache
event.respondWith(
caches.match(event.request)
);
});

In der Praxis ist aber mit einer komplexeren Situation zu rechnen: Manche Anfragen können aus dem Cache bedient werden, manche nicht. Da caches.match() einen Promise zurückliefert und diese als rejected zurückkommt, wenn die angeforderte Ressource im Cache nicht gefunden wird, fangt ihr diesen Fall folgendermaßen ab und leitet die Anfrage an das Netzwerk weiter:

this.addEventListener('fetch', function(event) {
// Reagiere auf Anfragen mit passenden Ressourcen aus dem Cache
event.respondWith(
caches.match(event.request)
.catch(function() {
// Wenn das nicht möglich ist, leite sie an das Netzwerk weiter
return fetch(event.request);
})
);
});

Damit seid ihr eigentlich mit einer einfachen Implementierung eines Service Workers fertig. Aber euer Szenario stellt noch weitere Anforderungen – da das fetch-Event erkennt, was an Dateien und Dokumente angefordert wird, können ihr diese Ressourcen nun gleich »im Gallopp« im Cache ergänzen:

this.addEventListener('fetch', function(event) {
event.respondWith(
// Reagiere auf Anfragen mit passenden Ressourcen aus dem Cache
caches.match(event.request).catch(function() {
// Wenn das nicht möglich ist, leite sie an das Netzwerk weiter
return fetch(event.request).then(function(response) {
// Sobald das geschehen ist, befülle 'meinCacheVersion1' mit den angefragten Ressourcen
return caches.open('meinCacheVersion1').then(function(cache) {
cache.put(event.request, response.clone());
return response;
});
});
})
);
});

Wenn sich eine Ressource weder im Cache befindet, noch gerade eine Verbindung zu einem Netzwerk besteht, dann verdient dies ein eigenes Handling. Im Installationsschritt haben wir eine Seite namens sorry-offline.html im Cache abgelegt. Und diese lässt sich für dieses Worst Case Scenario ausgeben – beispielsweise so:

this.addEventListener('fetch', function(event) {
event.respondWith(
// Reagiere auf Anfragen mit passenden Ressourcen aus dem Cache
caches.match(event.request).catch(function() {
// Wenn das nicht möglich ist, leite sie an das Netzwerk weiter
return fetch(event.request).then(function(response) {
// Sobald das geschehen ist, befülle 'meinCacheVersion1' mit den angefragten Ressourcen
return caches.open('meinCacheVersion1').then(function(cache) {
cache.put(event.request, response.clone());
return response;
});
}).catch(function() {
// Scheitert die Cache- und Netzwerkanfrage, liefere sorry-offline.html
return caches.match('/test/sorry-offline.html');
});
})
);
});

Aktivierung

Dass Website-Assets einmal hochgeladen und danach nie wieder angefasst werden, ist völlig unrealistisch. Entsprechend gibt es ein Verfahren, Service Worker (bzw. Caches) zu löschen und zu aktualisieren. Dazu aktualisiert ihr euer install-Event mit den neuen oder geänderten Daten und nutzt das activate-Event, indem ihr alle Caches außer dem aktuellen löscht (hier 'meinCacheVersion2' genannt):

this.addEventListener('activate', function(event) {
let cacheWhitelist = ['meinCacheVersion2'];
// Lösche alle Caches, die nicht in der Whitelist genannt sind
event.waitUntil(
caches.keys().then(function(keyList) {
return Promise.all(keyList.map(function(key) {
if (cacheWhitelist.indexOf(key) === -1) {
return caches.delete(key);
}
}));
})
);
});

Hiermit sind die wesentlichen Vorraussetzungen für ein besseres Offline-Handling einer handelsüblichen Website geschaffen und alle Anforderungen aus Eurem Beispiel-Szenario erfüllt. Service Worker können aber noch mehr, beispielsweise:

Anfragen an das Netzwerk so lange zurückhalten, bis ein Netzwerk wieder verfügbar ist (Background Sync).
Selbst dann Push-Benachrichtigungen ausführen, wenn das Browserfenster geschlossen ist (Push Manager).
Mit der Channel Messaging API kann ein Service Worker mit anderen installierten Workern unabhängig vom Browserkontext (und damit z.B. in zwei iFrames) kommunizieren.

Wie bei allen neuen Technologien stellt sich die Frage nach der Browserunterstützung. Hierzu gibt es aber zwei gute Nachrichten:

Erstens unterstützen Firefox und Chrome Service Worker bereits seit 2015 (ab Version 44, respektive 45). Microsoft hat die volle Unterstützung für Edge 17 angekündigt und stellt eine Vorschau mit dem Windows Insider Release 17063 zur Verfügung. Auch Apple aktiviert mit der Safari Technology Preview 46 seine Service-Worker-Implementierung, sodass mit einem zeitnahen Eintreffen auf den Standardbrowsern von macOS und iOS zu treffen ist. Eine komplette Übersicht hält wie immer caniuse bereit.

Zweitens lassen sich Service Worker ganz im Sinne des Progressive Enhancements einsetzen: Wenn Browser moderne Features nicht unterstützen, ist das nicht weiter tragisch. Benutzer »fähiger« Browser wiederum werden belohnt.

Spätestens, wenn diese Technologie die iOS-Geräte der Entscheider erreicht, wird sich »Service Worker« also vollends zu den beliebten Online-Marketing-Buzzwords »One Pager«, »Responsive« und »Parallax« gesellen.

Wer durch diese – zugegebenermaßen sehr an der Oberfläche kratzende – Vorstellung neugierig auf den steuerbaren Netzwerk-Proxy geworden ist, dem sei der umfassende deutschsprachige Artikel bei MDN Web Docs ans Herz gelegt – sowie die zahlreichen englischsprachigen Quellen und Tutorials zum Thema. Einen winzigen Auschnitt daraus findet ihr hier: