Precaching mit Workbox

Eine Funktion von Dienst-Workern ist die Möglichkeit, Dateien beim Installieren des Dienst-Workers im Cache zu speichern. Dies wird als „Precaching“ bezeichnet. Mit dem Precaching können im Cache gespeicherte Dateien an den Browser gesendet werden, ohne dass das Netzwerk genutzt werden muss. Verwenden Sie das Precaching für wichtige Assets, die Ihre Website auch offline benötigt: Startseite, Stile, Fallback-Bild und wichtige Scripts.

Die Verwendung von Workbox für das Precaching ist optional. Sie können eigenen Code schreiben, um wichtige Assets beim Installieren des Dienstarbeiters im Voraus zu cachen. Der Hauptvorteil von Workbox ist die integrierte Versionskontrolle. Das Aktualisieren von vorab im Cache gespeicherten Assets mit Workbox ist viel einfacher, als wenn Sie die Versionierung und Aktualisierung dieser Dateien selbst verwalten müssten.

Manifeste vorab im Cache speichern

Das Vorab-Caching wird durch eine Liste von URLs und zugehörige Versionsinformationen für jede URL gesteuert. Zusammengenommen werden diese Informationen als Pre-Cache-Manifest bezeichnet. Das Manifest ist die „Source of Truth“ für den Status aller Elemente, die im Precache für eine bestimmte Version einer Webanwendung enthalten sein sollen. Ein Precache-Manifest im von Workbox verwendeten Format sieht in etwa so aus:

[{
  url: 'app.abcd1234.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

Wenn der Service Worker installiert wird, werden im Cache-Speicher für jede der drei aufgeführten URLs drei Cache-Einträge erstellt. Das erste Asset enthält bereits Versionsinformationen in der URL (app ist der eigentliche Dateiname und .abcd1234 enthält die Versionsinformationen direkt vor der Dateiendung .js). Die Build-Tools von Workbox können dies erkennen und ein Revisionsfeld ausschließen. Die anderen beiden Assets enthalten keine Versionsinformationen in ihren URLs. Daher erstellen die Build-Tools von Workbox ein separates revision-Feld mit einem Hash des Inhalts der lokalen Datei.

Bereits im Cache vorhandene Ressourcen bereitstellen

Assets dem Cache hinzuzufügen, ist nur ein Teil des Precachings. Sobald die Assets im Cache sind, müssen sie auf ausgehende Anfragen reagieren. Dazu ist ein fetch-Ereignislistener in Ihrem Service Worker erforderlich, der prüfen kann, welche URLs vorab im Cache gespeichert wurden, und diese im Cache gespeicherten Antworten zuverlässig zurückgeben kann, wobei das Netzwerk dabei umgangen wird. Da der Service Worker den Cache auf Antworten überprüft und diese vor dem Netzwerk verwendet, wird dies als Cache-first-Strategie bezeichnet.

Effiziente Updates

Ein Pre-Cache-Manifest bietet eine genaue Darstellung des erwarteten Cache-Status. Wenn sich eine Kombination aus URL und Version im Manifest ändert, weiß ein Service Worker, dass der vorherige im Cache gespeicherte Eintrag nicht mehr gültig ist und aktualisiert werden muss. Es ist nur eine einzige Netzwerkanfrage erforderlich, die vom Browser automatisch im Rahmen der Aktualisierungsüberprüfung des Service Workers gesendet wird, um zu ermitteln, welche vorab im Cache gespeicherten URLs aktualisiert werden müssen.

Aktualisierungen bei vorab im Cache gespeicherten Ressourcen

Wenn Sie im Laufe der Zeit neue Versionen Ihrer Webanwendung veröffentlichen, müssen Sie zuvor im Cache gespeicherte URLs auf dem neuesten Stand halten, neue Assets im Cache speichern und veraltete Einträge löschen. Solange Sie jedes Mal, wenn Sie Ihre Website neu erstellen, ein vollständiges Pre-Cache-Manifest generieren, dient dieses Manifest jederzeit als „Source of Truth“ für Ihren Pre-Cache-Status.

Wenn eine vorhandene URL ein neues Revisionsfeld hat oder URLs zum Manifest hinzugefügt oder daraus entfernt wurden, ist das ein Signal für Ihren Service Worker, dass Aktualisierungen im Rahmen der Ereignishandler install und activate ausgeführt werden müssen. Wenn Sie beispielsweise Änderungen an Ihrer Website vorgenommen und sie neu erstellt haben, hat das aktuelle Pre-Cache-Manifest möglicherweise die folgenden Änderungen erfahren:

[{
  url: 'app.ffaa4455.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

Jede dieser Änderungen teilt Ihrem Service Worker mit, dass neue Anfragen gesendet werden müssen, um zuvor im Cache gespeicherte Einträge ('offline.svg' und 'index.html') zu aktualisieren und neue URLs im Cache zu speichern ('app.ffaa4455.js'), sowie URLs zu löschen, die nicht mehr verwendet werden ('app.abcd1234.js').

Installation wie im App-Shop

Ein weiterer Vorteil des Precachings besteht darin, dass Sie Ihren Nutzern eine Funktion bieten können, die außerhalb einer App-Shop-Installation sonst nur schwer zu erreichen wäre. Sobald ein Nutzer eine Seite Ihrer Webanwendung zum ersten Mal besucht, können Sie alle URLs im Voraus im Cache speichern, die zum Anzeigen jeder Ansicht Ihrer Webanwendung erforderlich sind, ohne warten zu müssen, bis der Nutzer jede einzelne Ansicht besucht.

Wenn ein Nutzer eine App installiert, erwartet er, dass alle Teile schnell angezeigt werden, nicht nur die Ansichten, die er in der Vergangenheit besucht hat. Mit dem Precaching können Sie das gleiche Erlebnis auch für Web-Apps nutzen.

Welche Ihrer Assets sollten vorab im Cache gespeichert werden?

Im Leitfaden Herausfinden, was geladen wird finden Sie Informationen dazu, welche URLs am besten vorab im Cache gespeichert werden sollten. Als Faustregel gilt: Pre-Cachen Sie alle HTML-, JavaScript- oder CSS-Dateien, die früh geladen werden und für die Darstellung der grundlegenden Struktur einer bestimmten Seite entscheidend sind.

Es ist besser, keine Medien oder anderen Assets vorab zu cachen, die später geladen werden, es sei denn, sie sind für die Funktionalität Ihrer Webanwendung entscheidend. Verwenden Sie stattdessen eine Laufzeit-Caching-Strategie, damit diese Assets „on-the-fly“ im Cache gespeichert werden.

Denken Sie immer daran, dass beim Precaching die Netzwerkbandbreite und der Speicherplatz auf dem Gerät eines Nutzers genutzt werden, genau wie bei der Installation einer App aus einem App-Shop. Als Entwickler liegt es in Ihrer Verantwortung, das Precaching mit Bedacht zu nutzen und ein überladenes Precache-Manifest zu vermeiden.

Die Build-Tools von Workbox geben Aufschluss über die Anzahl der Elemente im Pre-Cache-Manifest sowie die Gesamtgröße der Pre-Cache-Nutzlast.

Wiederkehrende Besucher Ihrer Webanwendung profitieren langfristig von den Vorabkosten des Precachings, da sich die Möglichkeit, das Netzwerk zu umgehen, durch die eingesparte Bandbreite im Laufe der Zeit schnell amortisiert.