Les service workers sont un outil puissant qui permet aux sites Web de fonctionner hors connexion et de créer eux-mêmes des règles de mise en cache spécialisées. Un gestionnaire fetch de service worker voit chaque requête d'une page qu'il contrôle, et peut décider s'il souhaite y diffuser une réponse à partir du cache du service worker, ou même réécrire l'URL pour extraire complètement une réponse différente, par exemple en fonction des préférences de l'utilisateur local.
Toutefois, cela peut avoir des répercussions sur les performances pour les service workers lorsqu'une page est chargée pour la première fois depuis un certain temps et que le service worker de contrôle n'est pas en cours d'exécution. Étant donné que toutes les récupérations doivent avoir lieu via le service worker, le navigateur doit attendre que celui-ci démarre, puis s'exécute pour savoir quel contenu charger. Ce coût de démarrage peut être faible, mais important, pour les développeurs qui utilisent des service workers afin d'améliorer les performances grâce à des stratégies de mise en cache.
Le préchargement de navigation est une approche permettant de résoudre le problème. Il permet d'envoyer des requêtes de navigation sur le réseau parallèlement au démarrage du service worker, mais il se limite aux requêtes de navigation initiales et inclut toujours le service worker dans le chemin critique. Depuis le lancement du préchargement de navigation, de nombreux efforts ont été déployés pour développer une solution plus générale à l'espace problématique, y compris des moyens pour que certaines requêtes ne soient pas bloquées au démarrage du service worker.
API Service Worker Static Routing
À partir de Chrome 116, l'API expérimentale Service Worker Static Routing est disponible pour tester la première étape d'une telle solution. Lorsqu'un service worker est installé, il peut utiliser l'API Service Worker Static Routing pour indiquer de manière déclarative comment récupérer certains chemins de ressources.
Dans la version initiale de l'API, les chemins peuvent être déclarés de manière à toujours être diffusés à partir du réseau, et non du service worker. Lorsqu'une URL contrôlée est chargée par la suite, le navigateur peut commencer à récupérer les ressources de ces chemins avant que le nœud de calcul de service n'ait fini de démarrer. Cette opération supprime le service worker des chemins dont vous savez qu'il n'a pas besoin d'un service worker.
Pour utiliser l'API, le service worker appelle event.registerRouter sur l'événement install avec un ensemble de règles:
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',
}]);
}
});
Chaque règle possède généralement deux propriétés:
condition: spécifie le moment où la règle s'applique en utilisant l'API URL Pattern pour faire correspondre les chemins d'accès aux ressources. La propriété peut utiliser une instanceURLPatternou l'objet brut équivalent compatible avec la transmission au constructeurURLPattern(par exemple,new URLPattern({pathname: '*.jpg'})ou simplement{pathname: '*.jpg'}).La flexibilité des formats d'URL signifie que la règle peut faire correspondre un élément aussi simple que n'importe quelle ressource dans un chemin d'accès, à des conditions très spécifiques et détaillées. Les modèles doivent généralement être familiers avec les utilisateurs des bibliothèques de routage populaires.
source: spécifie comment les ressources correspondant àconditionseront chargées. Aujourd'hui, seule la valeur'network'est acceptée (en contournant le service worker à charger la ressource directement sur le réseau), mais nous prévoyons d'étendre cette valeur à d'autres valeurs à l'avenir.
Cas d'utilisation
Comme expliqué, la version initiale de l'API constitue essentiellement un mécanisme de secours à partir de la commande de service worker pour certains chemins. L'utilité de cette solution dépend de la manière dont vous vous servez de votre service worker et de la manière dont les utilisateurs parcourent votre site.
C'est le cas, par exemple, si votre site utilise une stratégie axée sur le cache (revenir au réseau), mais que certains contenus sont si rarement consultés qu'il n'a que peu ou pas d'intérêt pour le cache (comme le contenu archivé ou les flux RSS). La restriction de l'extraction de ces chemins d'accès depuis le réseau peut être configurée uniquement dans le service worker, mais celui-ci doit toujours démarrer et exécuter le service pour décider comment gérer ces requêtes.
En revanche, l'API de routage statique contourne complètement le service worker avec quelques lignes déclaratives:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
À mesure que l'API Service Worker Static Routing évolue, il est prévu que cette configuration devienne plus flexible et compatible avec davantage de scénarios, comme la course déclarative d'une récupération de réseau et le démarrage d'un service worker. Pour en savoir plus, reportez-vous à l'exploration par le spécialiste de la "forme finale" de l'API.
Essayer l'API Service Worker Static Routing
L'API Service Worker Static Routing est disponible dans Chrome à partir de la version 116 après une phase d'évaluation, qui permet aux développeurs de tester l'API sur leur site auprès d'utilisateurs réels pour mesurer l'effet. Consultez Premiers pas avec les phases d'évaluation pour en savoir plus sur les phases d'évaluation.
Pour les tests en local, l'API Service Worker Static Routing peut être activée à l'aide d'une option sur chrome://flags/#service-worker-static-router ou en exécutant Chrome à partir de la commande, comme avec --enable-features=ServiceWorkerStaticRouter.
Commentaires et instructions futures
L'API Service Worker Static Routing est en cours de développement et est toujours en cours de développement. Si cela vous semble utile, veuillez l'essayer via la phase d'évaluation et envoyer vos commentaires sur l'API, l'implémentation et les fonctionnalités disponibles.