Worker – Übersicht

Wie Web Worker und Service Worker die Leistung Ihrer Website verbessern können und wann Sie einen Web Worker und einen Service Worker verwenden

Andrew Guan

Demián Renzulli

In dieser Übersicht wird erläutert, wie Web Worker und Service Worker die Leistung Ihrer Website verbessern können und wann Sie einen Web Worker und einen Service Worker verwenden sollten. Weitere Informationen zu bestimmten Mustern der Fenster- und Service-Worker-Kommunikation finden Sie in dieser Reihe.

So können Mitarbeiter Ihre Website verbessern

Der Browser verwendet einen einzelnen Thread (den Hauptthread), um den gesamten JavaScript-Code auf einer Webseite sowie Aufgaben wie das Rendern der Seite und die automatische Speicherbereinigung auszuführen. Wenn Sie übermäßigen JavaScript-Code ausführen, wird der Hauptthread möglicherweise blockiert. Dadurch kann der Browser die Ausführung dieser Aufgaben verzögern, sodass die Nutzerfreundlichkeit beeinträchtigt wird.

In der iOS-/Android-Anwendungsentwicklung besteht ein gängiges Muster dafür, dass der Hauptthread der Anwendung auf Nutzerereignisse reagieren kann, indem Vorgänge auf zusätzliche Threads verlagert werden. In den neuesten Android-Versionen hat das zu lange Blockieren des Hauptthreads einen App-Absturz zur Folge.

Im Web basiert JavaScript auf dem Konzept eines einzelnen Threads und es fehlen Funktionen, die zum Implementieren eines Multithreading-Modells wie das der einer App erforderlich sind, wie z. B. gemeinsamer Speicher.

Trotz dieser Einschränkungen kann ein ähnliches Muster im Web erzielt werden, wenn Worker Skripts in Hintergrundthreads ausführen, sodass diese Aufgaben ausführen können, ohne den Hauptthread zu beeinträchtigen. Worker sind ein ganzer JavaScript-Bereich, der in einem separaten Thread ohne gemeinsamen Speicher ausgeführt wird.

In diesem Post lernen Sie zwei verschiedene Arten von Workern (Web Worker und Service Worker) und ihre Gemeinsamkeiten und Unterschiede sowie die häufigsten Muster für ihre Verwendung in Produktionswebsites kennen.

Web Worker und Service Worker

Ähnlichkeiten

Web-Worker und Service-Worker sind zwei Arten von Workern, die für Websites zur Verfügung stehen. Sie haben einiges gemeinsam:

• Beide werden in einem sekundären Thread ausgeführt, sodass JavaScript-Code ausgeführt werden kann, ohne den Hauptthread und die Benutzeroberfläche zu blockieren.
• Sie haben keinen Zugriff auf die Objekte Window und Document. Daher können sie nicht direkt mit dem DOM interagieren und haben nur eingeschränkten Zugriff auf Browser-APIs.

Unterschiede

Man könnte meinen, dass die meisten Dinge, die an einen Web Worker delegiert werden können, in einem Service Worker erledigt werden können und umgekehrt. Zwischen den beiden gibt es jedoch wichtige Unterschiede:

• Im Gegensatz zu Web Workern können Sie mit Service Workern mit dem Ereignis fetch Netzwerkanfragen abfangen und im Hintergrund auf Push API-Ereignisse warten (über das Ereignis push).
• Eine Seite kann mehrere Web Worker erzeugen. Ein einzelner Service Worker steuert jedoch alle aktiven Tabs unter dem Bereich, in dem sie registriert wurde.
• Die Lebensdauer des Web Workers ist eng an den Tab gekoppelt, zu dem er gehört, während der Lebenszyklus des Service Workers davon unabhängig ist. Aus diesem Grund wird durch das Schließen des Tabs, auf dem ein Web Worker ausgeführt wird, dieser auch beendet, während ein Service Worker im Hintergrund weiter ausgeführt werden kann, auch wenn auf der Website keine aktiven Tabs geöffnet sind.

