Progressive Web-Apps: Mit Workbox arbeiten

1. Willkommen

In diesem Lab konvertieren Sie eine Website mit einem vorhandenen Service Worker zur Verwendung von Workbox. Dies ist das zweite in einer Reihe von Codelabs zum Workshop zu progressiven Web-Apps. Das vorherige Codelab hieß Offline gehen. Diese Reihe umfasst sechs weitere Codelabs.

Lerninhalte

  • Vorhandenen Service Worker für die Verwendung von Workbox konvertieren
  • Offline-Fallback für eine PWA hinzufügen

Wichtige Informationen

  • Einfaches HTML und JavaScript

Voraussetzungen

2. Einrichtung

Klonen oder laden Sie zuerst den Starter-Code herunter, der für dieses Codelab benötigt wird:

Wenn Sie das Repository klonen, achten Sie darauf, dass Sie sich im pwa03--workbox-Branch befinden. Die ZIP-Datei enthält auch den Code für diesen Zweig.

Für diese Codebasis ist Node.js 14 oder höher erforderlich. Sobald Sie den Code haben, führen Sie npm ci über die Befehlszeile im Ordner des Codes aus, um alle erforderlichen Abhängigkeiten zu installieren. Führen Sie dann npm start aus, um den Entwicklungsserver für das Codelab zu starten.

Die README.md-Datei des Quellcodes enthält eine Erklärung für alle verteilten Dateien. Außerdem sind die folgenden Dateien wichtig, mit denen Sie in diesem Codelab arbeiten werden:

Schlüsseldateien

  • service-worker.js: Die Service Worker-Datei der Anwendung
  • offline.html – Offline-HTML, das verwendet wird, wenn eine Seite nicht verfügbar ist

3. Zu Workbox migrieren

Wenn wir uns den vorhandenen Service Worker ansehen, lässt sich das Vorab-Caching in zwei Schritte unterteilen:

  • Relevante Dateien während der Service Worker-Installation im Cache speichern
  • Diese Dateien noch einmal mit der Strategie „Nur Cache“ bereitstellen

Die Datei index.html und der /-Pfad sind weiterhin sinnvoll für das Vorab-Caching, da sich das HTML dieser Web-App nicht oft ändern wird. Die anderen Dateien wie CSS und JavaScript können sich jedoch ändern. Wir möchten nicht, dass jedes Mal der gesamte Service Worker-Lebenszyklus durchlaufen werden muss. Außerdem berücksichtigt der aktuelle Service Worker nur eine Teilmenge unseres CSS und JavaScript. Wir möchten, dass alles abgedeckt wird. Das Zwischenspeichern dieser Elemente mit der Strategie „Stale While Revalidate“ ist sinnvoller, da die Antwort schnell erfolgt und bei Bedarf im Hintergrund aktualisiert werden kann.

Precaching überarbeitet

Bei der Migration zu Workbox müssen wir keinen der vorhandenen Codes beibehalten. Löschen Sie also alles in service-worker.js. Im vorherigen Lab haben wir diesen Service Worker so eingerichtet, dass er kompiliert wird. Daher können wir hier ESModule-Importe verwenden, um Workbox aus den NPM-Modulen zu importieren. Beginnen wir mit dem Pre-Caching. Fügen Sie in service-worker.js den folgenden Code hinzu:

import { warmStrategyCache } from 'workbox-recipes';
import { CacheFirst } from 'workbox-strategies';
import { registerRoute } from 'workbox-routing';
import { CacheableResponsePlugin } from 'workbox-cacheable-response';
import { ExpirationPlugin } from 'workbox-expiration';

// Set up page cache
const pageCache = new CacheFirst({
  cacheName: 'page-cache',
  plugins: [
    new CacheableResponsePlugin({
      statuses: [0, 200],
    }),
    new ExpirationPlugin({
      maxAgeSeconds: 30 * 24 * 60 * 60,
    }),
  ],
});

warmStrategyCache({
  urls: ['/index.html', '/'],
  strategy: pageCache,
});

registerRoute(({ request }) => request.mode === 'navigate', pageCache);

Erklärung

Für die Einrichtung des Pre-Caching für /index.html und / stehen fünf Module zur Verfügung. Das mag viel erscheinen, aber dieser Code ist viel leistungsfähiger als der zuvor geschriebene Code.

