Les utilisateurs s'attendent à ce que les applications démarrent de manière fiable sur des connexions réseau lentes ou instables, voire hors connexion. Ils s'attendent à ce que le contenu avec lequel ils ont interagi récemment, comme les pistes multimédias ou les billets et itinéraires, soit disponible et utilisable. Lorsqu'une requête n'est pas possible, ils s'attendent à ce que l'application les en informe au lieu d'échouer ou de planter en silence. Et ils veulent que tout cela se fasse rapidement. Comme vous pouvez le voir dans Milliseconds make millions, même une amélioration de 0,1 seconde du temps de chargement peut augmenter les conversions jusqu'à 10 %. Les service workers sont l'outil qui permet à votre progressive web app (PWA) de répondre aux attentes de vos utilisateurs.
Lorsqu'une application demande une ressource couverte par le champ d'application du service worker, celui-ci intercepte la requête et agit comme un proxy réseau, même si l'utilisateur est hors connexion. Il peut ensuite décider de diffuser la ressource à partir du cache à l'aide de l'API Cache Storage, de la diffuser à partir du réseau comme s'il n'y avait pas de service worker actif ou de la créer à partir d'un algorithme local. Cela vous permet d'offrir une expérience de haute qualité semblable à celle d'une application de plate-forme, même lorsque votre application est hors connexion.
Enregistrer un service worker
Avant qu'un service worker prenne le contrôle de votre page, il doit être enregistré pour votre PWA. Cela signifie que la première fois qu'un utilisateur ouvre votre PWA, toutes ses requêtes réseau sont envoyées directement à votre serveur, car le service worker n'a pas encore le contrôle de vos pages.
Après avoir vérifié si le navigateur est compatible avec l'API Service Worker, votre PWA peut enregistrer un service worker. Une fois chargé, le service worker s'installe entre votre PWA et le réseau, interceptant les requêtes et fournissant les réponses correspondantes.
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register("/serviceworker.js");
}
Vérifier si un service worker est enregistré
Pour vérifier si un service worker est enregistré, utilisez les outils de développement de votre navigateur préféré.
Dans Firefox et les navigateurs basés sur Chromium (Microsoft Edge, Google Chrome ou Samsung Internet) :
- Ouvrez les outils de développement, puis cliquez sur l'onglet Application.
- Dans le volet de gauche, sélectionnez Service Workers.
- Vérifiez que l'URL du script du service worker s'affiche avec l'état "Activé". (Pour en savoir plus, consultez Cycle de vie.) Sur Firefox, l'état peut être "En cours d'exécution" ou "Arrêté".
Dans Safari :
- Cliquez sur Développer > Service Workers.
- Recherchez une entrée avec l'origine actuelle dans ce menu. Si vous cliquez sur cette entrée, un outil d'inspection s'ouvre sur le contexte du service worker.
Champ d'application
Le dossier dans lequel se trouve votre service worker détermine son champ d'application. Un service worker situé à l'adresse example.com/my-pwa/sw.js peut contrôler toute navigation à l'adresse my-pwa ou à une adresse inférieure, comme example.com/my-pwa/demos/. Les service workers ne peuvent contrôler que les éléments (pages, workers, collectivement "clients") de leur portée.
Ce champ d'application s'applique aux onglets de navigateur et aux fenêtres PWA.
Un seul service worker est autorisé par scope. Lorsqu'un service worker est actif et en cours d'exécution, une seule instance est généralement disponible, quel que soit le nombre de clients (fenêtres PWA ou onglets de navigateur) en mémoire.
Safari dispose d'une gestion de portée plus complexe, appelée partitions, qui affecte le fonctionnement des portées avec les iFrames multidomaines. Pour en savoir plus sur l'implémentation de WebKit, consultez cet article de blog.
Cycle de vie
Les service workers ont un cycle de vie qui dicte la façon dont ils sont installés, séparément de l'installation de votre PWA.
Le cycle de vie du service worker commence par l'enregistrement du service worker. Le navigateur tente ensuite de télécharger et d'analyser le fichier du service worker. Si l'analyse réussit, l'événement install du service worker est déclenché. L'événement install ne se déclenche qu'une seule fois.
L'installation du service worker se fait de manière silencieuse, sans nécessiter l'autorisation de l'utilisateur, même si celui-ci n'installe pas la PWA. L'API Service Worker est disponible même sur les plates-formes qui ne prennent pas en charge l'installation de PWA, comme Safari et Firefox sur les appareils de bureau.
Une fois le service worker installé, il doit être activé avant de pouvoir contrôler ses clients, y compris votre PWA. L'événement activate se déclenche lorsque le service worker est prêt à contrôler ses clients. Toutefois, par défaut, un service worker activé ne peut pas gérer la page qui l'a enregistré tant que vous n'y accédez pas à nouveau en actualisant la page ou en rouvrant la PWA.
Vous pouvez écouter les événements dans le champ d'application global du service worker à l'aide de l'objet self :
serviceworker.js
// This code executes in its own worker or thread
self.addEventListener("install", event => {
console.log("Service worker installed");
});
self.addEventListener("activate", event => {
console.log("Service worker activated");
});
Mettre à jour un service worker
Les service workers sont mis à jour lorsque le navigateur détecte que le service worker contrôlant le client et la nouvelle version du fichier service worker du serveur sont différents au niveau des octets.
Une fois l'installation terminée, le nouveau service worker attend d'être activé jusqu'à ce que l'ancien service worker ne contrôle plus aucun client. Cet état est appelé "en attente". Il permet au navigateur de s'assurer qu'une seule version de votre service worker est exécutée à la fois.
L'actualisation d'une page ou la réouverture de la PWA ne permettront pas au nouveau service worker de prendre le contrôle. L'utilisateur doit fermer tous les onglets et fenêtres qui utilisent le service worker actuel, ou quitter la page, puis revenir en arrière pour donner le contrôle au nouveau service worker. Pour en savoir plus, consultez Cycle de vie du service worker.
Durée de vie du service worker
Un service worker installé et enregistré peut gérer toutes les requêtes réseau dans son champ d'application. Il s'exécute sur son propre thread, avec une activation et une terminaison contrôlées par le navigateur, ce qui lui permet de fonctionner même avant l'ouverture de votre PWA ou après sa fermeture. Les service workers s'exécutent sur leur propre thread, mais l'état en mémoire peut ne pas persister entre les exécutions d'un service worker. Assurez-vous donc que tout ce que vous souhaitez réutiliser pour chaque exécution est disponible dans IndexedDB ou dans un autre stockage persistant.
S'il n'est pas déjà en cours d'exécution, un service worker démarre chaque fois qu'une requête réseau est envoyée dans son champ d'application ou lorsqu'il reçoit un événement déclencheur tel qu'une synchronisation périodique en arrière-plan ou un message push.
Les service workers sont arrêtés s'ils sont inactifs pendant quelques secondes ou s'ils sont occupés trop longtemps. Les délais varient selon les navigateurs. Si un service worker a été arrêté et qu'un événement se produit et devrait le démarrer, il redémarre.
Capacités
Un service worker enregistré et actif utilise un thread dont le cycle de vie d'exécution est complètement différent de celui du thread principal de votre PWA. Toutefois, par défaut, le fichier service worker lui-même n'a aucun comportement. Il ne mettra en cache ni ne diffusera aucune ressource. C'est à votre code de le faire. Vous découvrirez comment dans les chapitres suivants.
Les capacités du service worker ne sont pas limitées au proxy ou à la diffusion de requêtes HTTP. D'autres fonctionnalités sont disponibles en plus de celle-ci pour d'autres objectifs, comme l'exécution de code en arrière-plan, les notifications Web push et le traitement des paiements. Nous aborderons ces ajouts dans Fonctionnalités.