Hinweis : Bei relativ kurzen Aufgaben wie dem Senden einer Nachricht wird ein Service Worker vom Browser wahrscheinlich nicht beendet, wenn keine aktiven Tabs vorhanden sind. Wenn die Aufgabe jedoch zu lange dauert, wird der Service Worker vom Browser beendet. Andernfalls besteht ein Risiko für den Datenschutz und den Akku des Nutzers. APIs wie Background Fetch, mit denen Sie eine Beendigung durch den Service Worker vermeiden können.

Anwendungsfälle

Die Unterschiede zwischen beiden Arten von Workern legen nahe, in welchen Situationen einer der beiden Typen verwendet werden sollte:

Anwendungsfälle für Web Worker beziehen sich häufiger auf das Auslagern von Aufgaben (z. B. umfangreiche Berechnungen) auf einen Sekundärthread, um eine Blockierung der Benutzeroberfläche zu vermeiden.

• Beispiel:Das Team, das das Videospiel PROXX entwickelt hat, wollte den Hauptthread so kostenlos wie möglich lassen, um sich um Nutzereingaben und Animationen zu kümmern. Zu diesem Zweck wurden Web Worker verwendet, um die Spiellogik und die Zustandswartung in einem separaten Thread auszuführen.

Service-Worker-Aufgaben beziehen sich im Allgemeinen eher darauf, als Netzwerk-Proxy zu fungieren, Hintergrundaufgaben zu verarbeiten und Dinge wie Caching und Offlinewiedergabe zu erledigen.

Beispiel:In einer Podcast-PWA möchten Sie Nutzern möglicherweise erlauben, vollständige Folgen herunterzuladen, um sie offline anzuhören. Dafür kannst du einen Service Worker und insbesondere die Background Fetch API verwenden. Auf diese Weise muss die Aufgabe nicht unterbrochen werden, wenn der Nutzer den Tab schließt, während die Folge heruntergeladen wird.

Die Benutzeroberfläche wird aktualisiert, um den Fortschritt eines Downloads anzuzeigen (links). Dank der Service Worker kann der Vorgang fortgesetzt werden, wenn alle Tabs geschlossen wurden (rechts).

Tools und Bibliotheken

Die Fenster- und Worker-Kommunikation kann mithilfe verschiedener untergeordneter APIs implementiert werden. Glücklicherweise gibt es Bibliotheken, die diesen Prozess abstrahieren und sich um die häufigsten Anwendungsfälle kümmern. In diesem Abschnitt werden zwei von ihnen behandelt, die sich jeweils um Window to Web Worker bzw. Service Worker kümmern: Comlink und Workbox.

Comlink

Comlink ist eine kleine RPC-Bibliothek (1,6 K), die beim Erstellen von Websites, die Web Worker verwenden, viele zugrunde liegende Details übernimmt. Es wurde bereits auf Websites wie PROXX und Squoosh verwendet. Eine Zusammenfassung der Ziele und Codebeispiele findest du hier.

Workbox

Workbox ist eine beliebte Bibliothek zum Erstellen von Websites, die Service Worker verwenden. Es enthält eine Reihe von Best Practices für Dinge wie Caching, Offlinenutzung, Hintergrundsynchronisierung usw. Das Modul workbox-window bietet eine bequeme Möglichkeit, Nachrichten zwischen dem Service Worker und der Seite auszutauschen.

Nächste Schritte

Im weiteren Verlauf dieser Reihe geht es um Muster für die Fenster- und Service-Worker-Kommunikation:

• Leitfaden für Imperatives Caching: Aufrufen eines Service Workers von der Seite aus, um Ressourcen im Voraus im Cache zu speichern (z.B. in Prefetch-Szenarien).
• Broadcast-Updates: Aufrufen der Seite durch den Service Worker, um über wichtige Updates zu informieren (z.B. wenn eine neue Version der Website verfügbar ist).
• Zwei-Wege-Kommunikation: Delegieren einer Aufgabe an einen Service Worker (z.B. bei einem umfangreichen Download) und Informieren der Seite über den Fortschritt.

Informationen zu Mustern der Fenster- und Web-Worker-Kommunikation finden Sie unter Web Worker verwenden, um JavaScript außerhalb des Hauptthreads des Browsers auszuführen.