Worker – Übersicht

Wie Web-Worker und Service-Worker die Leistung Ihrer Website verbessern können und wann Sie einen Web-Worker im Vergleich zu einem Service-Worker verwenden sollten.

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 im Vergleich zu einem Service-Worker verwenden sollten. In den anderen Artikeln dieser Reihe finden Sie spezifische Muster für die Kommunikation zwischen Fenster und Service Worker.

Wie Worker Ihre Website verbessern können

Der Browser verwendet einen einzelnen Thread (den Hauptthread), um den gesamten JavaScript-Code auf einer Webseite auszuführen und Aufgaben wie das Rendern der Seite und die automatische Speicherbereinigung auszuführen. Wenn zu viel JavaScript-Code ausgeführt wird, kann der Hauptthread blockiert werden. Dadurch verzögert sich die Ausführung dieser Aufgaben durch den Browser, was die Nutzerfreundlichkeit beeinträchtigt.

Bei der Entwicklung von iOS-/Android-Apps ist es üblich, Vorgänge auf zusätzliche Threads auszulagern, damit der Hauptthread der App verfügbar bleibt, um auf Nutzerereignisse zu reagieren. In den neuesten Android-Versionen führt ein zu langes Blockieren des Hauptthreads sogar zu einem App-Absturz.

Im Web wurde JavaScript auf der Grundlage des Konzepts eines einzelnen Threads entwickelt. Es fehlen die Funktionen, die für die Implementierung eines Multithreading-Modells wie dem von Apps erforderlich sind, z. B. gemeinsam genutzter Speicher.

Trotz dieser Einschränkungen kann im Web ein ähnliches Muster erreicht werden, indem Worker verwendet werden, um Skripts in Hintergrundthreads auszuführen. So können sie Aufgaben ausführen, ohne den Hauptthread zu beeinträchtigen. Worker sind ein vollständiger JavaScript-Bereich, der in einem separaten Thread ohne gemeinsamen Arbeitsspeicher ausgeführt wird.

In diesem Beitrag erfahren Sie mehr über zwei verschiedene Arten von Workern (Web-Worker und Service-Worker), ihre Ähnlichkeiten und Unterschiede sowie die gängigsten Muster für die Verwendung in Produktionswebsites.

Web Worker und Service Worker

Ähnlichkeiten

Web-Worker und Service-Worker sind zwei Arten von Workern, die für Websites verfügbar sind. Sie haben einige Gemeinsamkeiten:

• 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, können also 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, auch in einem Service-Worker erledigt werden können und umgekehrt. Es gibt jedoch wichtige Unterschiede zwischen ihnen:

• Im Gegensatz zu Web Workern können Sie mit Service Workern Netzwerkanfragen (über das Ereignis fetch) abfangen und im Hintergrund auf Push API-Ereignisse (über das Ereignis push) warten.
• Eine Seite kann mehrere Web-Worker erzeugen, aber ein einzelner Service-Worker steuert alle aktiven Tabs im Bereich, mit dem er registriert wurde.
• Die Lebensdauer des Web-Workers ist eng mit dem Tab verknüpft, zu dem er gehört, während der Lebenszyklus des Service-Workers davon unabhängig ist. Aus diesem Grund wird ein Web Worker beendet, wenn der Tab geschlossen wird, in dem er ausgeführt wird. Ein Service Worker kann dagegen im Hintergrund weiterlaufen, auch wenn für die Website keine aktiven Tabs geöffnet sind.

Hinweis: Bei relativ kurzen Aufgaben wie dem Senden einer Nachricht beendet der Browser einen Service Worker wahrscheinlich nicht, wenn keine aktiven Tabs vorhanden sind. Wenn die Aufgabe jedoch zu lange dauert, beendet der Browser den Service Worker, da sonst die Privatsphäre und der Akku des Nutzers gefährdet sind. APIs wie Background Fetch, mit denen Sie die Beendigung des Service Workers vermeiden können.

Anwendungsfälle

Die Unterschiede zwischen den beiden Worker-Typen deuten darauf hin, in welchen Situationen Sie den einen oder den anderen verwenden sollten:

Anwendungsfälle für Web-Worker beziehen sich häufiger auf das Auslagern von Aufgaben (z. B. aufwendige Berechnungen) in einen sekundären Thread, um das Blockieren der Benutzeroberfläche zu vermeiden.

• Beispiel: Das Team, das das Videospiel PROXX entwickelt hat, wollte den Hauptthread so weit wie möglich freihalten, um Nutzereingaben und Animationen zu verarbeiten. Dazu wurden Web-Worker verwendet, um die Spiellogik und die Statusverwaltung in einem separaten Thread auszuführen.

Service Worker-Aufgaben beziehen sich im Allgemeinen eher auf die Funktion als Netzwerk-Proxy, die Verarbeitung von Hintergrundaufgaben und Dinge wie Caching und Offline-Funktionen.

Beispiel: In einer Podcast-PWA können Nutzer ganze Folgen herunterladen, um sie sich offline anzuhören. Zu diesem Zweck können ein Service Worker und insbesondere die Background Fetch API verwendet werden. Wenn der Nutzer den Tab während des Downloads der Folge schließt, wird die Aufgabe nicht unterbrochen.

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

Tools und Bibliotheken

Die Kommunikation zwischen Fenster und Worker kann mithilfe verschiedener Low-Level-APIs implementiert werden. Glücklicherweise gibt es Bibliotheken, die diesen Prozess abstrahieren und die gängigsten Anwendungsfälle abdecken. In diesem Abschnitt werden zwei davon behandelt, die sich um die Kommunikation zwischen Fenster und Web-Workern bzw. Service Workern kümmern: Comlink und Workbox.

Comlink

Comlink ist eine kleine (1,6 KB) RPC-Bibliothek, die viele der zugrunde liegenden Details beim Erstellen von Websites mit Web Workern übernimmt. Es wurde auf Websites wie PROXX und Squoosh verwendet. Eine Zusammenfassung der Gründe und Codebeispiele finden Sie 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 Caching, Offline-Modus, Hintergrundsynchronisierung usw. Das Modul workbox-window bietet eine bequeme Möglichkeit, Nachrichten zwischen dem Service Worker und der Seite auszutauschen.

Nächste Schritte

Im Rest dieser Reihe geht es um Muster für die Kommunikation zwischen Fenster und Service Worker:

• Leitfaden zum imperativen Caching: Ein Service Worker wird von der Seite aufgerufen, um Ressourcen im Voraus im Cache zu speichern (z.B. in Prefetching-Szenarien).
• Updates übertragen: Die Seite wird vom Service Worker aufgerufen, um über wichtige Updates zu informieren (z.B. dass eine neue Version der Website verfügbar ist).
• Zwei-Wege-Kommunikation: Eine Aufgabe an einen Service Worker delegieren (z.B. einen großen Download) und die Seite über den Fortschritt auf dem Laufenden halten.

Muster für die Kommunikation zwischen Fenster und Web-Worker finden Sie unter Web-Worker verwenden, um JavaScript außerhalb des Hauptthreads des Browsers auszuführen.