Servicemedewerkers zijn een krachtig hulpmiddel waarmee websites offline kunnen werken en gespecialiseerde cachingregels voor zichzelf kunnen maken. Een fetch van een servicemedewerker ziet elk verzoek van een pagina die hij beheert, en kan beslissen of hij er een reactie op wil plaatsen vanuit de cache van de servicemedewerker, of zelfs de URL wil herschrijven om een volledig ander antwoord op te halen, bijvoorbeeld op basis van lokale gebruiker voorkeuren.
Er kunnen echter prestatiekosten zijn voor servicemedewerkers wanneer een pagina voor het eerst sinds een tijdje wordt geladen en de controlerende servicemedewerker momenteel niet actief is. Omdat alle ophaalacties via de servicemedewerker moeten plaatsvinden, moet de browser wachten tot de servicemedewerker is opgestart en uitgevoerd om te weten welke inhoud moet worden geladen. Deze opstartkosten kunnen klein maar aanzienlijk zijn voor ontwikkelaars die servicemedewerkers gebruiken om de prestaties te verbeteren via cachingstrategieën.
Het vooraf laden van navigatie is één manier om het probleem op te lossen, waarbij navigatieverzoeken via het netwerk kunnen worden gedaan parallel aan het opstarten van de servicemedewerker, maar het is beperkt tot initiële navigatieverzoeken en omvat nog steeds de servicemedewerker in het kritieke pad. Sinds de lancering van het vooraf laden van navigatie zijn er meerdere pogingen ondernomen om een meer algemene oplossing voor het probleem te ontwikkelen, inclusief manieren om sommige verzoeken helemaal niet te blokkeren bij het opstarten van servicemedewerkers.
De Service Worker Statische Routing-API
Vanaf Chrome 116 is de experimentele Service Worker Static Routing API beschikbaar voor het testen van de eerste stap naar een dergelijke oplossing. Wanneer een servicemedewerker is geïnstalleerd, kan deze de Service Worker Static Routing API gebruiken om declaratief aan te geven hoe bepaalde bronpaden moeten worden opgehaald.
In de eerste versie van de API kunnen paden worden aangegeven dat ze altijd via het netwerk worden bediend, en niet via de servicemedewerker. Wanneer later een gecontroleerde URL wordt geladen, kan de browser bronnen uit die paden gaan ophalen voordat de servicemedewerker klaar is met starten. Hiermee wordt de servicemedewerker verwijderd uit de paden waarvan u weet dat deze geen servicemedewerker nodig hebben.
Om de API te gebruiken, roept de servicemedewerker event.registerRouter aan tijdens de install met een reeks regels:
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',
}]);
}
});
Elke regel heeft doorgaans twee eigenschappen:
condition: specificeert wanneer de regel van toepassing is met behulp van de URL Pattern API om bronpaden te matchen. De eigenschap kan eenURLPatterninstantie aannemen, of het equivalente gewone object dat compatibel is om te worden doorgegeven aan deURLPatternconstructor (bijvoorbeeldnew URLPattern({pathname: '*.jpg'})of gewoon{pathname: '*.jpg'}).De flexibiliteit van URL-patronen betekent dat de regel zoiets eenvoudigs als elke bron onder een pad kan koppelen aan zeer specifieke en gedetailleerde voorwaarden. De patronen zouden over het algemeen bekend moeten zijn bij gebruikers van populaire routeringsbibliotheken.
source: specificeert hoe de overeenkomendeconditionvoor bronnen wordt geladen. Momenteel wordt alleen de waarde'network'ondersteund (waarbij de servicemedewerker wordt omzeild om de bron rechtstreeks via het netwerk te laden), maar het plan is om dit in de toekomst uit te breiden naar andere waarden .
Gebruiksgevallen
Zoals uitgelegd is de initiële versie van de API voor sommige paden in wezen een ontsnappingsluik voor de controle van servicemedewerkers. Waar dit zinvol is om te gebruiken, zal afhankelijk zijn van hoe u uw servicemedewerker gebruikt en hoe gebruikers uw site bezoeken.
Een voorbeeld hiervan kan zijn dat uw site een cache-first-strategie gebruikt (terugvallen op het netwerk), maar dat bepaalde inhoud zo zelden wordt bezocht dat het weinig tot geen waarde heeft om ooit in de cache terecht te komen (zoals gearchiveerde inhoud of RSS-feeds). Het beperken van het ophalen van deze paden uit het netwerk kan alleen worden ingesteld in de servicewerker, maar de servicemedewerker moet nog steeds opstarten en rennen om te beslissen hoe deze verzoeken moeten worden afgehandeld.
De statische routerings-API omzeilt de servicemedewerker daarentegen volledig met een paar declaratieve regels:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
Naarmate de Service Worker Static Routing API evolueert, is het de bedoeling dat deze configuratie flexibeler wordt en meer scenario's ondersteunt, zoals het declaratief racen van een netwerkophaalactie en het opstarten van servicemedewerkers. Zie de verkenning van de spec-uitlegger van een mogelijke "definitieve vorm" van de API voor meer details.
Ik probeer de Service Worker Static Routing API uit
De Service Worker Static Routing API is beschikbaar in Chrome vanaf versie 116 na een origin-proefperiode , waarmee ontwikkelaars de API op hun site kunnen testen met echte gebruikers om het effect te meten. Zie 'Aan de slag met herkomstproeven' voor achtergrondinformatie over herkomstproeven.
Voor lokaal testen kan de Service Worker Static Routing API worden ingeschakeld met een vlag op chrome://flags/#service-worker-static-router , of door Chrome uit te voeren vanuit de opdracht, zoals met --enable-features=ServiceWorkerStaticRouter .
Feedback en toekomstige richtingen
De Service Worker Static Routing API wordt actief ontwikkeld en nog steeds vorm gegeven. Als het nuttig voor je lijkt te zijn, probeer het dan uit via de origin-proefversie en geef feedback over de API, implementatie en beschikbare functionaliteit .