Eine Funktion von Service Workern ist die Möglichkeit, Dateien der Service Worker installiert. Dies wird als „Precaching“ bezeichnet. Dank Precaching können im Browser gespeicherte Dateien bereitgestellt werden, mit dem Netzwerk verbunden sind. Verwenden Sie Pre-Caching für wichtige Assets, die Ihre Website selbst wenn offline: Hauptseite, Stile, Fallback-Image und wichtige Skripts
Warum sollten Sie Workbox verwenden?
Die Verwendung der Workbox für das Precaching ist optional. Sie können Ihren eigenen Code Kritische Assets bei der Installation durch den Service Worker vorab im Cache speichern Der Hauptvorteil von Workbox ist die vorkonfigurierte Versionsverwaltung. Beim Aktualisieren vorab im Cache gespeicherter Assets mit Workbox ist die Aktualisierung wenn Sie die Versionsverwaltung und Aktualisierung dieser Dateien selbst übernehmen mussten.
Manifeste vorab im Cache speichern
Das Precaching basiert auf einer Liste von URLs und zugehörigen Versionsinformationen für für jede URL. Zusammengenommen werden diese Informationen Precache-Manifest. Das Manifest ist die „Quelle der Wahrheit“ dass alles in Ordnung sein sollte, den Pre-Cache für eine bestimmte Version einer Webanwendung. Ein Precache-Manifest im von Workbox verwendetes Format, sieht etwa so aus:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Nach der Installation des Service Workers werden drei Cache-Einträge im
Cache-Speicher für jede der drei aufgeführten URLs. Für das erste Asset gibt es eine Versionsverwaltung
Informationen, die bereits in der URL enthalten sind (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
Die anderen beiden Assets enthalten keine Versionsinformationen in ihren URLs.
Build-Tools wird ein separates revision-Feld erstellt, das einen Hash der lokalen
Dateiinhalt.
Vorab im Cache gespeicherte Ressourcen bereitstellen
Das Hinzufügen von Assets zum Cache ist nur ein Teil der Precaching Story – sobald
Assets im Cache gespeichert werden, müssen sie auf ausgehende Anfragen antworten. Dazu ist eine
fetch-Event-Listener in Ihrem Service Worker, der prüfen kann, welche URLs
Diese werden dann zuverlässig zurückgegeben, wodurch der
ein Netzwerk aufzubauen. Da der Service Worker den Cache auf Antworten prüft,
(und verwendet diese vor dem Netzwerk), wird dies als
Cache-First-Strategie.
Effiziente Updates
Ein Precache-Manifest bietet eine genaue Darstellung des erwarteten Caches. state; Wenn sich eine Kombination aus URL und Überarbeitung im Manifest ändert, kann ein Service Worker weiß, dass der vorherige im Cache gespeicherte Eintrag nicht mehr gültig ist und gelöscht werden muss. aktualisiert. Es wird nur eine einzige Netzwerkanfrage angenommen, die automatisch vom Browser als Teil des Service Workers Update-Prüfung, um zu ermitteln, 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, neue Assets vorab im Cache speichern und veraltete Einträge. Solange Sie jedes Mal ein vollständiges Precache-Manifest generieren wenn Sie Ihre Website neu erstellen, für dein zu einem beliebigen Zeitpunkt im Pre-Cache gespeichert werden.
Wenn bereits eine URL mit einem neuen Überarbeitungsfeld vorhanden ist oder URLs
hinzugefügt oder entfernt wurde, ist das ein Zeichen für Ihren Service Worker,
durchgeführt werden müssen,
install
und
activate
-Event-Handler. Wenn Sie z. B. Änderungen an Ihrer Website vorgenommen haben und
wurde Ihr neuestes Precache-Manifest möglicherweise folgendermaßen aufgebaut:
Änderungen:
[{
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
zum Aktualisieren zuvor im Cache gespeicherter Einträge ('offline.svg' und 'index.html') vorgenommen
und neue URLs ('app.ffaa4455.js') im Cache speichern, sowie Löschungen zum Bereinigen von URLs
die nicht mehr verwendet werden ('app.abcd1234.js').
Echter „App Store“ Installationsprozess
Ein weiterer Vorteil von Precaching besteht darin, dass Sie Ihren Nutzenden die außerhalb eines App-Shops nur schwer Installation. Wenn ein Nutzer zum ersten Mal eine Seite Ihrer Webanwendung besucht, können Sie alle URLs vorab im Cache speichern, die erforderlich sind, um eine Ihrer der Web-App im Voraus ansehen, ohne auf den Aufruf der einzelnen die individuelle Ansicht.
Wenn Nutzer eine App installieren, erwarten sie, dass jeder Teil schnell angezeigt wird. und nicht nur auf die bisherigen Aufrufe. Precaching bedeutet dasselbe für Web-Apps.
Welche Assets sollten vorab im Cache gespeichert werden?
Im Abschnitt Das Problem identifizieren erhalten, um eine gute welche URLs am besten im Cache gespeichert werden sollten. Als allgemeine Regel gilt: HTML, JavaScript oder CSS, die frühzeitig geladen werden und für die Nutzung wichtig sind, die die Grundstruktur einer Seite darstellt.
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 Web-App unbedingt erforderlich.) Verwenden Sie stattdessen eine Laufzeit Caching-Strategie, um sicherzustellen, Assets werden währenddessen im Cache gespeichert.
Denken Sie immer daran, dass beim Precaching die Netzwerkbandbreite und der Speicher genutzt werden. auf dem Gerät eines Nutzers (genau wie das Installieren einer App aus einem App-Shop). Als Entwickler müssen Sie mit Bedacht vorab im Cache speichern, um eine aufgeblähte precache-Manifest.
Die Build-Tools von Workbox teilen Ihnen die Anzahl der Elemente im Precache mit sowie die Gesamtgröße der Precache-Nutzlast.
Wiederkehrende Besucher Ihrer Webanwendung profitieren langfristig von den Anschaffungskosten Precaching, da die Möglichkeit, das Netzwerk zu umgehen, im Laufe der Zeit an eingesparter Bandbreite.