Precaching mit Workbox

Precaching ist eine der häufigsten Aufgaben in einem Service Worker. Workbox bietet viel Flexibilität darin, diese wichtige Aufgabe zu erledigen, unabhängig davon, für welches der Build-Tools von Workbox Sie sich entscheiden. In diesem Leitfaden erfahren Sie, wie Sie Assets mithilfe von generateSW und injectManifest vorab im Cache speichern und welche dieser Methoden sich am besten für Ihr Projekt eignen.

Precaching mit generateSW

generateSW ist die einfachste Möglichkeit, Assets in Workbox vorab im Cache zu speichern. Der wichtige Punkt bei generateSW ist, dass Sie nicht Ihren eigenen Service Worker schreiben, sondern ihn von Workbox für Sie erstellen lassen. Sie können ihr Verhalten jedoch durch eine Vielzahl von Konfigurationsoptionen beeinflussen.

generateSW führt standardmäßig verschiedene Aktionen aus, je nachdem, welches Build-Tool Sie verwenden. Wenn Sie workbox-webpack-plugin verwenden, müssen Sie keine Konfigurationsoptionen angeben. Standardmäßig speichert das Plug-in alles im Cache des Webpacks im Abhängigkeitsdiagramm und schreibt einen Service Worker mit dem Namen service-worker.js in das von output.path angegebene Verzeichnis

Wenn Sie jedoch workbox-build oder workbox-cli verwenden, werden standardmäßig nur die aus dem lokalen Dateisystem gelesenen HTML-, CSS- und JavaScript-Assets vorab im Cache gespeichert. In Bezug auf die Konfiguration müssen Sie swDest und die Option globDirectory in der generateSW-Konfiguration angeben, damit das Precaching funktioniert. Wahrscheinlich möchten Sie auch zusätzliche Optionen konfigurieren, die sich auf das Verhalten Ihres Service Workers auswirken. Lesen Sie dazu die Dokumentation.

Warnung:Wenn zu viele Assets in Ihrem Projekt mit den Standardeinstellungen vorab im Cache gespeichert wurden, verwenden Sie eine der glob-Optionen, um Ressourcen in der generateSW-Konfiguration auszuschließen. Wenn Sie workbox-webpack-plugin verwenden, lesen Sie in der GenerateSW-Dokumentation des Plug-ins nach, wie Sie verhindern können, dass unerwünschte Assets vorab im Cache gespeichert werden, da sich die Konfiguration von generateSW unterscheidet.

Precaching mit injectManifest

Die Verwendung von injectManifest ist nicht so einfach wie die Verwendung von generateSW, aber bei der Nutzerfreundlichkeit geht die Flexibilität verloren. Während generateSW die gesamte Service Worker-Generation für Sie verarbeitet, verwendet injectManifest einen von Ihnen geschriebenen Service Worker als Quelle und fügt eine Liste von URLs für die Pre-Cache-Speicherung ein. Der Rest des Service Workers bleibt unverändert.

Wenn Sie injectManifest verwenden, sind Sie für die Verkabelung der Precach-Logik verantwortlich. Wenn injectManifest Ihren Eingabe-Service-Worker untersucht, sucht er nach einer speziellen self.__WB_MANIFEST-Variable und ersetzt sie durch das Precache-Manifest. Wenn diese Variable nicht vorhanden ist, gibt injectManifest einen Fehler aus.

Hinweis:Wenn Sie den String, nach dem injectManifest sucht, in einen anderen String als self.__WB_MANIFEST ändern müssen, können Sie die Option injectionPoint in der Konfiguration angeben.

Die Liste der Einträge im Precache-Manifest kann mit zusätzlichen Konfigurationsoptionen optimiert werden.

Achtung: Im Gegensatz zu generateSW bündelt injectManifest die Workbox-Laufzeit nicht automatisch für Sie. Im direkten Vergleich unten erfahren Sie, wie Sie dies in Anwendungsfällen mit injectManifest bewältigen können.

Vergleich

Klicken Sie auf die folgenden Tabs, um die Nutzung der Methoden generateSW und injectManifest zu vergleichen:

Da generateSW einen Service Worker generiert, müssen Sie nur eine Konfiguration angeben. Hier ein Beispiel mit workbox-build:

// build-sw.js
import {generateSW} from 'workbox-build';

generateSW({
  swDest: './dist/sw.js',
  globDirectory: './dist',
  globPatterns: [
    '**/*.js',
    '**/*.css',
    '**/*.svg'
  ]
});

Der Service Worker kann dann in der Befehlszeile mit Node erstellt werden:

node build-sw.js

Da für injectManifest ein Quell-Service-Worker erforderlich ist, ist für ein minimal brauchbares Beispiel eine Quell-Service-Worker-Datei erforderlich. Wenn nur Precaching erforderlich ist, könnte der Eingabe-Service-Worker etwa so aussehen:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(self.__WB_MANIFEST);

Notieren Sie sich den String self.__WB_MANIFEST. Dies ist ein Platzhalter, den Workbox durch das Precache-Manifest ersetzt. Im Folgenden finden Sie eine gültige Konfiguration für diesen Anwendungsfall:

// build-sw.js
import {injectManifest} from 'workbox-build';

injectManifest({
  swSrc: './src/sw.js',
  swDest: './dist/sw.js',
  globDirectory: './dist',
  globPatterns: [
    '**/*.js',
    '**/*.css',
    '**/*.svg'
  ]
});

injectManifest ist zu bevorzugen, wenn Sie komplexe Anforderungen haben, z. B. erweitertes Routing, benutzerdefinierte Caching-Strategien oder andere Aspekte, die von den Optionen von generateSW nicht abgedeckt werden.

Achtung:In den obigen Beispielen wird davon ausgegangen, dass Sie sich in einer Knotenumgebung befinden, die ES-Module ohne Build-Schritt nativ unterstützt. In Knotenversionen vor Version 16 müssen Sie möglicherweise ein Flag festlegen, um die Unterstützung des ES-Moduls zu aktivieren, oder sich auf die CommonJS-Semantik mit module.exports verlassen.

Fazit

Das Precaching in Workbox ist wesentlich einfacher, als wenn Sie es selbst verwalten müssten, insbesondere wenn es sich um versionierte Assets, die von Bundlern kompiliert wurden, handelt. Precaching ist jedoch nicht die einzige Aufgabe, die Sie in einem Service Worker tun werden. Im weiteren Verlauf lernen Sie andere Techniken kennen, z. B. das Laufzeit-Caching.