Service Worker – Übersicht

Service Worker sind sehr nützlich, können aber anfangs schwierig sein. Mit Workbox sind Service Worker einfacher zu verwenden. Da Service Worker jedoch schwierige Probleme lösen, ist auch jede Abstraktion dieser Technologie schwierig, ohne sie zu verstehen. Daher wird in den ersten Abschnitten der Dokumentation die zugrunde liegende Technologie beschrieben, bevor wir auf die Workbox-Details eingehen.

Geben Sie chrome://serviceworker-internals/ in die Adressleiste ein, um eine Liste der Service Worker aufzurufen, die ausgeführt wird.

Eine laufende Liste von Service-Workern.

Was bieten Service Worker?

Service Worker sind spezialisierte JavaScript-Assets, die als Proxys zwischen Webbrowsern und Webservern fungieren. Das Ziel besteht darin, die Zuverlässigkeit durch Offlinezugriff zu verbessern und die Seitenleistung zu steigern.

Ein sich immer weiter verbessernder, app-ähnlicher Lebenszyklus

Service Worker sind eine Erweiterung vorhandener Websites. Das bedeutet, dass keine grundlegende Funktionalität beeinträchtigt ist, wenn Nutzer mit Browsern, die keine Service Worker unterstützen, Websites aufrufen, in denen sie verwendet werden. Darum geht es im Web.

Service Worker verbessern Websites schrittweise über einen Lebenszyklus, der plattformspezifischen Anwendungen ähnelt. Überlegen Sie, 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 wird auf Neuerscheinungen aktualisiert.

Der Service Worker-Lebenszyklus ist ähnlich, jedoch mit einem Progressive-Enhancement-Ansatz. Beim ersten Besuch einer Webseite, auf der ein neuer Service Worker installiert wird, stellt der erste Aufruf einer Seite ihre Grundfunktionen bereit, während der Service Worker den Download ausführt. Nachdem ein Service Worker installiert und aktiviert wurde, steuert er die Seite, um die Zuverlässigkeit und Geschwindigkeit zu verbessern.

Zugriff auf eine JavaScript-gesteuerte Caching API

Ein unverzichtbarer Aspekt der Service Worker-Technologie ist die Cache-Schnittstelle, bei der es sich um einen Caching-Mechanismus handelt, 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, kann die Cache-Schnittstelle über JavaScript programmiert werden. Dies bedeutet, dass Caching-Antworten auf Netzwerkanfragen auf der Logik basieren können, die für eine bestimmte Website am besten geeignet ist. Beispiel:

  • Statische Inhalte bei der ersten Anfrage im Cache speichern und sie nur bei jeder nachfolgenden Anfrage aus dem Cache bereitstellen.
  • Das Seiten-Markup wird im Cache gespeichert, aber nur in Offline-Szenarien aus dem Cache bereitgestellt.
  • Sie stellen für bestimmte Assets veraltete Antworten aus dem Cache bereit, aktualisieren sie jedoch im Hintergrund aus dem Netzwerk.
  • Sie streamen Teilinhalte aus dem Netzwerk und stellen sie mit einer App-Shell aus dem Cache zusammen, um die Wahrnehmungsleistung zu verbessern.

Jedes davon ist ein Beispiel für eine Caching-Strategie. Caching-Strategien ermöglichen Offline-Nutzung und können eine bessere Leistung liefern, indem die erneute Validierung mit hoher Latenz durch Umgehen einer Überprüfung des HTTP-Cache gestartet wird. Bevor Sie sich mit Workbox befassen, werden einige Caching-Strategien und Code, der diese Funktionen ermöglicht, vorgestellt.

Eine asynchrone und ereignisgesteuerte API

Die Datenübertragung über das Netzwerk ist grundsätzlich asynchron. Es dauert einige Zeit, bis ein Asset angefordert, ein Server auf diese Anfrage reagiert und die Antwort heruntergeladen wurde. Die dafür benötigte Zeit kann variieren und ist unbestimmt. Service Worker berücksichtigen diese Asynchronität über eine ereignisgesteuerte API und verwenden Callbacks für Ereignisse wie:

Ereignisse können mit einer vertrauten addEventListener API registriert werden. Alle diese Ereignisse können potenziell mit der Cache-Oberfläche interagieren. Insbesondere die Fähigkeit, bei der Weiterleitung von Netzwerkanfragen Callbacks auszuführen, ist für die begehrte Zuverlässigkeit und Geschwindigkeit von entscheidender Bedeutung.

Für asynchrone Arbeit in JavaScript sind Promise erforderlich. Da Versprechen auch async und await untermauern, können diese JavaScript-Funktionen auch verwendet werden, um den Service Worker- (und Workbox!)-Code für eine bessere Entwicklungsumgebung zu vereinfachen.

Precaching und Laufzeit-Caching

Die Interaktion zwischen einem Service Worker und einer Cache-Instanz umfasst zwei verschiedene Caching-Konzepte: das Precaching und das Laufzeit-Caching. Beides ist für die Vorteile eines Service Workers von zentraler Bedeutung.

Beim Precaching werden Assets im Voraus im Cache gespeichert, in der Regel während der Installation eines Service Workers. Dank Precaching können wichtige statische Assets und Materialien, die für den Offlinezugriff benötigt werden, heruntergeladen und in einer Cache-Instanz gespeichert werden. Durch diese Art des Cachings wird auch die Ladegeschwindigkeit für weitere Seiten verbessert, für die vorab im Cache gespeicherte Assets benötigt werden.

Beim Laufzeit-Caching wird eine Caching-Strategie auf Assets angewendet, wenn sie während der Laufzeit vom Netzwerk angefordert werden. Diese Art von Caching ist nützlich, da es den Offline-Zugriff auf Seiten und Assets garantiert, die der Nutzer bereits besucht hat.

In Kombination bieten diese Ansätze zur Verwendung der Cache-Schnittstelle in einem Service Worker einen enormen Vorteil für die Nutzer und bieten ein anwendungsähnliches Verhalten auf ansonsten gewöhnlichen Webseiten.

Isolierung vom Hauptthread

Der Status der JavaScript-Leistung ist eine ständige Herausforderung für das Web und hängt aus Sicht der Nutzer von den Gerätefunktionen und dem Zugriff auf ein Hochgeschwindigkeits-Internet ab. Je mehr JavaScript verwendet wird, desto schwieriger wird es, schnelle Websites zu erstellen, die eine positive Nutzererfahrung bieten.

Service Worker sind wie Web Worker, da ihre gesamte Arbeit auf ihren eigenen Threads erfolgt. Das bedeutet, dass die Aufgaben der Service-Worker nicht mit anderen Aufgaben im Hauptthread um die Aufmerksamkeit konkurrieren. Service Worker sind von Grund auf nutzungsorientiert!

Der Weg in die Zukunft

Diese Dokumentation ist nur eine Übersicht. Es gibt noch einige weitere Themen zu Service Workern, bevor wir uns mit Workbox befassen. Aber seien Sie versichert: Mit einem soliden Verständnis von Service Workern wird die Verwendung von Workbox einfacher und produktiver.