Service Worker sind ein leistungsstarkes Tool, mit dem Websites offline funktionieren und spezielle Caching-Regeln für sich selbst erstellen können. Ein fetch-Handler für Service Worker sieht jede Anfrage von einer Seite, die er verwaltet, und kann entscheiden, ob er eine Antwort aus dem Service Worker-Cache zurückgeben oder die URL sogar umschreiben möchte, um eine ganz andere Antwort abzurufen, z. B. basierend auf den lokalen Nutzereinstellungen.
Allerdings kann es zu Leistungseinbußen bei Service Workers kommen, wenn eine Seite zum ersten Mal seit einiger Zeit geladen wird und der steuernde Service Worker gerade 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 wird, um zu wissen, welche Inhalte geladen werden sollen. Diese Startkosten können für Entwickler, die Service Worker verwenden, um die Leistung durch Caching-Strategien zu verbessern, gering, aber erheblich sein.
Das Vorladen der Navigation ist eine Möglichkeit, das Problem zu lösen. Navigationsanfragen können dann parallel zum Start des Service Workers über das Netzwerk gesendet werden. Diese Methode ist jedoch auf die ersten Navigationsanfragen beschränkt und der Service Worker ist weiterhin im kritischen Pfad enthalten. Seit der Einführung der Navigationsvorab-Ladefunktion wurden mehrere Versuche unternommen, eine allgemeinere Lösung für das Problem zu entwickeln. Dazu gehören auch Möglichkeiten, wie einige Anfragen beim Start des Service Workers überhaupt nicht blockiert werden.
Die Service Worker Static Routing API
Ab Chrome 116 ist die experimentelle Service Worker Static Routing API verfügbar, um den ersten Schritt zu einer solchen Lösung zu testen. 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 ursprünglichen Version der API können Pfade deklariert werden, die immer über das Netzwerk und nicht über den 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 Dienst-Worker vollständig gestartet wurde. Dadurch wird der Service Worker aus den Pfaden entfernt, für die er nicht benötigt wird.
Um die API zu verwenden, ruft der Dienst-Worker event.registerRouter für das Ereignis install mit einer Reihe von Regeln 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 angewendet wird. Dazu wird die URL Pattern API verwendet, um Ressourcenpfade abzugleichen. Für die Property kann eineURLPattern-Instanz oder das entsprechende einfache Objekt verwendet werden, das an denURLPattern-Konstruktor übergeben werden kann (z. B.new URLPattern({pathname: '*.jpg'})oder nur{pathname: '*.jpg'}).Die Flexibilität von URL-Mustern bedeutet, dass die Regel so einfach wie jede Ressource unter einem Pfad mit sehr spezifischen und detaillierten Bedingungen abgeglichen werden kann. Die Muster sollten Nutzern gängiger Routingbibliotheken im Allgemeinen vertraut sein.
source: Gibt an, wie die mitconditionübereinstimmenden Ressourcen geladen werden. Derzeit wird nur der Wert'network'unterstützt, wodurch der Service Worker umgangen wird, um die Ressource direkt über das Netzwerk zu laden. Wir planen jedoch, diese Funktion in Zukunft auf andere Werte auszuweiten.
Anwendungsfälle
Wie bereits erläutert, ist die erste Version der API im Grunde eine Notausstiegsmöglichkeit für einige Pfade, um die Kontrolle durch den Service Worker zu umgehen. Ob dies sinnvoll ist, hängt davon ab, wie Sie Ihren Service Worker verwenden und wie Nutzer Ihre Website nutzen.
Ein Beispiel wäre, wenn auf Ihrer Website eine Cache-first-Strategie (Fallback auf das Netzwerk) verwendet wird, aber einige Inhalte so selten aufgerufen werden, dass es kaum einen Vorteil hat, wenn sie im Cache gespeichert werden (z. B. archivierte Inhalte oder RSS-Feeds). Die Beschränkung dieser Pfade auf das Abrufen aus dem Netzwerk kann nur im Service Worker eingerichtet werden. Der Service Worker muss jedoch gestartet und ausgeführt werden, um zu entscheiden, wie diese Anfragen verarbeitet werden sollen.
Die Static Routing API hingegen umgeht den Service Worker mit wenigen deklarativen Zeilen vollständig:
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. deklaratives Ausführen eines Netzwerkabrufs und Starten eines Service Workers. Weitere Informationen finden Sie in der Erläuterung der Spezifikation zu einer möglichen „Endform“ der API.
Service Worker Static Routing API testen
Die Service Worker Static Routing API ist ab Chrome-Version 116 im Rahmen eines Ursprungstests verfügbar. Damit können Entwickler die API auf ihrer Website mit echten Nutzern testen und die Auswirkungen messen. Weitere Informationen zu 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 die Befehlszeile wie bei --enable-features=ServiceWorkerStaticRouter aktiviert werden.
Feedback und zukünftige Richtung
Die Service Worker Static Routing API wird derzeit aktiv entwickelt und weiterentwickelt. Wenn Sie der Meinung sind, dass die Funktion für Sie nützlich sein könnte, testen Sie sie bitte über den Ursprungstest und geben Sie Feedback zur API, zur Implementierung und zu den verfügbaren Funktionen.