Die Bereitstellung eines Service Workers kann das Verhalten einer Website auf unerwartete Weise ändern. Da es mit Workbox das Schreiben und Bereitstellen eines Service Workers vereinfacht, werden einige der Auswirkungen eines Service Workers auf eine Website nach der Bereitstellung möglicherweise leichter übersehen.
Dies bedeutet nicht, dass die Verwendung von Workbox zu schlechten Ergebnissen führt, sondern nur, dass der Komfort, den sie bietet, es einfacher macht, auf einige Fallstricke zu stolpern, wenn man sich nicht bewusst ist, was die Bereitstellung eines Service Workers mit sich bringt.
Fallstricke vorab im Cache speichern
Precaching wurde bereits in diesen Dokumenten behandelt, aber nicht vollständig erläutert, wie dies nach hinten losgehen kann. Wenn Sie das Precaching auf zu viele Assets anwenden oder wenn der Service Worker registriert wurde, bevor die Seite das Laden wichtiger Assets abschließen konnte, können Probleme auftreten.
Da das Standardverhalten von workbox-webpack-plugin darin besteht, den Service Worker anzuweisen, generierte Assets automatisch vorab im Cache zu speichern, kann dies problematisch sein, da die Hürde für die Akzeptanz gering ist.
workbox-webpack-plugin.
In diesem Beispiel werden standardmäßig 14 Assets im aktuellen Projekt mit einer Gesamtgröße von insgesamt 352 Kilobyte im Cache gespeichert.Wenn ein Service Worker während der Installation Assets vorab im Cache speichert, werden eine oder mehrere Netzwerkanfragen gleichzeitig gestartet. Dies kann die Nutzerfreundlichkeit beeinträchtigen, wenn das richtige Timing nicht rechtzeitig feststeht. Auch wenn das Timing perfekt ist, kann es am Ende doch Daten verschwenden, wenn die Menge der vorab im Cache gespeicherten Assets nicht begrenzt ist.
Auf das Timing kommt es an
Wenn ein Service Worker etwas vorab im Cache speichert, ist der Zeitpunkt der Registrierung wichtig.
Service Worker werden oft mit Inline-<script>-Elementen registriert.
Das bedeutet, dass HTML-Parser möglicherweise Service Worker-Registrierungscode finden, bevor die wichtigen Assets der Seite geladen wurden.
Das ist ein Problem. Ein Service Worker sollte idealerweise im schlimmsten Fall leistungsneutral sein und die Leistung nicht verschlechtern. Bieten Sie Nutzern einen Gefallen und registrieren Sie einen Service Worker, wenn das load-Ereignis der Seite ausgelöst wird.
Dadurch wird die Wahrscheinlichkeit verringert, dass die Precaching-Funktion das Laden der wichtigsten Assets einer Seite beeinträchtigt, was wiederum dazu führt, dass die Seite schneller interaktiv werden kann, ohne dass Netzwerkanfragen für Assets gestellt werden müssen, die möglicherweise erst später benötigt werden.
Datennutzung berücksichtigen
Unabhängig vom Zeitpunkt werden beim Precaching Netzwerkanfragen weitergeleitet. Wenn ein Manifest der Assets, die vorab im Cache gespeichert werden sollen, nicht sorgfältig ausgewählt wird, kann dies zu einer gewissen Verschwendung führen.
Verschwendete Daten sind ein möglicher Kompromiss beim Precaching, aber nicht jeder hat Zugriff auf ein schnelles Internet oder sogar unbegrenzte Datentarife. Beim Precaching sollten Sie besonders große Assets entfernen und auf Laufzeit-Caching zurückgreifen, um sie zu erfassen, anstatt kostspielige Annahmen zu treffen.
Der Service Worker-Start kann Netzwerkanfragen verzögern
Service Worker werden in einem vom restlichen Code einer Website getrennten Prozess ausgeführt. Dieser Prozess beginnt und stoppt häufig. Wenn ein Service Worker nach der Inaktivität ein Abrufereignis verarbeiten muss, muss der Browser zuerst Zeit darauf verwenden, den Service Worker zu starten. Dieser zusätzliche Aufwand vor der Verarbeitung einer Anfrage ist gering, da er den Vorteil hat, dass eine Antwort aus dem Cache statt aus dem Netzwerk bereitgestellt wird.
Wenn Strategien verwendet werden, die nicht aus dem Cache bereitgestellt werden können und an das Netzwerk übertragen werden müssen, insbesondere bei der Verarbeitung von Navigationsanfragen, führt die Startzeit immer zu einer gewissen Verzögerung. Je nach Gerätefunktionen und/oder CPU-Auslastung kann es bei Navigationsanfragen aufgrund langsamer Startvorgänge von Service Workern zu einer deutlichen Verzögerung kommen. Wenn Sie einen Service Worker ohne Bewusstsein für diese Verzögerung bereitstellen, kann das zu unbeabsichtigten Leistungseinbußen führen.
Dieses Problem wurde mit dem Tool Navigation Preload gelöst, wird aber noch nicht in allen Browsern unterstützt. Ihre Verwendung ist jedoch eine Überlegung wert. Sie wird weiter unten in dieser Dokumentation behandelt.
Cache-First-Strategien können nach hinten abfeuern
Caching-Strategien, bei denen zuerst der Cache oder nur der Cache konsultiert wird, eignen sich hervorragend sowohl für den Offlinezugriff als auch für die Leistung. In einigen Fällen können sie jedoch Probleme verursachen.
Laufzeit-Caching von nicht versionierten statischen Assets
Bundler versionieren statische Assets in der Regel mit einem inhaltsbasierten Hash im Dateinamen (z. B. styles.a4edf38c.css). Bei Service Workern, die Caching-Strategien verwenden, bei denen zuerst der Cache nach statischen Inhalten geprüft wird, und eine netzwerkorientierte Strategie für Seiten-Markup verwenden, sollte es keine Caching-Probleme geben, da im Markup auf aktualisierte Assets verwiesen wird, die immer aus dem Netzwerk abgerufen werden.
Probleme treten auf, wenn nicht versionierte statische Assets während der Laufzeit mit diesen Strategien im Cache gespeichert werden.
Wenn die Funktionalität einer Website von app.js bereitgestellt wird und eine Cache-First-Laufzeitstrategie verwendet wird und app.js später ohne Änderung des Dateinamens aktualisiert wird, wird die ursprünglich im Cache gespeicherte Version weiterhin aus dem Cache bereitgestellt und nicht aktualisiert.
Die Lösung besteht darin, eine Strategie zu verwenden, bei der das Netzwerk auf Updates geprüft wird, z. B. „Network-First“ oder „Stale-while-re“. Alternativ können Build-Tools ein Precache-Manifest für diese Assets generieren, da die Precaching-Logik von Workbox sie auf dem neuesten Stand hält.
Unabhängig davon sollten Sie unbedingt die Versionsverwaltung statischer Assets durch einen Hash im Asset-Namen oder im Abfragestring in Betracht ziehen. Dadurch werden Probleme mit veralteten Assets in Service Workern vermieden, die Cache-First-Laufzeitstrategien für statische Assets verwenden.
Mind Storage-Kontingente
Service Worker-Updates werden häufig von Zeit zu Zeit eingeführt. Wenn Updates eingeführt werden, werden alte Caches mit abgelaufenen Namen normalerweise während der Aktivierung des neuen Service Workers entfernt.
Einige Service Worker-Iterationen sind jedoch langlebig oder Cache-Namen werden bei neuen Updates möglicherweise nicht aktualisiert. In diesem Fall können sich alte statische Inhalte in den Caches ansammeln, wenn Updates dafür bereitgestellt werden. Browser legen Speicherkontingente fest, die variieren können. Das ist ein guter Grund, auf sie zu achten!
Workbox löst diese Probleme gut, aber Speicherkontingente können dennoch überschritten werden. Mit dem Modul "workbox-expiration" können Sie Caches genauer steuern.
Keine Angst
Die Bereitstellung eines Service Workers ist keine Kleinigkeit. Es sollte jedoch keine beängstigende Aufgabe sein, ein bisschen Planung und Achtsamkeit dafür zu schaffen, was die Bereitstellung eines Service Workers mit Workbox mit sich bringt. Mithilfe dieser Dokumentation können Sie diese Bedenken mit Sorgfalt und Zuversicht bewältigen.