Der Service Worker-Lebenszyklus sorgt zwar für einen vorhersehbaren Installations- und Aktualisierungsprozess, kann den lokalen Entwicklungszyklus jedoch etwas differenzierter gestalten.
In einem typischen lokalen Entwicklungszyklus speichern Entwickler Änderungen an Dateien in einem Texteditor und wechseln dann zum Browser, um die Änderungen zu überprüfen. Der Prozess wird wiederholt. Wenn ein Service Worker vorhanden ist, ist dieser Zyklus weitgehend gleich, aber es kann Unterschiede zwischen den Erwartungen des Entwicklers und dem Verhalten des Browsers geben.
Ausnahmen für die lokale Entwicklung
Service Worker APIs sind im Allgemeinen nur auf Seiten verfügbar, die über HTTPS bereitgestellt werden. Es gibt jedoch Ausnahmen von dieser Regel, bei denen sie möglicherweise über HTTP verfügbar sind.
Eine Ausnahme bilden Seiten, die über localhost ausgeliefert werden. Diese Methode eignet sich gut für die lokale Entwicklung.
Es ist jedoch nicht ungewöhnlich, dass Entwickler in einer Hostdatei außer localhost lokale Hostnamen angeben.
Dies ist in lokalen Entwicklungsumgebungen erforderlich, wenn mehrere Projekte separate Hostnamen erfordern.
In diesen Fällen reicht es aus, ein selbst signiertes Zertifikat bereitzustellen.
Eine bequemere Problemumgehung besteht darin, den Browser anzuweisen, Ausnahmen für Service Worker-Tests einzurichten.
Rufen Sie für Chrome chrome://flags/#unsafely-treat-insecure-origin-as-secure auf und geben Sie unsichere Ursprünge an, die als sichere Ursprünge behandelt werden sollen.
Firefox bietet eine Möglichkeit, Service Worker an unsicheren Ursprüngen über die Einstellung devtools.serviceWorkers.testing.enabled in about:config zu testen.
Service Worker-Entwicklungshilfen
Die lokale Entwicklung mit einem Service Worker kann zu scheinbar unerwartetem Verhalten führen.
Nehmen wir beispielsweise an, dass für nicht versionierte statische Inhalte eine Nur-Cache-Strategie oder eine vorab im Cache gespeicherte „Du bist offline“-Seite verwendet wird, die beim Aktualisieren nach Änderungen aktualisiert werden soll.
Da eine veraltete Version dieser Assets immer von einer Cache-Instanz bereitgestellt wird, werden sie scheinbar nie aktualisiert.
Das frustrierend ist, dass der Service Worker nur das tut, wofür er erstellt wurde. Es gibt jedoch einige Möglichkeiten, das Testen zu vereinfachen.
Die bei Weitem effektivste Methode zum Testen eines Service Workers besteht darin, Fenster zum privaten Surfen zu verwenden, zum Beispiel Inkognitofenster in Chrome oder die Funktion zum privaten Surfen in Firefox.
Jedes Mal, wenn Sie ein Fenster im Modus zum privaten Surfen öffnen, beginnen Sie von vorn.
Es gibt keine aktiven Service Worker und keine offenen Cache-Instanzen. Die Routine für diese Art von Tests sieht so aus:
- Öffnen Sie ein Fenster zum privaten Surfen.
- Rufen Sie eine Seite auf, auf der ein Service Worker registriert wird.
- Prüfen Sie, ob sich der Service Worker wie erwartet verhält.
- Schließen Sie das Inkognitofenster.
- Wiederholen.
Mit diesem Prozess ahmen Sie den Lebenszyklus des Service Workers treu nach.
Andere Testtools, die im Chrome-Entwicklertools-Anwendungsbereich verfügbar sind, können Abhilfe schaffen. Der Service Worker-Lebenszyklus kann jedoch auf unterschiedliche Weise geändert werden.
Das Anwendungsfenster enthält ein untergeordnetes Feld mit der Bezeichnung Service Workers, in dem die aktiven Service Worker für die aktuelle Seite angezeigt werden. Jeder aktive Service Worker kann manuell aktualisiert oder sogar komplett abgemeldet werden. Es gibt auch drei Ein-/Aus-Schaltflächen oben, die die Entwicklung erleichtern.
- Offline simuliert Offline-Bedingungen. Dies ist hilfreich, wenn Sie testen, ob ein aktiver Service Worker Offlineinhalte bereitstellt.
- Beim Aktualisieren aktualisieren: Wenn diese Option aktiviert ist, wird der aktuelle Service Worker jedes Mal abgerufen und ersetzt, wenn die Seite neu geladen wird.
- Wenn die Option Für Netzwerk umgehen aktiviert ist, wird jeglicher Code im Ereignis
fetcheines Service Workers umgangen und Inhalte immer aus dem Netzwerk abgerufen.
Diese Ein-/Aus-Schaltflächen sind hilfreich, insbesondere wenn Sie ein Projekt mit einem aktiven Service Worker entwickeln, aber auch dafür sorgen möchten, dass der Vorgang auch ohne Service Worker wie erwartet funktioniert.
In den Entwicklertools von Firefox gibt es ein ähnliches Anwendungsfenster. Die Funktionalität beschränkt sich jedoch darauf, zu sehen, welche Service Worker installiert sind, und können aktive Service Worker manuell für die aktuelle Seite abmelden. Es ist genauso hilfreich, erfordert jedoch im lokalen Entwicklungszyklus mehr manuellen Aufwand.
Umschalten und neu laden
Wenn Sie lokal mit einem aktiven Service Worker entwickeln und die Funktionen Bei Aktualisierung aktualisieren oder Für Netzwerk umgehen nicht erforderlich sind, ist es auch sinnvoll, die Umschalttaste gedrückt zu halten und auf die Schaltfläche „Aktualisieren“ zu drücken.
Dies wird als erzwungene Aktualisierung bezeichnet, bei der der HTTP-Cache für das Netzwerk umgangen wird. Wenn ein Service Worker aktiv ist, wird er bei einer erzwungenen Aktualisierung ebenfalls vollständig umgangen.
Diese Funktion ist besonders nützlich, wenn unsicher ist, ob eine bestimmte Caching-Strategie wie beabsichtigt funktioniert, und es nützlich ist, alles aus dem Netzwerk abzurufen, um das Verhalten mit und ohne Service Worker zu vergleichen. Besser noch, es ist ein festgelegtes Verhalten, sodass alle Browser, die Service Worker unterstützen, es beobachten.
Cache-Inhalte überprüfen
Wenn der Cache nicht überprüft werden kann, lässt sich schwer feststellen, ob eine Caching-Strategie wie beabsichtigt funktioniert.
Der Cache könnte zwar im Code überprüft werden, aber das ist ein Prozess mit Debuggern und/oder console-Anweisungen, bei dem ein visuelles Tool besser für diese Aufgabe geeignet wäre.
Im Bereich „Anwendung“ der Chrome-Entwicklertools gibt es ein untergeordnetes Steuerfeld, in dem der Inhalt von Cache-Instanzen geprüft wird.
Dieses untergeordnete Steuerfeld erleichtert die Entwicklung von Service Workern mit Funktionen wie den folgenden:
- Sehen Sie sich die Namen von
CacheInstanzen an. - Die Möglichkeit, den Antworttext von im Cache gespeicherten Assets und die zugehörigen Antwortheader zu prüfen.
- Entfernen Sie ein oder mehrere Elemente aus dem Cache oder löschen Sie ganze
Cache-Instanzen.
Diese grafische Benutzeroberfläche erleichtert die Prüfung von Service Worker-Caches, um festzustellen, ob Elemente einem Service Worker-Cache hinzugefügt, aktualisiert oder vollständig entfernt wurden. Firefox bietet einen eigenen Cache-Viewer mit ähnlichen Funktionen, der sich jedoch in einem separaten Speicherbereich befindet.
Speicherkontingent simulieren
Bei Websites mit vielen großen statischen Assets (z. B. Bilder mit hoher Auflösung) kann es vorkommen, dass Speicherkontingente erreicht werden. In diesem Fall entfernt der Browser Elemente aus dem Cache, die er als veraltet oder anderweitig wertlos erachtet, um Platz für neue Assets zu schaffen.
Der Umgang mit Speicherkontingenten sollte Teil der Service Worker-Entwicklung sein. Mit Workbox ist dieser Prozess einfacher, als ihn selbst zu verwalten. Mit oder ohne Workbox kann es jedoch sinnvoll sein, ein benutzerdefiniertes Speicherkontingent zu simulieren, um die Cache-Verwaltungslogik zu testen.
Der Anwendungsbereich der Chrome-Entwicklertools enthält das untergeordnete Steuerfeld Speicher, das Informationen dazu enthält, wie viel des aktuellen Speicherkontingents von der Seite verwendet wird. Außerdem kann ein benutzerdefiniertes Kontingent in Megabyte angegeben werden. In diesem Fall wird das benutzerdefinierte Speicherkontingent in Chrome erzwungen, damit es getestet werden kann.
Übrigens enthält dieses untergeordnete Steuerfeld auch die Schaltfläche Websitedaten löschen sowie eine Reihe zugehöriger Kontrollkästchen für die Elemente, die gelöscht werden sollen, wenn auf die Schaltfläche geklickt wird.
Dazu gehören alle geöffneten Cache-Instanzen und die Möglichkeit, die Registrierung aller aktiven Service Worker aufzuheben, die die Seite steuern.
Einfachere Entwicklung, höhere Produktivität
Wenn Entwickelnde unbelastet sind, können sie selbstbewusster und produktiver arbeiten. Die lokale Entwicklung mit einem Service Worker kann sehr differenziert sein, muss aber nicht umständlich sein. Mit diesen Tipps und Tricks sollte die Entwicklung mit einem aktiven Service Worker viel transparenter und vorhersehbarer sein, was zu einer besseren Entwicklung führt.