Phase d'évaluation de l'API Service Worker Static Routing

Brendan Kenny

Les services workers sont un outil puissant qui permet aux sites Web de fonctionner hors connexion et de créer des règles de mise en cache spécialisées pour eux-mêmes. Un gestionnaire fetch de service worker voit chaque requête provenant d'une page qu'il contrôle et peut décider s'il souhaite y répondre à partir du cache du service worker, ou même réécrire l'URL pour récupérer une réponse entièrement différente (par exemple, en fonction des préférences locales de l'utilisateur).

Toutefois, les services workers peuvent avoir un coût en termes de performances 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 se produire via le service worker, le navigateur doit attendre que le service worker démarre et s'exécute pour savoir quel contenu charger. Ce coût de démarrage peut être faible, mais significatif pour les développeurs qui utilisent des services workers pour 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'effectuer des requêtes de navigation sur le réseau en parallèle du démarrage du service worker. Toutefois, il est limité aux requêtes de navigation initiales et inclut toujours le service worker dans le chemin critique. Depuis le lancement du préchargement de navigation, plusieurs efforts ont été déployés pour développer une solution plus générale au problème, y compris des moyens pour que certaines requêtes ne soient pas du tout bloquées au démarrage du service worker.

API de routage statique de service workers

À partir de Chrome 116, l'API expérimentale de routage statique de service workers est disponible pour tester la première étape d'une telle solution. Lorsqu'un service worker est installé, il peut utiliser l'API de routage statique de service worker pour indiquer de manière déclarative comment certains chemins de ressources doivent être récupérés.

Dans la version initiale de l'API, les chemins peuvent être déclarés pour être toujours diffusés à partir du réseau, et non du service worker. Lorsqu'une URL contrôlée est chargée ultérieurement, le navigateur peut commencer à extraire des ressources à partir de ces chemins avant que le worker de service ne soit complètement démarré. Cela supprime le service worker des chemins que vous savez ne pas avoir 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 comporte généralement deux propriétés:

• condition: spécifie quand la règle s'applique à l'aide de l'API URL Pattern pour faire correspondre les chemins de ressources. La propriété peut prendre une instance URLPattern ou l'objet simple équivalent qui peut être transmis au constructeur URLPattern (par exemple, new URLPattern({pathname: '*.jpg'}) ou simplement {pathname: '*.jpg'}).

  La flexibilité des formats d'URL signifie que la règle peut correspondre à quelque chose d'aussi simple qu'une ressource sous un chemin d'accès, à des conditions très spécifiques et détaillées. Les modèles doivent généralement être familiers aux utilisateurs de bibliothèques de calcul d'itinéraires populaires.

• source: spécifie comment les ressources correspondant à condition seront chargées. Actuellement, seule la valeur 'network' est prise en charge (le service worker est contourné pour charger directement la ressource sur le réseau), mais nous prévoyons de l'étendre à d'autres valeurs à l'avenir.

Cas d'utilisation

Comme expliqué, la version initiale de l'API est essentiellement une échappatoire au contrôle du service worker pour certains chemins. L'utilisation de cette fonctionnalité dépendra de la façon dont vous utilisez votre service worker et de la façon dont les utilisateurs parcourent votre site.

Par exemple, si votre site utilise une stratégie de mise en cache prioritaire (recours au réseau), mais que certains contenus sont si rarement consultés qu'il n'est pas intéressant de les mettre en cache (comme les contenus archivés ou les flux RSS), La restriction de l'extraction de ces chemins à partir du réseau ne peut que être configurée dans le service worker, mais le service worker doit toujours démarrer et s'exécuter pour décider comment gérer ces requêtes.

À l'inverse, 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 de routage statique du service worker évolue, cette configuration devrait devenir plus flexible et prendre en charge davantage de scénarios, comme la mise en concurrence déclarative d'une récupération réseau et du démarrage du service worker. Pour en savoir plus, consultez l'explication des spécifications sur la "forme finale" potentielle de l'API.

Essayer l'API de routage statique de service workers

L'API de routage statique de service workers est disponible dans Chrome à partir de la version 116, sous la forme d'une phase d'évaluation, qui permet aux développeurs de tester l'API sur leur site avec de vrais utilisateurs afin de mesurer son impact. Pour en savoir plus sur les essais d'origine, consultez Premiers pas avec les essais d'origine.

Pour les tests locaux, l'API de routage statique de service workers peut être activée à l'aide d'un indicateur dans chrome://flags/#service-worker-static-router ou en exécutant Chrome à partir de la commande comme avec --enable-features=ServiceWorkerStaticRouter.

Commentaires et perspectives d'avenir

L'API de routage statique de service workers est en cours de développement et est encore en cours de conception. Si vous pensez qu'elle peut vous être utile, veuillez l'essayer via le test de l'origine et nous faire part de vos commentaires sur l'API, l'implémentation et les fonctionnalités disponibles.