Utiliser l'API Service Worker Static Routing pour contourner le service worker sur des chemins spécifiques

Rachel Andrew

À partir de Chrome 123, l'API de routage statique de service workers est disponible. Cette API vous permet d'indiquer de manière déclarative comment certains chemins de ressources doivent être récupérés. Cela signifie que le navigateur n'a pas besoin d'exécuter un service worker uniquement pour récupérer des réponses à partir d'un cache ou directement à partir du réseau. Cette API est en phase d'évaluation depuis Chrome 116. Cet article détaille son lancement dans Chrome 123.

Remarque :Pour en savoir plus sur cette fonctionnalité, consultez l'article d'origine Test de l'origine de l'API de routage statique ServiceWorker.

Utiliser l'API

Pour utiliser l'appel d'API event.addRoutes sur l'événement install du service worker. Transmettez à cette méthode une liste de routes, avec les propriétés suivantes:

condition

Indique quand la règle s'applique. Accepte les propriétés suivantes :

• urlPattern: instance URLPattern ou chaîne représentant une URLPattern valide, qui peut être transmise au constructeur URLPattern.
• requestMethod: chaîne contenant une méthode de requête.
• requestMode: chaîne contenant un mode de requête.
• requestDestination: chaîne contenant une destination de requête.
• runningStatus: chaîne, "running" ou "not-running". Il indique l'état d'exécution du service worker.

source

Spécifie comment les ressources correspondant à condition sont chargées. L'une des chaînes suivantes :

• "network"
• "cache"
• "fetch-event"
• "race-network-and-fetch-handler"

Remarque :source peut éventuellement inclure un nom de cache. Consultez l'exemple plus loin dans cet article.

Dans l'exemple suivant, les URL commençant par "/articles" sont acheminées vers le service worker s'il est en cours d'exécution. Si plusieurs conditions sont définies (par exemple, urlPattern et runningStatus), toutes doivent être remplies pour que le parcours soit utilisé.

addEventListener('install', (event) => {
  event.addRoutes({
    condition: {

          urlPattern: "/articles/*",
          runningStatus: "running"
    },
    source: "fetch-event"
  });
});

Dans l'exemple suivant, les publications dans un formulaire sont envoyées directement au réseau et contournent le service worker.

addEventListener('install', (event) => {
  event.addRoutes({
    condition: {
          urlPattern: "/form/*",
          requestMethod: "post"
    },
    source: "network"
  });
});

Dans l'exemple suivant, le stockage de cache nommé "pictures" est utilisé pour extraire les fichiers dont l'extension est .png ou .jpg.

addEventListener('install', (event) => {
  event.addRoutes({
    condition: {
      or: [
        {urlPattern: "*.png"},
        {urlPattern: "*.jpg"}
      ]
    },
    source: {
      cacheName: "pictures"
    }
  });
});

Modifications par rapport à la phase d'évaluation de l'origine

L'essai d'origine d'origine utilisait InstallEvent.registerRouter() au lieu de InstallEvent.addRoutes(). La méthode registerRouter() ne pouvait être appelée qu'une seule fois. Ce changement a été effectué en fonction des commentaires de la communauté sur le test de l'origine.

Remarque :Si votre code utilise la méthode registerRouter() obsolète, vous devez migrer vers addRoutes(). Nous prévoyons de supprimer registerRouter() dans Chrome 125.

La nouvelle API profite également des modifications apportées à URLPattern dans Chrome 121, permet de spécifier une méthode, un mode et une destination de requête, et ajoute des options de source supplémentaires.

Prise en charge dans les outils pour les développeurs Chrome

Les règles de routeur enregistrées s'affichent dans l'onglet Service Worker du panneau Application.

Dans le panneau Network (Réseau), si la requête correspond à la règle enregistrée, cela est indiqué dans la colonne "size" (Taille). Lorsque vous pointez sur la colonne "Taille", l'ID du routeur enregistré s'affiche. Les règles correspondantes s'affichent dans l'onglet de l'application.