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 Precaching können im Browser im Cache gespeicherte Dateien bereitgestellt werden, ohne zum Netzwerk zu wechseln. Verwenden Sie das Precaching für wichtige Assets, die Ihre Website auch dann benötigt, wenn sie offline ist: Hauptseite, Stile, Fallback-Bilder und wichtige Skripts.
Warum sollte ich Workbox verwenden?
Die Verwendung von Workbox für das Precaching ist optional. Sie können Ihren eigenen Code schreiben, um wichtige Assets während der Installation durch den Service Worker vorab im Cache zu speichern. Der Hauptvorteil von Workbox ist die sofort einsatzbereite Versionsverwaltung. Beim Aktualisieren von vorab im Cache gespeicherten Assets mit Workbox fallen wesentlich weniger Probleme an, als wenn Sie die Versionsverwaltung und Aktualisierung dieser Dateien selbst verwalten müssten.
Manifeste vorab im Cache speichern
Das Precaching basiert auf einer Liste von URLs und den zugehörigen Versionsinformationen für jede URL. Zusammengenommen wird diese Information als Precache-Manifest bezeichnet. Das Manifest ist die „Source of Truth“ für den Status aller Elemente, die sich für eine bestimmte Version einer Webanwendung im Precache 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 im Cache-Speicher drei Cache-Einträge für jede der drei aufgeführten URLs erstellt. Die Versionsinformationen des ersten Assets sind 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, und diese im Cache gespeicherten Antworten zuverlässig zurückgeben. Dabei wird das Netzwerk umgangen. Da der Service Worker den Cache auf Antworten prüft und die Antworten vor dem Netzwerk verwendet, wird dies als Cache-First-Strategie bezeichnet.
Effiziente Updates
Ein Precache-Manifest bietet 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 aktualisiert werden muss. Um festzustellen, welche vorab im Cache gespeicherten URLs aktualisiert werden müssen, wird nur eine einzige Netzwerkanfrage gestellt, die im Rahmen der Updateprüfung des Service Workers automatisch vom Browser gestellt wird.
Updates für vorab im Cache gespeicherte Ressourcen
Wenn Sie nach und nach neue Versionen Ihrer Web-App veröffentlichen, müssen Sie zuvor im Cache gespeicherte URLs immer auf dem neuesten Stand halten, neue Assets vorab im Cache speichern und veraltete Einträge löschen. Solange Sie bei jeder Neuerstellung Ihrer Website ein vollständiges Precache-Manifest generieren, dient dieses Manifest jederzeit als „Source of Truth“ für den Precache-Status.
Wenn eine URL mit einem neuen Überarbeitungsfeld vorhanden ist oder URLs aus dem Manifest hinzugefügt oder daraus entfernt wurden, ist das ein Zeichen für Ihren Service Worker, dass im Rahmen der Event-Handler install und activate Aktualisierungen durchgeführt werden müssen. Wenn Sie beispielsweise Änderungen an Ihrer Website vorgenommen und neu erstellt haben, wurden an Ihrem letzten Precache-Manifest möglicherweise die folgenden Änderungen vorgenommen:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Durch jede dieser Änderungen wird Ihr Service Worker darüber informiert, 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'). Außerdem müssen sie gelöscht werden, um nicht mehr verwendete URLs zu bereinigen ('app.abcd1234.js').
Echte „App-Shop“-Installation
Ein weiterer Vorteil der Precaching-Methode besteht darin, dass Sie Ihren Nutzern eine Umgebung bieten können, die außerhalb eines App-Shops nur schwer realisierbar wäre. Wenn ein Nutzer eine Seite in Ihrer Web-App zum ersten Mal besucht, können Sie potenziell alle URLs, die zum Anzeigen einer beliebigen Ansicht Ihrer Web-App erforderlich sind, vorab im Cache speichern, ohne warten zu müssen, bis die einzelnen Ansichten aufgerufen werden.
Wenn ein Nutzer eine App installiert, erwartet er, dass alle Teile schnell angezeigt werden, nicht nur die Aufrufe, die er in der Vergangenheit aufgerufen hat. Precaching bringt dieselbe Erfahrung auch für Webanwendungen.
Welche Assets sollten vorab im Cache gespeichert werden?
Sehen Sie sich die Anleitung Bestimmte Inhalte ermitteln an, um sich einen Eindruck davon zu verschaffen, welche URLs am besten vorab im Cache gespeichert werden sollten. Als Faustregel gilt: Alle HTML-, JavaScript- oder CSS-Elemente, die früh geladen werden und die für die Darstellung der Grundstruktur einer bestimmten Seite entscheidend sind, sollten vorab im Cache gespeichert werden.
Medien oder andere Assets, die später geladen werden, sollten nach Möglichkeit nicht im Cache gespeichert werden, sofern dies für die Funktionalität Ihrer Webanwendung nicht zwingend erforderlich ist. Nutzen Sie stattdessen eine Laufzeit-Caching-Strategie, damit diese Assets während der Ausführung im Cache gespeichert werden.
Beachten Sie immer, dass das Precaching die Netzwerkbandbreite und den Speicher auf dem Gerät eines Nutzers beansprucht (genau wie bei der Installation einer App aus einem App-Shop). Es liegt an Ihnen als Entwickler, mit Bedacht vorab im Cache zu speichern und ein aufgeblähtes Precache-Manifest zu vermeiden.
Die Build-Tools von Workbox geben Ihnen die Anzahl der Elemente im Precache-Manifest sowie die Gesamtgröße der Precache-Nutzlast mit.
Wiederkehrende Besucher Ihrer Webanwendung profitieren langfristig von den Anschaffungskosten für das Precaching, da sich die Möglichkeit, das Netzwerk zu umgehen, im Laufe der Zeit schnell durch die eingesparte Bandbreite amortisiert.