Ein Feature von Service Workern ist die Möglichkeit, Dateien im Cache zu speichern, wenn der Service Worker installiert wird. Dies wird als „Precaching“ bezeichnet. Durch Precaching ist es möglich, im Cache gespeicherte Dateien für den Browser bereitzustellen, ohne das Netzwerk zu verwenden. Verwenden Sie Precaching für wichtige Assets, die Ihre Website auch offline benötigt: Hauptseite, Stile, Fallback-Bild und wichtige Skripts.
Warum sollten Sie Workbox verwenden?
Die Verwendung der Workbox für das Precaching ist optional. Sie können eigenen Code schreiben, um wichtige Assets vorab im Cache zu speichern, wenn der Service Worker installiert wird. Der Hauptvorteil von Workbox ist die vorkonfigurierte Versionsverwaltung. Beim Aktualisieren vorab im Cache gespeicherter Assets mit Workbox ist die Aktualisierung wesentlich geringer, als wenn Sie die Versionsverwaltung und Aktualisierung dieser Dateien selbst durchführen müssten.
Manifeste vorab im Cache speichern
Das Pre-Caching wird durch eine Liste von URLs und zugehörigen Versionsinformationen für jede URL gesteuert. Zusammengenommen bilden diese Informationen ein Precache-Manifest. Das Manifest ist die "Source of Truth" für den Status aller Inhalte, die sich im Precache für eine bestimmte Version einer Webanwendung befinden sollen. Ein Precache-Manifest in dem 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 für jede der drei aufgeführten URLs im Cachespeicher drei Cache-Einträge erstellt. Beim ersten Asset sind die Versionsinformationen bereits in der URL enthalten (app ist der tatsächliche Dateiname und .abcd1234 enthält die Versionsinformationen direkt vor der Dateiendung .js). Die Build-Tools von Workbox können dies erkennen und ein Überarbeitungsfeld ausschließen. Die anderen beiden Assets enthalten keine Versionsinformationen in ihren URLs. Daher erstellen die Build-Tools von Workbox ein separates revision-Feld, das einen Hash des Inhalts der lokalen Datei enthält.
Vorab im Cache gespeicherte Ressourcen bereitstellen
Das Hinzufügen von Assets zum Cache ist nur ein Teil der Precaching Story. Sobald die Assets im Cache gespeichert sind, müssen sie auf ausgehende Anfragen antworten. Dazu ist ein fetch-Event-Listener in Ihrem Service Worker erforderlich, der prüfen kann, welche URLs vorab im Cache gespeichert wurden, diese im Cache gespeicherten Antworten zuverlässig zurückgeben und dabei das Netzwerk umgehen. Da der Service Worker den Cache auf Antworten prüft (und diese vor dem Netzwerk verwendet), wird dies als Cache-First-Strategie bezeichnet.
Effiziente Updates
Ein Precache-Manifest liefert eine genaue Darstellung des erwarteten Cache-Status. Wenn sich eine Kombination aus URL und Überarbeitung im Manifest ändert, weiß ein Service Worker, dass der vorherige im Cache gespeicherte Eintrag nicht mehr gültig ist und muss aktualisiert werden. Es wird nur eine einzige Netzwerkanfrage verwendet, die vom Browser im Rahmen der Updateprüfung des Service Workers automatisch gestellt wird, um festzustellen, welche vorab im Cache gespeicherten URLs aktualisiert werden müssen.
Updates für vorab im Cache gespeicherte Ressourcen
Wenn Sie im Laufe der Zeit neue Versionen Ihrer Webanwendung veröffentlichen, müssen Sie zuvor vorab im Cache gespeicherte URLs auf dem neuesten Stand halten, neue Assets vorab im Cache speichern und veraltete Einträge löschen. Solange Sie bei jeder Neuerstellung Ihrer Website weiterhin ein vollständiges Precache-Manifest generieren, dient dieses Manifest jederzeit als „Source of Truth“ für Ihren Precache-Status.
Wenn bereits eine URL mit einem neuen Überarbeitungsfeld vorhanden ist oder wenn im Manifest URLs hinzugefügt oder gelöscht wurden, weist das für Ihren Service Worker darauf hin, dass Aktualisierungen als Teil der Event-Handler install und activate durchgeführt werden müssen. Wenn Sie beispielsweise einige Änderungen an Ihrer Website vorgenommen und sie neu erstellt haben, wurden in Ihrem letzten Precache-Manifest möglicherweise die folgenden Änderungen vorgenommen:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Mit jeder dieser Änderungen wird Ihrem Service Worker mitgeteilt, dass neue Anfragen gestellt 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 Löschungen zum Bereinigen von URLs, die nicht mehr verwendet werden ('app.abcd1234.js').
Echte App-Store-Installation
Ein weiterer Vorteil von Precaching besteht darin, dass Sie Ihren Nutzern eine Erfahrung bieten können, die außerhalb eines App-Shops nur schwer zu erreichen wäre. Wenn ein Nutzer zum ersten Mal eine Seite in Ihrer Webanwendung besucht, können Sie im Voraus alle URLs vorab im Cache speichern, die erforderlich sind, um beliebige Aufrufe Ihrer Webanwendung anzuzeigen, ohne warten zu müssen, bis der Nutzer die einzelnen Datenansichten aufgerufen hat.
Wenn ein Nutzer eine App installiert, erwartet er, dass alle Teile schnell angezeigt werden, nicht nur die Aufrufe, die er in der Vergangenheit erzielt hat. Precaching bietet dasselbe Erlebnis auch für Web-Apps.
Welche Assets sollten vorab im Cache gespeichert werden?
In der Anleitung Herausfinden, was geladen wird, können Sie sich noch einmal einen Eindruck davon verschaffen, welche URLs am besten vorab im Cache gespeichert werden sollten. Grundsätzlich gilt, HTML, JavaScript oder CSS, die frühzeitig geladen wird und für die Darstellung der Grundstruktur einer bestimmten Seite entscheidend ist, muss vorab im Cache gespeichert werden.
Medien oder andere Assets, die später geladen werden, sollten nicht vorab im Cache gespeichert werden, es sei denn, dies ist für die Funktionalität Ihrer Webanwendung unbedingt erforderlich. Verwenden Sie stattdessen eine Laufzeit-Caching-Strategie, damit diese Assets während der Ausführung im Cache gespeichert werden.
Denken Sie immer daran, dass beim Precaching die Netzwerkbandbreite und der Speicher auf dem Gerät eines Nutzers genutzt werden (so wie es beim Installieren einer App aus einem App-Shop der Fall ist). Als Entwickler müssen Sie mit Bedacht vorab zwischenspeichern und ein aufgeblähtes Precache-Manifest vermeiden.
Die Build-Tools von Workbox geben Ihnen die Anzahl der Elemente im Precache-Manifest sowie die Gesamtgröße der Precache-Nutzlast an.
Wiederkehrende Besucher Ihrer Webanwendung profitieren langfristig von den Vorabkosten für das Precaching, da die Möglichkeit, das Netzwerk zu vermeiden, sich im Laufe der Zeit für die eingesparte Bandbreite bezahlt.