Service Worker sind ein leistungsstarkes Tool, mit dem Websites offline funktionieren und spezielle Caching-Regeln für sich selbst erstellt werden können. Ein Service-Worker-fetch-Handler sieht jede Anfrage von einer von ihm verwalteten Seite und kann entscheiden, ob er eine Antwort aus dem Service Worker-Cache bereitstellen oder die URL sogar umschreiben möchte, um eine andere Antwort vollständig abzurufen – etwa basierend auf lokalen Nutzereinstellungen.
Allerdings können Leistungskosten für Service Worker anfallen, wenn eine Seite zum ersten Mal seit einiger Zeit geladen wird und der steuernde Service Worker derzeit nicht ausgeführt wird. Da alle Abrufe über den Service Worker erfolgen müssen, muss der Browser warten, bis der Service Worker gestartet und ausgeführt wurde, bevor er weiß, welche Inhalte geladen werden sollen. Für Entwickler, die Service Worker nutzen, um die Leistung durch Caching-Strategien zu verbessern, können die Startkosten gering, aber hoch sein.
Das Vorabladen der Navigation ist ein Ansatz zur Lösung dieses Problems. Dabei können parallel zum Service Worker-Start über das Netzwerk Navigationsanfragen gesendet werden. Sie ist jedoch auf die anfänglichen Navigationsanfragen beschränkt und schließt den Service Worker weiterhin in den kritischen Pfad ein. Seit der Einführung des Vorabladens der Navigation wurden mehrere Anstrengungen unternommen, um eine allgemeinere Lösung für den Problembereich zu entwickeln, einschließlich der Möglichkeiten, wie einige Anfragen beim Start des Service Workers nicht blockiert werden.
Die Service Worker Static Routing API
Ab Chrome 116 ist die experimentelle Service Worker Static Routing API zum Testen des ersten Schritts einer solchen Lösung verfügbar. Wenn ein Service Worker installiert ist, kann er mithilfe der Service Worker Static Routing API deklarativ angeben, wie bestimmte Ressourcenpfade abgerufen werden sollen.
In der ersten Version der API können Pfade so deklariert werden, dass sie immer vom Netzwerk und nicht vom Service Worker bereitgestellt werden. Wenn eine kontrollierte URL später geladen wird, kann der Browser mit dem Abrufen von Ressourcen aus diesen Pfaden beginnen, bevor der Service Worker den Start beendet hat. Dadurch wird der Service Worker aus den Pfaden entfernt, von denen Sie wissen, dass sie keinen Service Worker benötigen.
Zur Verwendung der API ruft der Service Worker mit einer Reihe von Regeln event.registerRouter für das Ereignis install auf:
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
Jede Regel hat in der Regel zwei Eigenschaften:
condition: gibt an, wann die Regel mit der URL Pattern API zum Abgleich von Ressourcenpfaden angewendet wird. Das Attribut kann eineURLPattern-Instanz oder das äquivalente einfache Objekt annehmen, das mit der Übergabe an denURLPattern-Konstruktor kompatibel ist (z. B. entwedernew URLPattern({pathname: '*.jpg'})oder nur{pathname: '*.jpg'}).Die Flexibilität von URL-Mustern bedeutet, dass die Regel etwas so Einfaches wie jede Ressource in einem Pfad bis zu sehr spezifischen und detaillierten Bedingungen zuordnen kann. Die Muster sollten Nutzern beliebter Routingbibliotheken im Allgemeinen vertraut sein.
source: gibt an, wie die Ressourcen geladen werden, die mitconditionübereinstimmen. Derzeit wird nur der Wert'network'unterstützt, d. h. der Service Worker wird umgangen, um die Ressource direkt über das Netzwerk zu laden. Es ist geplant, diesen Wert in Zukunft auf andere Werte auszuweiten.
Anwendungsfälle
Wie erläutert, ist die ursprüngliche Version der API im Wesentlichen eine Ausweichmöglichkeit für die Service Worker-Steuerung für einige Pfade. Wo dies sinnvoll ist, hängt davon ab, wie Sie Ihren Service Worker verwenden und wie Nutzer Ihre Website durchlaufen.
Ein Beispiel hierfür wäre, wenn auf deiner Website eine Cache-First-Strategie verwendet wird, d. h., es gibt Inhalte, die so selten besucht werden, dass sie nie den Cache erreichen (z. B. archivierte Inhalte oder RSS-Feeds). Die Einschränkung, dass diese Pfade aus dem Netzwerk abgerufen werden können, kann nur im Service Worker festgelegt werden. Der Service Worker muss jedoch trotzdem gestartet und ausgeführt werden, um zu entscheiden, wie diese Anfragen verarbeitet werden sollen.
Bei der Static Routing API wird der Service Worker dagegen mit einigen deklarativen Zeilen vollständig umgangen:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
Im Zuge der Weiterentwicklung der Service Worker Static Routing API soll diese Konfiguration flexibler werden und mehr Szenarien unterstützen, z. B. einen deklarativen Start eines Netzwerkabrufs und eines Service Workers. Weitere Informationen finden Sie in der Erläuterung der Spezifikationen der API.
Service Worker Static Routing API testen
Die Service Worker Static Routing API ist in Chrome ab Version 116 nach einem Ursprungstest verfügbar. Damit können Entwickler die API auf ihrer Website mit echten Nutzern testen, um die Auswirkungen zu messen. Hintergrundinformationen zu Ursprungstests finden Sie unter Erste Schritte mit Ursprungstests.
Für lokale Tests kann die Service Worker Static Routing API mit einem Flag unter chrome://flags/#service-worker-static-router oder durch Ausführen von Chrome über den Befehl wie mit --enable-features=ServiceWorkerStaticRouter aktiviert werden.
Feedback und zukünftige Schritte
Die Service Worker Static Routing API befindet sich noch in der Entwicklungsphase und ist noch in der Entwicklungsphase. Wenn es für Sie nützlich sein könnte, probieren Sie es über den Ursprungstest aus und geben Sie uns Feedback zur API, Implementierung und verfügbaren Funktionen.