Les utilisateurs s'attendent à ce que les applications démarrent de manière fiable lorsque la connexion réseau est lente ou irrégulière, voire hors connexion. Ils s'attendent à ce que le contenu avec lequel ils ont interagi le plus récemment, comme les pistes multimédias, les billets et les itinéraires, soit disponible et utilisable. Lorsqu'une requête n'est pas possible, il s'attend à ce que l'application le prévienne au lieu d'échouer sans bruit ou de planter. Et ils veulent que tout cela se fasse rapidement. Comme vous pouvez le constater dans la section Les millisecondes, vous pouvez gagner des millions, une amélioration de 0,1 seconde du temps de chargement peut entraîner une augmentation des conversions pouvant atteindre 10%. Les service workers sont l'outil qui permet à votre progressive web app (PWA) de répondre aux attentes des utilisateurs.
Lorsqu'une application demande une ressource couverte par le champ d'application du service worker, celui-ci intercepte la requête et agit en tant que proxy réseau, même si l'utilisateur est hors connexion. Il peut ensuite décider s'il doit diffuser la ressource depuis le cache à l'aide de l'API Cache Storage, la diffuser depuis le réseau comme s'il n'existait pas de service worker actif ou la créer à partir d'un algorithme local. Cela vous permet d'offrir une expérience de haute qualité comme celle d'une application de plate-forme, même lorsque votre application est hors connexion.
Enregistrer un service worker
Pour qu'un service worker prenne le contrôle de votre page, celle-ci doit être enregistrée pour votre PWA. Cela signifie que la première fois qu'un utilisateur ouvre votre PWA, toutes ses requêtes réseau sont transmises directement à votre serveur, car le service worker ne contrôle pas encore vos pages.
Après avoir vérifié si le navigateur était compatible avec l'API Service Worker, votre PWA peut enregistrer un service worker. Une fois le chargement terminé, le service worker se connecte entre votre PWA et le réseau, interceptant les requêtes et diffuse 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 pour les développeurs dans votre navigateur préféré.
Dans Firefox et les navigateurs basés sur Chromium (Microsoft Edge, Google Chrome ou Samsung Internet):
- Accédez aux outils pour les développeurs, puis cliquez sur l'onglet Application.
- Dans le volet de gauche, sélectionnez Service workers.
- Vérifiez que l'URL de script du service worker s'affiche avec l'état "Activé". (Pour en savoir plus, consultez la section Cycle de vie.) Dans Firefox, l'état peut être "En cours d'exécution" ou "Arrêté".
Dans Safari:
- Cliquez sur Develop > Service Workers (Développer > Service Workers).
- Recherchez dans ce menu une entrée avec l'origine actuelle. Cliquez sur cette entrée pour ouvrir un inspecteur sur le contexte du service worker.
Champ d'application
Le champ d'application du dossier dans lequel se trouve votre service worker détermine son champ d'application. Un service worker résidant sur example.com/my-pwa/sw.js peut contrôler toute navigation dans le chemin my-pwa ou sous le chemin d'accès my-pwa, par exemple example.com/my-pwa/demos/. Les service workers ne peuvent contrôler que les éléments (pages, nœuds de calcul et collectivement "clients") inclus dans leur champ d'application.
Ce champ d'application s'applique aux onglets du navigateur et aux fenêtres PWA.
Un seul service worker est autorisé par niveau d'accès. 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 propose une gestion plus complexe des champs d'application, appelée partitions, qui affecte le fonctionnement des champs d'application avec les iFrames interdomaines. Pour en savoir plus sur l'implémentation de WebKit, consultez cet article de blog.
Cycle de vie
Le cycle de vie des service workers détermine la façon dont ils sont installés, indépendamment de votre installation 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 d'un service worker s'effectue en arrière-plan, sans nécessiter l'autorisation de l'utilisateur, même s'il n'installe pas la PWA. L'API Service Worker est disponible même sur les plates-formes non compatibles avec l'installation de PWA, telles que Safari et Firefox sur les ordinateurs de bureau.
Après l'installation, le service worker doit être activé pour pouvoir contrôler ses clients, y compris votre PWA. Lorsque le service worker est prêt à contrôler ses clients, l'événement activate se déclenche. Toutefois, par défaut, un service worker activé ne peut pas gérer la page qui l'a enregistrée tant que vous ne l'actualisez pas ou que vous rouvrez 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 du service worker à partir du serveur ne sont pas codés en octets.
Après une installation réussie, le nouveau service worker attend que l'ancien service worker ne contrôle plus aucun client avant d'être activé. Cet état est appelé "attente". C'est ainsi que le navigateur s'assure qu'une seule version de votre service worker s'exécute à la fois.
Le fait d'actualiser une page ou de rouvrir la PWA ne permet pas au nouveau service worker de prendre le contrôle. L'utilisateur doit fermer ou quitter tous les onglets et fenêtres avec le service worker actuel, puis revenir en arrière pour donner le contrôle au nouveau service worker. Pour en savoir plus, consultez Cycle de vie des service workers.
Durée de vie d'un service worker
Un service worker installé et enregistré peut gérer toutes les requêtes réseau dans son champ d'application. Elle s'exécute sur son propre thread, dont l'activation et l'arrêt sont contrôlées par le navigateur, ce qui lui permet de fonctionner avant même 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. Par conséquent, assurez-vous que tout ce que vous souhaitez réutiliser pour chaque exécution est disponible dans IndexedDB ou dans un autre espace de 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 depuis quelques secondes ou depuis trop longtemps. Le temps nécessaire à cette opération varie d'un navigateur à l'autre. Si un service worker a été arrêté et qu'un événement susceptible de le démarrer se produit, il redémarre.
Capacités
Un service worker enregistré et actif utilise un thread dont le cycle d'exécution est complètement différent de celui du thread principal de votre PWA. Toutefois, par défaut, le fichier de service worker lui-même n'a aucun comportement. Il ne met pas en cache ni ne diffuse aucune ressource. Voici ce que votre code doit faire. Vous découvrirez comment dans les chapitres suivants.
Les fonctionnalités des service workers ne concernent pas seulement le proxy ou le traitement des requêtes HTTP. D'autres fonctionnalités sont également disponibles à d'autres fins, telles que l'exécution de code en arrière-plan, les notifications push Web et le traitement des paiements. Nous aborderons ces ajouts dans la section Fonctionnalités.