Les utilisateurs s'attendent à ce que les applications démarrent 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 notification ou de planter. Et les utilisateurs souhaitent tout faire rapidement. Comme nous pouvons le constater dans cette étude, les millisecondes rapportent des millions, une amélioration du temps de chargement de 0,1 seconde peut suffire à accroître le nombre de conversions de 10%. En résumé, les utilisateurs s'attendent à ce que les PWA soient fiables. C'est pourquoi nous disposons de service workers.
Bonjour les service workers
Lorsqu'une application demande une ressource couverte par le champ d'application du service worker, y compris lorsqu'un utilisateur est hors connexion, le service worker intercepte la requête en agissant comme un proxy réseau. Il peut ensuite décider s'il doit diffuser la ressource depuis le cache via l'API Cache Storage, depuis le réseau comme d'habitude sans service worker, ou la créer à partir d'un algorithme local. Cela vous permet de proposer une expérience semblable à celle fournie par une application de plate-forme. Elle peut même fonctionner entièrement 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. Autrement dit, la première fois qu'un utilisateur accède à votre PWA, les 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 est compatible avec l'API Service Worker, votre PWA peut enregistrer un service worker. Une fois chargé, le service worker établit une relation entre votre PWA et le réseau, intercepte 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 du script du service worker apparaît bien avec l'état "Activé". Vous découvrirez la signification de cet état dans la section "Cycle de vie" de ce chapitre. Dans Firefox, l'état peut être "En cours d'exécution" ou "Arrêté".
Dans Safari:
- Cliquez sur le menu Développer, puis sur le sous-menu Service workers.
- Vérifiez qu'une entrée correspondant à l'origine actuelle apparaît dans le sous-menu. Elle ouvre un inspecteur sur le contexte du service worker.
Définition du 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 n'importe quelle navigation sur le chemin d'accès my-pwa ou inférieur, 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") de leur champ d'application. Le champ d'application s'applique aux onglets du navigateur et aux fenêtres de PWA.
Un seul service worker par niveau d'accès est autorisé. Lorsqu'elle est active et en cours d'exécution, une seule instance est généralement disponible, quel que soit le nombre de clients en mémoire (comme des fenêtres PWA ou des onglets de navigateur).
Safari propose une gestion plus complexe des champs d'application, appelée "partitions", qui affecte le fonctionnement des champs d'application si vous disposez d'iFrames sur plusieurs domaines. Pour en savoir plus sur l'implémentation de WebKit, consultez cet article de blog.
Lifecycle (Cycle de vie)
Le cycle de vie des service workers qui détermine la façon dont ils sont installés est distinct de l'installation de 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, son événement install 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 même disponible 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 ne contrôle plus ses clients, y compris votre PWA. Vous devez d'abord l'activer. Lorsque le service worker est prêt à contrôler ses clients, l'événement activate se déclenche. Toutefois, cela ne signifie pas que la page qui a enregistré le service worker sera gérée. Par défaut, le service worker ne prend le contrôle que lorsque vous accédez de nouveau à cette page, que ce soit parce que la page est actualisée ou par la réouverture de 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 qui contrôle actuellement le client et la nouvelle version (à partir de votre serveur) du même fichier sont différents.
Après une installation réussie, le nouveau service worker attend d'être activé jusqu'à ce que l'ancien service worker ne contrôle aucun client. Cet état, appelé "waiting" (en attente), permet au navigateur de s'assurer qu'une seule version de votre service worker s'exécute à la fois. Le nouveau service worker ne prend pas le contrôle lors de l'actualisation d'une page ou de la réouverture de la PWA. L'utilisateur doit fermer tous les onglets et fenêtres ou quitter l'interface avec le service worker actuel, puis revenir en arrière. Ce n'est qu'alors que le nouveau service worker prendra le contrôle. Pour en savoir plus, consultez cet article sur le cycle de vie des service workers.
Durée de vie d'un service worker
Une fois installé et enregistré, un service worker peut gérer toutes les requêtes réseau dans son champ d'application. Il s'exécute sur son propre thread, et l'activation et l'arrêt sont contrôlés par le navigateur. Elle peut ainsi fonctionner avant ou après l'ouverture de votre PWA. Bien que les service workers s'exécutent sur leur propre thread, rien ne garantit que l'état en mémoire persiste entre leurs exécutions. Assurez-vous donc que tout ce que vous souhaitez réutiliser à 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 comprise dans son champ d'application est demandée ou lorsqu'un événement déclencheur, tel qu'une synchronisation périodique en arrière-plan ou un message push, est reçu.
Les service workers n'ont pas une durée de vie indéfinie. Bien que les délais exacts diffèrent selon les navigateurs, les service workers sont arrêtés s'ils sont inactifs depuis quelques secondes ou depuis trop longtemps. Si un service worker a été arrêté et qu'un événement qui déclenche son démarrage, il redémarre.
Capacités
Avec un service worker enregistré et actif, vous disposez d'un thread dont le cycle de vie d'exécution est complètement différent de celui 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, car cette opération doit être effectuée par votre code. Vous découvrirez comment faire dans les chapitres suivants.
Les fonctionnalités du service worker ne concernent pas uniquement le proxy ou la diffusion de requêtes HTTP. D'autres fonctionnalités sont également disponibles pour 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 fonctionnalités plus en détail dans la section Fonctionnalités.