Zuerst wird eine neue „Cache First“-Caching-Strategie eingerichtet, die anstelle einer „Cache Only“-Strategie ausgewählt wird, damit bei Bedarf andere Seiten in den Cache aufgenommen werden können. Es erhält den Namen page-cache. Workbox-Strategien können eine Reihe von Plug-ins verwenden, die sich auf den Lebenszyklus des Speicherns und Abrufens von Inhalten aus dem Cache auswirken können. Hier werden zwei Plugins verwendet: das Cacheable Response-Plugin und das Expiration-Plugin. So wird dafür gesorgt, dass nur gute Serverantworten im Cache gespeichert werden und dass jedes Element im Cache nach 30 Tagen geleert wird.

Als Nächstes wird der Cache der Strategie mit /index.html und / mithilfe des Workbox-Rezepts „Strategie-Cache aufwärmen“ aufgewärmt. Dadurch werden diese Elemente während des Installationsereignisses des Service Workers in den Cache aufgenommen.

Schließlich wird eine neue Route registriert. Jede Anfrage, die eine Seitennavigation ist, wird von dieser „Cache First“-Strategie verwaltet. Dabei wird entweder aus dem Cache oder aus dem Netzwerk abgerufen und die Antwort dann im Cache gespeichert.

Assets im Cache speichern

Nachdem das Vorab-Caching von Routen eingerichtet ist, ist es an der Zeit, das Caching für die Assets der Website neu zu implementieren. Das sind CSS und JavaScript. Fügen Sie dazu zuerst StaleWhileRevalidate in Ihren workbox-strategies-Import ein und dann den folgenden Code am Ende Ihres Service Workers:

// Set up asset cache
registerRoute(
  ({ request }) => ['style', 'script', 'worker'].includes(request.destination),
  new StaleWhileRevalidate({
    cacheName: 'asset-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  }),
);

Erklärung

Bei dieser Route wird zuerst ermittelt, ob es sich bei der Art der Anfrage um einen Stil, ein Skript oder einen Worker handelt, was CSS, JavaScript oder Web Workers entspricht. Wenn ja, wird die Strategie „Stale While Revalidate“ verwendet. Dabei wird zuerst versucht, aus dem Cache zu liefern. Wenn das nicht möglich ist, wird auf das Netzwerk zurückgegriffen. Gleichzeitig wird versucht, die Version im Cache nach Möglichkeit über das Netzwerk zu aktualisieren. Wie bei der Seitenstrategie werden bei dieser Strategie nur gute Antworten im Cache gespeichert.

4. Offline-Fallback hinzufügen

Nachdem der ursprüngliche Service Worker zu Workbox migriert wurde, muss noch eine Sache erledigt werden, um zu verhindern, dass die PWA im Offlinemodus abstürzt: ein Offline-Fallback muss hinzugefügt werden.

Offline-Fallbacks können für alles festgelegt werden, was offline möglicherweise nicht verfügbar ist: Seiten, Schriftarten, CSS, JavaScript, Bilder usw. Für alle PWAs sollte mindestens ein Seiten-Fallback festgelegt werden, damit Nutzer, die zu einer Seite navigieren, die nicht im Cache ist, im Kontext Ihrer App bleiben.

Workbox-Rezepte bieten ein Offline-Fallback-Rezept, mit dem genau das möglich ist. Fügen Sie dazu zuerst offlineFallback in Ihren workbox-recipes-Import ein und dann den folgenden Code am Ende Ihres Service Workers:

// Set up offline fallback
offlineFallback({
  pageFallback: '/offline.html',
});

Erklärung

Mit dem Offline-Fallback-Rezept wird eine „Nur Cache“-Strategie eingerichtet, die mit den bereitgestellten Fallbacks aufgewärmt wird. Anschließend wird ein Workbox-Standard-Catch-Handler eingerichtet, der alle fehlgeschlagenen Routinganfragen abfängt (wenn sich nichts im Cache befindet und etwas im Netzwerk nicht erreicht werden kann), den Inhalt der relevanten Dateien aus dem Cache abruft und ihn als Inhalt zurückgibt, solange die Anfrage fehlschlägt.

5. Glückwunsch!

Sie haben gelernt, wie Sie mit Workbox Caching-Strategien für Routen einrichten und Offline-Fallbacks für Ihre PWA bereitstellen.

Das nächste Codelab in der Reihe ist IndexedDB.