Sie versuchen herauszufinden, was ein Service Worker ist? Sie sind nicht allein!
Ein Service-Worker ist ein Skript, das im Hintergrund in einem von der Browser-Benutzeroberfläche getrennten Thread ausgeführt wird. Service Worker machen es möglich, dass eine Website offline funktioniert. Sie sind das technische Kraftpaket, das eine Website zu einer progressiven Web-App aufwertet. Sie ermöglichen eine tiefe Plattformintegration, wie Rich Caching, Push-Benachrichtigungen und Hintergrundsynchronisation.
Service Worker sind als erweiterbare Plattform konzipiert, zusätzliche Funktionen sind derzeit in Planung.
Sie können nicht auf das DOM zugreifen, aber alle Netzwerkanfragen abfangen. Dies gibt den Entwicklern die Möglichkeit zu kontrollieren, wie die Anfragen behandelt werden, und bietet eine reichhaltige Möglichkeit, Websites auch offline funktionieren zu lassen.
Service Worker wurden als „game changer“ für das Web bezeichnet. Ich glaube nicht, dass das übertrieben ist, denn sie ermöglichen viele dringend benötigte Funktionen und machen die Kernarchitektur, die ich jahrelang verwendet habe, nativ.
Service Worker klingen fantastisch!
Das ist die Schlüsseltechnologie oder moderne Web-API hinter Progressive Web Applications. Ohne einen Service Worker ist eine Website nur eine Website, fügen Sie einen Service Worker hinzu und Sie haben jetzt eine Anwendung.
Es gibt einige wichtige Eigenschaften von Service Workern, die Sie verstehen müssen:
- Ein Service Worker ist eine JavaScript-Datei
- Sie werden in einem von der Benutzeroberfläche getrennten Thread ausgeführt
- Sie können nicht direkt auf das DOM zugreifen
- Es gibt einen Lebenszyklus oder eine Reihe von Ereignissen, die ein Service Worker durchläuft, um aktiv zu werden, was später erklärt wird
- Sie sind nur aktiv, solange sie verwendet werden, also keine Belastung der Batterie
- Sie sind auf den Ursprung oder die Domäne beschränkt, in der sie registriert sind
- Service Worker benötigen HTTPS
- Sie können Nachrichten an und von der UI senden
- Sie benötigen keine geöffnete Webseite, um zu funktionieren
- Sie werden von allen gängigen Browsern unterstützt, einschließlich iOS Safari
- Sie sind ähnlich wie Web Worker, aber in vielerlei Hinsicht besser
- Wie funktionieren Service Worker?
- Erweiterbarkeit von Service Workern
- Lebenszyklus von Service Workern
- Wie lange halten Service Worker?
- Wie kann ich überprüfen, ob ein Service Worker registriert ist?
- Wie hebe ich die Registrierung eines Service Workers auf
- Service Worker Caching
- Wie aktualisiere ich meinen Service Worker Cache
- Welche Browser unterstützen Service Worker?
- Was ist der Unterschied zwischen einem Service-Worker und einem Web-Worker
- Was ein Service-Worker nicht kann
Wie arbeiten Service-Worker?
Ein Service-Worker sitzt zwischen dem Browser und dem Netzwerk und agiert wie ein Proxy-Server, der eine Reihe von nicht-benutzerdefinierten Aufgaben erledigt. Sie sind ereignisgesteuert und leben außerhalb des Browser-Prozesses, so dass sie ohne aktive Browser-Sitzung arbeiten können. Der Service Worker ist ein Skript, das in einem von der Benutzeroberfläche getrennten Thread ausgeführt wird. Dadurch kann der Service Worker Aufgaben ausführen, die nicht zur Benutzeroberfläche gehören, und die Leistung einer Website verbessern.
Service Worker werden beendet, wenn sie nicht gebraucht werden, und bei Bedarf wiederhergestellt, so dass sie die CPU nicht belasten und die Batterien nicht entladen. Sie fungieren als programmierbarer Netzwerk-Proxy oder Vermittler zwischen dem Browser und dem Netzwerk und geben Entwicklern die Möglichkeit, die Behandlung von Netzwerkanfragen zu gestalten.
Die erste Leistung, die ein Service Worker einer Website bietet, ist die Möglichkeit, Offline-Funktionen mit granularer Kontrolle zu aktivieren. Dies wird durch eine umfangreiche Caching-API und das Abfangen aller Netzwerkanfragen erreicht, bevor sie das Netzwerk verlassen.
Caching ermöglicht nicht nur Offline-Erlebnisse, sondern Websites können auch sofort geladen werden, wenn sie aus dem Cache abgerufen werden. Das Caching von Service Workern macht das Netzwerk zu einer progressiven Erweiterung oder ist nicht erforderlich, um die Website nutzbar zu machen.
Erweiterbarkeit von Service Workern
Eine unterschätzte Eigenschaft von Service Workern ist ihre Erweiterbarkeit Service Worker sind so konzipiert, dass sie das Rückgrat bilden, das zusätzliche Funktionen unterstützt. Die ersten beiden Funktionen, die in Browsern verfügbar sind, sind native Push-Benachrichtigungen und Hintergrundsynchronisation. Weitere neue APIs werden derzeit erörtert und sollten in naher Zukunft in den Browsern erscheinen.
Service Worker leben in ihrem eigenen Thread und haben keinen Zugriff auf das DOM. Sie haben auch ihren eigenen globalen Bereich, auf den mit dem Objekt „self“ verwiesen wird.
Sie erfordern außerdem, dass eine Website über HTTPS bereitgestellt wird. Diese Anforderung ist auf die leistungsstarken Funktionen zurückzuführen, die Service Worker bieten. HTTPS verhindert viele gängige Angriffe. Heutzutage sollten alle Sites über HTTPS bereitgestellt werden, da die Hürden für die Implementierung beseitigt wurden und sie ein Mindestmaß an Sicherheit bieten.
Sie sind außerdem asynchron. Das bedeutet, dass alle APIs Versprechen unterstützen. Das bedeutet auch, dass bestimmte APIs und Funktionen in Service Workern nicht zugänglich sind. Die bemerkenswerteste ist localStorage. Stattdessen sollten Daten mit IndexedDB gespeichert werden.
Lebenszyklus von Service Workern
Bevor man sich mit diesen großartigen Service Worker-Funktionen beschäftigt, müssen Entwickler den Lebenszyklus verstehen.
Ein Service Worker muss von einer Website registriert werden. Da einige Browser noch keine Service Worker unterstützen, sollten Sie vor der Registrierung eines Service Workers eine Funktionsprüfung durchführen. Dies geschieht durch die Überprüfung auf das Vorhandensein von ’serviceWorker‘ in navigator.
if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(function(registration) { // Registration was successful }) .catch(function(err) { // registration failed :( }); } Um den Service Worker zu registrieren, rufen Sie navigator.serviceWorker.register auf. Übergeben Sie den Pfad zum Service Worker. Die Funktion register gibt ein Versprechen zurück.
Bei Erfolg gibt das Versprechen einen Verweis auf das Registrierungsobjekt des Service Workers zurück. Von dort aus können Sie bei Bedarf spezifische UI-Aufgaben durchführen.
Standard Service Worker Events
- installieren
- aktivieren
- abrufen
- push (wird von Safari nicht unterstützt)
- sync (wird von den meisten Browsern noch nicht unterstützt)
Wenn ein Service Worker registriert wird, tritt das Ereignis „install“ auf.
Beim Pre-Caching wird eine vordefinierte Liste von Dateien, die zur Erstellung einer Seite oder Website benötigt werden, in den Cache aufgenommen, bevor sie angefordert werden. Dabei wird der Cache des Service Workers genutzt, um diese Antworten aufrechtzuerhalten.
self.addEventListener("install", event => { event.waitUntil( caches.open(preCacheName) .then(function (cache) { return cache.addAll(precache_urls); }) ); }); Das Installationsereignis wird nur einmal während der Lebensdauer eines Service Workers ausgelöst. Das Ereignis wird erst wieder ausgelöst, wenn der Service Worker aktualisiert wird.
Das nächste Ereignis, das im Rahmen des Registrierungslebenszyklus ausgelöst wird, ist „activate“. Wenn ein Service Worker installiert wird, wird er nicht sofort aktiv. Die natürliche Reihenfolge ist, dass ein neuer Service-Worker wartet, bis alle Service-Worker-‚Clients‘ geschlossen sind.
Der Grund, warum Service-Worker so konzipiert sind, dass sie nicht sofort aktiv werden, ist, um zu verhindern, dass sie die Benutzererfahrung unterbrechen.
Die Funktion skipWaiting zwingt einen wartenden Service-Worker, aktiv zu werden. Diese Funktion sollte nur verwendet werden, wenn Sie sicher sind, dass der neue Service Worker keine bestehenden Clients unterbricht.
self.skipWaiting(); 
Wenn der Service Worker aktiv wird, wird das ‚activate‘-Ereignis ausgelöst.
self.addEventListener("activate", event => { //on activate event.waitUntil(clients.claim()); }); Dieses Ereignis wird üblicherweise verwendet, um Aufräum- oder Migrationsaufgaben durchzuführen. Zum Beispiel das Entfernen von Legacy-Caches, die mit den neuen Service-Worker-Caches in Konflikt geraten könnten.
Wie lange halten Service Worker?
Es gibt keine feste Regel, wie lange ein Browser einen Service Worker laufen lässt. Intern verwendet die Engine des Browsers eine Reihe von Heuristiken, um zu bestimmen, wann der Service-Worker-Prozess beendet werden soll.
Im Allgemeinen wird der Prozess nach ein oder zwei Minuten, vielleicht sogar schon nach 30 Sekunden, beendet, wenn eine Webseite inaktiv ist.
In Wirklichkeit hängt die genaue Zeit von der Hardware, den Nutzungsmustern usw. ab.
Die gute Nachricht ist, dass es nur eine Handvoll Millisekunden dauert, einen Service Worker einzuschalten. Das ist so schnell, dass Sie keine Latenzzeit bemerken werden. Sie brauchen auch nichts Besonderes zu programmieren, um mit einem Szenario ohne Service Worker umzugehen, Ihre Website wird einfach funktionieren. Die Magie der progressiven Verbesserung
Wie prüfe ich, ob ein Service Worker registriert ist?
Es gibt mehrere Möglichkeiten zu prüfen, ob ein Service Worker registriert ist. Am einfachsten ist es, die Methode serviceworkers.getRegistrations aufzurufen.
navigator.serviceWorker.getRegistrations().then(registrations => { console.log(registrations); });Dies ist ein Code, den Sie zu Ihrem Seitenskript hinzufügen können, um die Registrierung für den technischen Support oder die Fehlersuche bei Entwicklern zu protokollieren.
Die Methode ‚getRegistrations‘ gibt ein Array aller Service Worker zurück, die im aktuellen Bereich oder auf der aktuellen Website registriert sind.
Wenn Sie nur die Registrierung auf der Konsole protokollieren, sollten Sie besser die Registerkarte ‚Anwendung‘ der Entwicklungswerkzeuge betrachten. Dort gibt es ein Unterfenster, in dem die registrierten Service Worker des Ursprungs angezeigt werden. Sie können auch Hintergrundsynchronisierungsereignisse auslösen und Push-Benachrichtigungen testen.
Sie können den Service Worker auch löschen, eine Aktualisierung erzwingen und andere allgemeine Verwaltungsfunktionen nutzen, die bei der Entwicklung helfen.
Der wirkliche Wert, den getRegistrations bietet, ist eine Art Hintertür-Supportfunktion. Wir alle wissen, wie es ist, wenn man jemandem aus der Ferne helfen will und keinen Zugriff auf die DevTools hat, um das Problem wirklich zu beheben. Manchmal möchte man eine Art visuelle Support-Seite oder ein Modal, um Informationen über den Zustand der Anwendung bereitzustellen.
Der durchschnittliche Verbraucher wird nicht wissen, wie er auf die DevTools-Konsole zugreifen kann. Stattdessen können Sie eine Benutzeroberfläche innerhalb der Anwendung erstellen, um die Eigenschaften des Service-Worker-Registrierungsobjekts anzuzeigen.
Wie hebe ich die Registrierung eines Service Workers auf
Hoffentlich werden Sie nicht auf ein Szenario stoßen, in dem Ihr Service-Worker-Code einen Fehler in der Benutzererfahrung verursacht hat. Falls doch, gibt es ein paar Dinge, die Sie tun können, um einen Service Worker zu entfernen oder die Registrierung aufzuheben.
Die meisten Szenarien, in denen Sie einen Service Worker entfernen müssen, sind während der Entwicklung der Anwendung. In diesem Fall können Sie die DevTools verwenden, um den Service Worker zu entfernen oder zu löschen.
Wenn Sie einen bereitgestellten Service Worker entfernen oder löschen müssen, wird es ein wenig komplizierter. Es gibt programmatische Möglichkeiten, um Ihnen aus der Patsche zu helfen.
Lesen Sie mehr über Entfernungsmethoden.
Service Worker Caching
Die Service Worker Spezifikation beinhaltet native Caching-Funktionen. Dies ersetzt den traditionellen appCache, der seit seiner Einführung viele Verwaltungsprobleme verursacht hat. Die Cache-API bietet eine Persistenzschicht, die Netzwerkantworten speichert, die von der entsprechenden Anfrage abgefragt werden können.
Der Schlüssel zur Nutzung des Service-Worker-Caching ist das Service-Worker-Ereignis „fetch“. Dieses Ereignis wird bei jeder Netzwerkanforderung ausgelöst, so dass Sie die Anforderung abfangen und prüfen können, ob die Antwort zwischengespeichert wurde, bevor sie an das Netzwerk weitergeleitet wird.
Durch den Zugriff auf Assets im lokalen Cache können Sie auf teure Netzwerkanforderungen verzichten. Das bedeutet, dass die Website auch dann funktionieren kann, wenn kein Netz vorhanden ist, wenn sie offline ist, wenn die Netzverbindung schlecht ist, wenn die Balken niedrig sind oder wenn eine falsche Mobilfunkverbindung (bekannt als LiFi) besteht.
self.addEventListener("fetch", event => { event.respondWith( fetchFromCache(event) .catch(() => fetch(request) .then(response => addToCache(cacheKey, request, response)) .catch(() => offlineResponse(resourceType, opts)) ) ); }); Im obigen Beispiel prüft der Code, ob eine Antwort zuvor zwischengespeichert wurde. Wenn ja, wird die zwischengespeicherte Antwort zurückgegeben. Wenn nicht, wird die Anfrage an das Netzwerk weitergeleitet.
Wenn die Anfrage zurückkommt, wird die Antwort zwischengespeichert und an die Benutzeroberfläche zurückgegeben.
Wenn das Netzwerk ausfällt, fällt die Logik auf eine Offline-Antwort zurück.
Es gibt eine Menge beweglicher Teile, die im Beispielcode verwendet werden. Ich werde mehr Details in einem Folgeartikel bereitstellen.
Wie aktualisiere ich meinen Service Worker Cache
Ein weit verbreiteter Irrglaube ist, dass eine Netzwerkanforderung, die einmal im Cache gespeichert wurde, für immer gespeichert bleibt. Dies ist nicht der Fall. Sie haben die vollständige Kontrolle darüber, wann und wie der Cache ungültig gemacht und aktualisiert wird.
Dies ist ein sehr komplexes und komplexes Thema. Ich denke, ich kann persönlich etwa drei Dutzend Caching-Strategien aufzählen, die alle einen Weg zur Verwaltung der Cache-Invalidierung oder zur Aktualisierung des Caches beinhalten.
Ich denke, der Schlüssel zur Invalidierung ist die Festlegung entweder eines Zeitwertes für die Invalidierung (time to live), eines Manifests oder eines Aktualisierungsprozesses im Hintergrund. Im letzteren Fall können Sie eine HEAD-Anfrage stellen, um zu sehen, ob eine Aktualisierung auf dem Server stattgefunden hat, indem Sie den Wert des zuletzt aktualisierten Headers mit der Zeit vergleichen, zu der die Antwort zwischengespeichert wurde.
Es gibt keine einheitliche Antwort für jede Anwendung. Sie müssen Ihre Strategie planen und darauf vorbereitet sein, sie anzupassen, wenn Sie sehen, wie Ihre Anwendung genutzt wird.
Welche Browser unterstützen Service Worker?
Alle modernen Browser unterstützen Service Worker, zumindest das Caching. Chrome, FireFox und Edge unterstützen native Push-Benachrichtigungen und Chrome und Edge unterstützen Hintergrundsynchronisation.
Das bedeutet, dass die Kernfunktionen von PWA in allen Geräten und Browsern verfügbar sind. Push und Hintergrundsynchronisation sind Erweiterungen.
Wir haben mehrere Progressive Web Apps entwickelt, die ausgeklügelte Offline-Caching-Strategien erforderten, damit die Anwendungen offline funktionieren, sogar auf iOS. Bei diesen Anwendungen müssen alle Anfragen, auch POST-, PUT- und DELETE-Aktionen, in einer Warteschlange zwischengespeichert werden. Wir haben diese Anwendungen auch unter iOS synchronisiert, wenn bekannt war, dass Verbindungen verfügbar waren.
Was ist der Unterschied zwischen einem Service Worker und einem Web Worker
Service Worker und Web Worker sind ähnliche Werkzeuge. Beide führen Prozesse in einem von der Benutzeroberfläche getrennten Thread aus. Der eigentliche Unterschied liegt im tatsächlichen Nutzungskontext.
Beide haben keinen Zugriff auf das DOM- oder Window-Objekt. Sie sind besser für Middle-Tier- oder lange, prozessintensive Aufgaben geeignet.
Web-Worker werden nur ausgeführt, wenn eine Webseite geöffnet ist und eine Aufgabe von einem Skript auf der Seite ausgelöst wird.
Ein Service-Worker kann ebenfalls ausgeführt werden, wenn eine Seite geöffnet ist, kann aber auch durch ein Plattformereignis wie eine Push-Benachrichtigung ausgelöst werden. Eine Webseite muss nicht geöffnet sein, damit ein Service Worker ausgeführt werden kann.
Service Worker fungieren auch als Proxy zwischen dem Netzwerk und der Benutzeroberfläche. Wenn eine Seite verwendet wird (das häufigste Szenario), laufen alle HTTPS-Netzwerkanfragen durch den Service Worker, wie Sie im Abschnitt Caching gelernt haben.
Die Kommunikation zwischen der Benutzeroberfläche und den beiden Workern erfolgt über die postMessage-Methode und das Message-Ereignis. Wenn Sie bereits Multi-Thread-Programmierung betrieben haben, ist Ihnen dieses Modell sehr vertraut.
Was ein Service Worker nicht tun kann
Service Worker können nicht auf das Window-Objekt zugreifen
Das Window-Objekt wird im UI-Thread ausgeführt, getrennt vom Service-Worker-Thread. Das bedeutet, dass ein Service-Worker keine direkte Manipulation von DOM-Elementen vornehmen kann. Der Service Worker und das Fenster können über die postMessage-Methode kommunizieren. Damit können Nachrichten hin- und hergereicht werden. Auf jeder Seite muss eine Logik vorhanden sein, um die Nachrichten zu verarbeiten und verschiedene Workflows auszulösen.
Service Worker erfordern HTTPS
Da Service Worker so leistungsfähig sind, werden sie nur aktiviert, wenn die Seite über HTTPS bereitgestellt wird. Dies gewährleistet ein gewisses Maß an Sicherheit, damit der Service Worker die Dinge tun kann, für die er gedacht ist.
Über HTTP wäre der Service Worker anfällig für Man-in-the-Middle-Angriffe. Entwickler können auf localhost arbeiten, was uns davon abhält, ein lokales TLS-Zertifikat zu installieren.
Mit anderen Worten lautet die Antwort auf die Frage, ob ein Service Worker über HTTP funktioniert, nein. Die Seite wird immer noch gerendert, aber der Service Worker registriert sich nicht und wird nicht ausgeführt.
Sind nur asynchron
Service Worker sind asynchron, was bedeutet, dass sie Promises und APIs, die Promises verwenden, nutzen und darauf angewiesen sind. Das bedeutet, dass synchrone APIs wie XHR und localStorage für einen Service Worker nicht verfügbar sind. Aber keine Angst, Sie können die Fetch-API (die XHR ersetzt) und IndexedDB verwenden. Die meisten APIs, die nicht direkt mit dem Fensterobjekt interagieren, sind in einem Service Worker zugänglich.