In dieser Dokumentation wurde das Precaching bereits behandelt, aber nicht genug darüber, wie es richtig funktioniert. Dies ist wichtig, denn unabhängig davon, ob Sie Workbox verwenden, ist es einfach, zu viel vorab im Cache zu speichern und dadurch möglicherweise Daten und Bandbreite zu verschwenden. Achten Sie darauf, wie sich die Precaching-Nutzlast auf die Nutzererfahrung auswirkt.
Beachten Sie beim Lesen dieses Dokuments, dass es sich um allgemeine Richtlinien handelt. Ihre Anwendungsarchitektur und Ihre Anforderungen können dazu führen, dass Sie andere Schritte ausführen müssen, als hier empfohlen werden, aber diese Richtlinien dienen als gute Standardeinstellungen.
Empfohlen: kritische statische Assets vorab im Cache speichern
Die besten Kandidaten für das Precaching sind kritische statische Assets. Was zählt aber als „kritisch“? Aus Entwicklerperspektive mag es verlockend sein, eine ganze Anwendung als „kritisch“ zu betrachten. Am wichtigsten ist jedoch die Perspektive der Nutzer. Betrachten Sie kritische Assets als diejenigen, die für eine positive Nutzererfahrung absolut notwendig sind:
- Globale Stylesheets
- JavaScript-Dateien mit globalen Funktionen.
- Application Shell-HTML-Code, wenn dies für Ihre Architektur gilt.
Zur Erinnerung: Dies sind allgemeine Richtlinien und keine verbindlichen Empfehlungen. Wenn Assets vorab im Cache gespeichert werden, sollten Sie eher davon ausgehen, dass sie eher nicht im Cache gespeichert werden.
Empfohlen: Offline-Fallback für mehrseitige Websites vorab im Cache speichern
Bei typischen mehrseitigen Websites verlassen Sie sich bei der Verarbeitung von Navigationsanfragen möglicherweise auf eine Netzwerk-First- oder Nur-Netzwerk-Caching-Strategie.
In solchen Fällen sollten Sie dafür sorgen, dass Ihr Service Worker vorab im Cache speichert und mit einer Offline-Fallback-Seite antwortet, wenn der Nutzer im Offlinemodus eine Navigationsanfrage stellt. Eine Möglichkeit, dies in Workbox zu tun, könnte darin bestehen, eine reine Netzwerkstrategie mit einem Offline-Fallback zu verwenden und auch das Vorabladen der Navigation zu nutzen:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
So ist sichergestellt, dass Nutzer zumindest Offline-Inhalte erhalten, wenn sie offline gehen und eine Seite aufrufen, die nicht in ihrem Cache gespeichert ist.
Vielleicht doch: spekulatives Precaching in Betracht ziehen
Das ist ein großes „vielleicht“ hier oben, aber es gibt potenziellen Vorteil durch das Precaching von Assets, die nur in bestimmten Szenarien verwendet werden. Stellen Sie sich das so vor: Es entstehen zusätzliche Vorabdaten-Downloads mit dem spekulativen Vorteil, dass zukünftige Anfragen nach diesen Assets beschleunigt werden.
Aber seien Sie sehr vorsichtig, wenn Sie sich dafür entscheiden. Es ist einfach, dabei Daten zu verschwenden, und es sollte eine datengesteuerte Entscheidung sein. Außerdem sollten Sie das spekulative Precaching von Assets vermeiden, die sich häufig ändern, da der Nutzer jedes Mal zusätzliche Datennutzung verursacht, wenn der Precaching-Code eine neue Überarbeitung erkennt. Beobachte die Nutzerflüsse in deinen Analysen, um zu sehen, welche Seite Nutzer in der Regel aufrufen. Wenn du dir nicht sicher bist, ob Assets spekulativ im Cache gespeichert werden, ist das wahrscheinlich ein gutes Zeichen dafür, dass du das nicht tun solltest.
Vielleicht nicht: Statischen HTML-Code vorab im Cache speichern
Diese Richtlinie gilt eher für statische Websites, bei denen diskrete HTML-Dateien entweder von einem Generator für statische Websites oder manuell erstellt werden, anstatt sie dynamisch oder über ein Anwendungs-Back-End bereitzustellen. Wenn dies Ihre Architektur beschreibt, ist es wahrscheinlich am besten, wenn Sie nicht jede HTML-Datei für Ihre Website vorab im Cache speichern.
Ein Problem beim Precaching der HTML-Dateien einer ganzen Website besteht darin, dass Markups, die jetzt vorab im Cache gespeichert werden, später immer aus dem Cache bereitgestellt werden, bis der Service Worker aktualisiert wird. Das ist hervorragend für die Leistung, kann aber zu einer deutlichen Abwanderung von Cache und Cache führen, wenn sich der HTML-Code Ihrer Website häufig ändert.
Es gibt jedoch einige Ausnahmen von dieser Regel. Wenn Sie eine kleine Website mit einigen statischen HTML-Dateien bereitstellen, ist es wahrscheinlich in Ordnung, alle diese Seiten vorab im Cache zu speichern, sodass sie offline verfügbar sind. Wenn Sie eine besonders große Website haben, empfiehlt es sich, einige umsatzstarke Seiten und einen Offline-Fallback spekulativ im Cache zu speichern. Außerdem können Sie Laufzeit-Caching verwenden, um andere Seiten im Cache zu speichern.
Vermeide es, responsive Bilder oder Favicons vorab im Cache zu speichern
Dies ist weniger eine allgemeine, sondern eher eine Regel. Responsive Bilder sind eine komplexe Lösung für ein komplexes Problem: Sie haben viele Nutzer auf vielen Geräten, die sich in Bildschirmgröße, Pixeldichte und Unterstützung alternativer Formate unterscheiden. Wenn Sie einen ganzen Satz responsiver Bilder vorab im Cache speichern, werden wahrscheinlich auch mehrere Bilder im Cache gespeichert, wenn der Nutzer letztendlich nur eines davon herunterlädt.
Bei Favicons ist dies ähnlich, da Websites häufig eine ganze Reihe von Favicons für verschiedene Szenarien bereitstellen. Meistens wird nur ein Favicon angefordert, wodurch das Precaching eines ganzen Favicon-Sets ähnlich verschwendet wird.
Tun Sie Ihren Nutzern einen Gefallen und verwenden Sie responsive Bild- und Favicon-Sets nicht vorab im Cache. Verwenden Sie stattdessen das Laufzeit-Caching. Wenn Sie Bilder vorab im Cache speichern müssen, sollten Sie häufig verwendete Bilder, die nicht Teil eines Satzes responsiver Bilder oder Favicons sind, vorab im Cache speichern. SVGs sind weniger riskant im Hinblick auf die Datennutzung. Ein einzelnes SVG wird unabhängig von der Pixeldichte eines bestimmten Bildschirms optimal gerendert.
Nicht: Polyfills vorab im Cache speichern
Die unterschiedliche Browserunterstützung für APIs stellt für Webentwickler eine dauerhafte Herausforderung dar. Polyfilling ist eine der Herausforderungen, um dieser Herausforderung gerecht zu werden. Eine Möglichkeit, die Leistungskosten von Polyfills zu minimieren, besteht darin, Funktionen zu überprüfen und Polyfills nur für die Browser zu laden, die sie benötigen.
Da das Laden von Polyfills unter Berücksichtigung der aktuellen Umgebung während der Laufzeit erfolgt, ist das Precaching von Polyfills ein Glücksspiel. Einige Benutzer werden davon profitieren, während andere am Ende Bandbreite für unnötige Polyfills verschwenden.
Polyfills dürfen nicht vorab im Cache gespeichert werden. Laufzeit-Caching sorgt dafür, dass sie nur in Browsern zwischengespeichert werden, in denen sie zur Vermeidung von Datenverschwendung erforderlich sind.
Fazit
Für das Precaching müssen Sie im Voraus überlegen, welche Assets Ihre Nutzer tatsächlich benötigen. Sie können es jedoch auf jeden Fall so machen, dass zukünftige Leistung und Zuverlässigkeit priorisiert werden.
Wenn Sie sich nicht sicher sind, ob bestimmte Assets vorab im Cache gespeichert werden sollen, ist es am besten, Workbox anzuweisen, diese Assets auszuschließen und eine Laufzeit-Caching-Route zu erstellen. In jedem Fall wird das Precaching weiter unten in dieser Dokumentation ausführlich behandelt, sodass Sie diese Prinzipien in Zukunft auf Ihre Precaching-Logik anwenden können.