Service Worker bieten einen enormen Nutzen, können aber anfangs schwierig sein. Mit Workbox ist die Bedienung im Service noch einfacher. Da Service Worker jedoch schwierige Probleme lösen, wird die Abstraktion dieser Technologie schwierig, ohne sie zu verstehen. In den ersten Teilen der Dokumentation wird daher die zugrunde liegende Technologie behandelt, bevor wir auf die Workbox-Besonderheiten eingehen.
Geben Sie chrome://serviceworker-internals/ in die Adressleiste ein, um eine laufende Liste der Service Worker aufzurufen.
Was bieten Service Worker?
Service Worker sind spezialisierte JavaScript-Assets, die als Proxys zwischen Webbrowsern und Webservern fungieren. Sie zielen darauf ab, die Zuverlässigkeit zu verbessern, indem Offlinezugriff bereitgestellt wird, sowie die Seitenleistung zu steigern.
Ein sich immer weiter verbessernder, app-ähnlicher Lebenszyklus
Service Worker sind eine Erweiterung bestehender Websites. Wenn Nutzer in Browsern, die keine Service Worker unterstützen, Websites besuchen, für die sie verwendet werden, steht also keine grundlegende Funktionalität zur Verfügung. Darum geht es im Web.
Service Worker verbessern Websites schrittweise über einen Lebenszyklus, der plattformspezifischen Anwendungen ähnelt. Stellen Sie sich vor, was passiert, wenn eine native App aus einem App-Shop installiert wird:
- Eine Anfrage zum Herunterladen der Anwendung wird gestellt.
- Die App wird heruntergeladen und installiert.
- Die App ist einsatzbereit und kann gestartet werden.
- Die App-Updates für neue Releases.
Der Lebenszyklus des Service Workers ist ähnlich, jedoch wird ein Progressive-Enhancement-Ansatz verwendet. Beim allerersten Besuch einer Webseite, auf der ein neuer Service Worker installiert wird, werden beim ersten Besuch der Seite die Grundfunktionen bereitgestellt, während der Service Worker herunterlädt. Nachdem ein Service Worker installiert und aktiviert wurde, steuert er die Seite, um Zuverlässigkeit und Geschwindigkeit zu verbessern.
Zugriff auf eine JavaScript-gesteuerte Caching API
Ein unverzichtbarer Aspekt der Service Worker-Technologie ist die Cache-Schnittstelle. Sie ist ein Caching-Mechanismus, der vollständig vom HTTP-Cache getrennt ist.
Auf die Schnittstelle Cache kann innerhalb des Service Worker-Bereichs und innerhalb des Hauptthreads zugegriffen werden.
Dies eröffnet unzählige Möglichkeiten für nutzergesteuerte Interaktionen mit einer Cache-Instanz.
Während der HTTP-Cache durch Caching-Anweisungen in HTTP-Headern beeinflusst wird, ist die Cache-Schnittstelle über JavaScript programmierbar.
Das bedeutet, dass die Caching-Antworten für Netzwerkanfragen auf jeder Logik basieren können, die für eine bestimmte Website am besten geeignet ist.
Beispiel:
- Speichern Sie statische Assets bei der ersten Anfrage im Cache und stellen Sie sie nur bei jeder nachfolgenden Anfrage aus dem Cache bereit.
- Speichern Sie das Markup für Seiten im Cache, aber stellen Sie Markup aus dem Cache nur in Offlineszenarien bereit.
- Veraltete Antworten für bestimmte Assets aus dem Cache bereitstellen, aber über das Netzwerk im Hintergrund aktualisieren
- Streamen Sie Teilinhalte aus dem Netzwerk und stellen Sie sie mit einer App-Shell aus dem Cache zusammen, um die Wahrnehmung der Leistung zu verbessern.
Jedes davon ist ein Beispiel für eine Caching-Strategie. Caching-Strategien machen Offline-Erlebnisse möglich und bieten eine bessere Leistung, da Neuvalidierungen mit hoher Latenz umgangen werden, die der HTTP-Cache startet. Bevor wir uns mit Workbox befassen, werden einige Caching-Strategien und Code erläutert, die dafür sorgen, dass sie funktionieren.
Eine asynchrone und ereignisgesteuerte API
Die Übertragung von Daten über das Netzwerk erfolgt von Natur aus asynchron. Es dauert einige Zeit, ein Asset anzufordern, ein Server auf diese Anfrage zu antworten und die Antwort herunterzuladen. Die dafür erforderliche Zeit ist vielfältig und unbestimmt. Service Worker erfüllen diese Asynchronität über eine ereignisgesteuerte API und verwenden Callbacks für Ereignisse wie:
- Wenn ein Service Worker die Installation durchführt
- Wenn ein Service Worker aktiviert wird
- Wenn ein Service Worker eine Netzwerkanfrage erkennt.
Ereignisse können mit einer vertrauten addEventListener API registriert werden.
Alle diese Ereignisse können potenziell mit der Cache-Oberfläche interagieren.
Vor allem die Möglichkeit, Callbacks auszuführen, wenn Netzwerkanfragen weitergeleitet werden, ist von entscheidender Bedeutung, um die begehrte Zuverlässigkeit und Geschwindigkeit zu gewährleisten.
Für asynchrone Aufgaben in JavaScript müssen Promise-Objekte verwendet werden.
Da Promis auch async und await untermauern, können diese JavaScript-Funktionen auch verwendet werden, um Service Worker- (und Workbox!)-Code zu vereinfachen und die Entwicklung zu verbessern.
Pre-Caching und Laufzeit-Caching
Die Interaktion zwischen einem Service Worker und einer Cache-Instanz umfasst zwei verschiedene Caching-Konzepte: Pre-Caching und Laufzeit-Caching.
All das ist von entscheidender Bedeutung für die Vorteile, die ein Service Worker bieten kann.
Beim Precaching werden Assets vorzeitig im Cache gespeichert, in der Regel während der Installation eines Service Workers.
Mit dem Precaching können wichtige statische Assets und Materialien, die für den Offlinezugriff benötigt werden, heruntergeladen und in einer Cache-Instanz gespeichert werden.
Diese Art des Cachings verbessert auch die Seitengeschwindigkeit auf nachfolgende Seiten, die die vorab im Cache gespeicherten Assets benötigen.
Beim Laufzeit-Caching wird eine Caching-Strategie auf Assets angewendet, die während der Laufzeit vom Netzwerk angefordert werden. Diese Art von Caching ist nützlich, da es den Offlinezugriff auf Seiten und Assets garantiert, die der Nutzer bereits besucht hat.
Diese Ansätze zur Verwendung der Cache-Schnittstelle in einem Service Worker bieten in Kombination einen enormen Vorteil für die Nutzerfreundlichkeit und bieten anwendungsähnliches Verhalten auf ansonsten gewöhnlichen Webseiten.
Isolation vom Hauptthread
Der Status der JavaScript-Leistung stellt eine ständige Herausforderung für das Web dar. Aus Sicht der Nutzer ist sie von den Gerätefunktionen und dem Zugang zu Highspeed-Internet abhängig. Je mehr JavaScript verwendet wird, desto schwieriger wird es, schnelle Websites zu erstellen, die eine positive Nutzererfahrung bieten.
Service Worker funktionieren wie Web Worker, da ihre gesamte Arbeit in ihren eigenen Threads stattfindet. Das bedeutet, dass Service Worker-Aufgaben nicht mit anderen Aufgaben im Hauptthread um Aufmerksamkeit konkurrieren. Service Worker stehen bei der Entwicklung im Mittelpunkt.
Der Weg, der vor dir liegt
Diese Dokumentation ist nur eine Übersicht. Es gibt noch einige weitere Themen zu Service Workern, über die wir auf Workbox sprechen können. Aber seien Sie versichert: Wenn Sie sich mit Service Workern auskennen, ist die Verwendung von Workbox einfacher und produktiver.