Workbox: Ihr Service Worker-Toolkit auf höchster Ebene

Jeff Posnick

Zwei APIs spielen beim Erstellen zuverlässiger Webanwendungen eine entscheidende Rolle: Service Worker und Cache Storage. Es kann jedoch eine Herausforderung sein, sie effektiv zu nutzen, ohne kleine Fehler einzubauen oder auf Grenzfälle zu stoßen. Beispielsweise können Fehler in Ihrem Service Worker-Code zu Caching-Problemen führen, sodass Nutzern möglicherweise veraltete Inhalte oder fehlerhafte Links angezeigt werden.

Workbox ist ein allgemeines Service Worker-Toolkit, das auf den Service Workern und Cache Storage APIs basiert. Es bietet einen produktionsreifen Satz von Bibliotheken, mit denen Webanwendungen Offlineunterstützung hinzugefügt werden können. Das Toolkit ist in zwei Sammlungen strukturiert: Tools zum Verwalten von Code, der in Ihrem Service Worker ausgeführt wird, und Tools, die sich in Ihren Build-Prozess einbinden.

Laufzeitcode

Dieser Code wird in Ihrem Service Worker-Skript ausgeführt und steuert, wie ausgehende Anfragen abgefangen und mit der Cache Storage API interagiert werden. Workbox umfasst insgesamt etwa 10 Bibliotheksmodule, die jeweils eine Vielzahl von speziellen Anwendungsfällen abdecken. Die wichtigsten Module bestimmen, ob der Service Worker antwortet (Routing genannt) und wie er antwortet (Caching-Strategie).

Integration erstellen

Workbox bietet Tools für Befehlszeilen, Node.js-Module und Webpack-Plug-in, die alternative Möglichkeiten für zwei Dinge bieten:

  • Erstellen Sie ein Service Worker-Skript anhand einer Reihe von Konfigurationsoptionen. Der generierte Service Worker verwendet die Laufzeitbibliotheken von Workbox im Hintergrund, um die von Ihnen konfigurierten Caching-Strategien in die Tat umzusetzen.
  • Erstellen Sie eine Liste von URLs, die im Voraus im Cache gespeichert werden sollen. Diese Liste basiert auf konfigurierbaren Mustern, um Dateien, die während des Build-Prozesses generiert wurden, ein- oder auszuschließen.

Warum sollte ich Workbox verwenden?

Die Verwendung von Workbox beim Erstellen eines Service Workers ist optional. Es gibt eine Reihe von Leitfäden, die gängige Caching-Strategien aus der einfachen Service-Worker-Perspektive durchgehen. Wenn Sie sich für Workbox entscheiden, finden Sie hier einige seiner Vorteile.

Cache-Verwaltung

Workbox übernimmt die Cache-Aktualisierungen für Sie, die entweder an Ihren Build-Prozess gebunden sind, wenn Sie Precaching verwenden, oder über konfigurierbare Größen-/Altersrichtlinien, wenn das Laufzeit-Caching verwendet wird. Die zugrunde liegende Cache Storage API ist leistungsstark, bietet aber keine integrierte Unterstützung für den Cache-Ablauf. Tools wie Workbox schließen diese Lücke.

Umfassendes Logging und Error Reporting

Bei den ersten Schritten mit Service Workern ist es nicht leicht, herauszufinden, warum etwas im Cache gespeichert wird (oder warum es nicht im Cache gespeichert ist). Workbox erkennt automatisch, wenn Sie eine Entwicklungsversion Ihrer Website unter localhost ausführen, und aktiviert die Protokollierung der Fehlerbehebung in der JavaScript-Konsole Ihres Browsers.

Workbox-Protokollierung in der Entwicklertools-Konsole

Wenn Sie den Logeinträgen folgen, können Sie etwaige Konfigurations- oder Entwertungsprobleme viel schneller finden, als wenn Sie es allein tun würden.

Getestete, browserübergreifende Codebasis

Workbox wurde für eine browserübergreifende Testsuite entwickelt und greift, wenn möglich, automatisch auf alternative Implementierungen von Funktionen zurück, die in bestimmten Browsern fehlen.

Wie sollten Sie Workbox verwenden?

Framework-Integration

Wenn Sie ein neues Projekt von Grund auf beginnen, können Sie die Workbox-Integration nutzen, die in vielen beliebten Starterkits und Add-on-Plug-ins enthalten ist:

Workbox einem vorhandenen Build-Prozess hinzufügen

Wenn Sie bereits einen Build-Prozess für Ihre Website eingerichtet haben, benötigen Sie möglicherweise nur die entsprechende Befehlszeile, das Node.js-Modul oder das Webpack-Plug-in-Tool, um Workbox zu verwenden.

Insbesondere die Workbox-Befehlszeile erleichtert den Einstieg und bietet einen wizard-Modus, der Ihre lokale Entwicklungsumgebung überprüft und eine angemessene Standardkonfiguration vorschlägt, die Sie für die Zukunft verwenden können:

workbox wizard
? What is the root of your web app (i.e. which directory do you deploy)? src/
? Which file types would you like to precache? css, js, html
? Where would you like your service worker file to be saved? build/sw.js
? Where would you like to save these configuration options? workbox-config.js

Führen Sie zum Erstellen des Service Workers workbox generateSW workbox-config.js als Teil eines Build-Prozesses aus. Weitere Informationen finden Sie in der generateSW-Dokumentation. Sie können den Service Worker weiter anpassen, indem Sie Änderungen an workbox-config.js vornehmen. Weitere Informationen finden Sie in der Dokumentation zu den Optionen.

Workbox zur Laufzeit in einem vorhandenen Service Worker verwenden

Wenn Sie bereits einen Service Worker haben und die Laufzeitumgebungen von Workbox testen möchten, importieren Sie Workbox aus seinem offiziellen CDN und verwenden Sie es sofort für das Laufzeit-Caching. In diesem Anwendungsfall können Sie das Precaching nicht nutzen (was eine Build-Time-Integration erfordert), aber es eignet sich hervorragend für das Prototyping und das spontane Testen verschiedener Caching-Strategien.

// Replace 3.6.3 with the current version number of Workbox.
importScripts('https://storage.googleapis.com/workbox-cdn/releases/3.6.3/workbox-sw.js');

workbox.routing.registerRoute(
  new RegExp('\.png$'),
  workbox.strategies.cacheFirst({
    cacheName: 'images-cache',
  })
);