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 das Vorab-Caching können gecachte Dateien an den Browser gesendet werden, ohne dass das Netzwerk genutzt werden muss. Verwenden Sie das Pre-Caching 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 integrierte Versionskontrolle. 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 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 von allem, was sich im Precache für eine bestimmte Version einer Webanwendung befinden soll. 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 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-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 ü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 URL/Revision-Kombination im Manifest ändert, weiß ein Service Worker, dass der vorherige im Cache gespeicherte Eintrag nicht mehr gültig ist und aktualisiert werden muss. 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 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'
}]
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').
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 in 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. Precaching bietet dasselbe Erlebnis auch für Web-Apps.
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, Medien oder andere Assets, die später geladen werden, nicht vorab zu cachen, 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.