Vous essayez de comprendre ce qu’est un travailleur de service ? Vous n’êtes pas seul !
Un Service Worker est un script qui s’exécute en arrière-plan, dans un thread séparé de l’interface utilisateur du navigateur. Le cache du Service Worker permet à un site web de fonctionner hors ligne. Ils constituent la centrale technique qui permet de transformer un site Web en une application Web progressive. Ils permettent une intégration profonde de la plateforme, comme la mise en cache riche, les notifications push et la synchronisation en arrière-plan.
Les travailleurs de service sont conçus pour être une plateforme extensible, des fonctionnalités supplémentaires sont actuellement prévues.
Ils ne peuvent pas accéder au DOM, mais peuvent intercepter toutes les requêtes réseau. Cela donne aux développeurs la possibilité de contrôler la façon dont les demandes sont traitées, offrant un moyen riche de faire fonctionner les sites Web hors ligne.
Les travailleurs de service sont ont été appelés un changement de jeu pour le web. Je ne pense pas que ce soit une simple exagération, car ils permettent de nombreuses capacités très nécessaires et rendent native l’architecture de base que j’ai utilisée pendant des années.
Les travailleurs de service semblent incroyables !
C’est la technologie clé ou l’API Web moderne derrière les applications Web progressives. Sans un travailleur de service, un site Web est juste un site Web, ajoutez un travailleur de service et vous avez maintenant une application.
Il y a quelques caractéristiques clés sur les travailleurs de service que vous devez comprendre :
- Un travailleur de service est un fichier JavaScript
- Ils s’exécutent sur un thread séparé de l’interface utilisateur
- Ils ne peuvent pas accéder directement au DOM
- Il y a un cycle de vie ou une série d’événements par lesquels un travailleur de service s’écoule pour devenir actif, expliqué plus tard
- Ils ne sont sous tension que lorsqu’ils sont utilisés, donc pas de tension de batterie
- Ils sont isolés à l’origine ou au domaine avec lequel ils sont enregistrés
- Les travailleurs de service nécessitent HTTPS
- Peuvent envoyer des messages vers et depuis l’interface utilisateur
- Ne nécessitent pas une page Web ouverte pour fonctionner
- Sont pris en charge par tous les principaux navigateurs, y compris iOS Safari
- Sont similaires aux Web Workers, mais meilleurs à bien des égards
- Comment fonctionnent les Service Workers ?
- L’extensibilité des travailleurs de service
- Le cycle de vie des travailleurs de service
- Combien de temps durent les travailleurs de service ?
- Comment puis-je vérifier si un travailleur de service est enregistré ?
- Comment puis-je désenregistrer un travailleur de service
- Cache de travailleur de service
- Comment puis-je mettre à jour mon cache de travailleur de service
- Quels navigateurs prennent en charge les travailleurs de service ?
- Quelle est la différence entre un Service Worker et un Web Worker
- Ce qu’un Service Worker ne peut pas faire
Comment fonctionnent les Service Workers ?
Un Service Worker se situe entre le navigateur et le réseau, agissant comme un serveur proxy, gérant une collection de tâches non centrées sur l’interface utilisateur. Ils sont pilotés par des événements et vivent en dehors du processus du navigateur, ce qui leur permet de travailler sans session active du navigateur. Le travailleur de service est un script qui s’exécute dans un thread, séparé de l’interface utilisateur. Cela permet au travailleur de service d’effectuer des tâches non liées à l’interface utilisateur, ce qui améliore les performances d’un site Web.
Les travailleurs de service se terminent lorsqu’ils ne sont pas utilisés et sont restaurés lorsque cela est nécessaire, ce qui leur évite de solliciter le processeur et de vider les batteries. Ils agissent comme un proxy réseau programmable, ou un intermédiaire entre le navigateur et le réseau, ce qui permet aux développeurs de concevoir la façon dont les demandes réseau sont traitées.
Le premier pouvoir qu’un travailleur de service apporte à un site Web est la possibilité d’activer des capacités hors ligne avec un contrôle granulaire. Cela se fait grâce à une API de mise en cache riche et à l’interception de toutes les requêtes réseau avant qu’elles ne partent.
La mise en cache permet non seulement des expériences hors ligne, mais les sites Web peuvent se charger instantanément lorsqu’ils sont récupérés dans le cache. La mise en cache du travailleur de service fait du réseau une amélioration progressive, ou non nécessaire pour rendre le site utilisable.
L’extensibilité du travailleur de service
Une caractéristique sous-estimée du travailleur de service est son extensibilité Les travailleurs de service sont conçus pour être l’épine dorsale qui prend en charge des fonctionnalités supplémentaires. Les deux premières fonctionnalités expédiées dans les navigateurs sont les notifications push natives et la synchronisation en arrière-plan. D’autres nouvelles API sont actuellement débattues et devraient commencer à apparaître dans les navigateurs dans un avenir proche.
Les travailleurs de service vivent dans leur propre thread et n’ont pas accès au DOM. Ils ont également leur propre portée globale, à laquelle on se réfère en utilisant l’objet ‘self’.
Ils exigent également qu’un site soit servi en utilisant HTTPS. Cette exigence est due aux puissantes fonctionnalités qu’offrent les travailleurs de service. HTTPS empêche de nombreuses attaques courantes. Aujourd’hui, tous les sites devraient être servis en utilisant HTTPS car les barrières à mettre en œuvre ont été levées et la quantité minimale de sécurité qu’ils offrent.
Ils sont également asynchrones. Cela signifie que toutes les API supportent les promesses. Cela signifie également que certaines API et fonctions ne sont pas accessibles dans les travailleurs de service. La plus notable est localStorage. Au lieu de cela, les données doivent être stockées en utilisant IndexedDB.
Cycle de vie des travailleurs de service
Avant de plonger dans ces grandes fonctionnalités des travailleurs de service, les développeurs doivent comprendre le cycle de vie.
Un travailleur de service doit être enregistré par un site Web. Comme certains navigateurs ne prennent toujours pas en charge les travailleurs de service, vous devez effectuer un contrôle des fonctionnalités avant d’enregistrer un travailleur de service. Ceci est fait en vérifiant la présence de ‘serviceWorker’ dans navigator.
if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(function(registration) { // Registration was successful }) .catch(function(err) { // registration failed :( }); } Pour enregistrer le travailleur de service, appelez navigator.serviceWorker.register. Passez le chemin d’accès au travailleur de service. La fonction register retourne une promesse.
En cas de succès, la promesse retourne une référence à l’objet d’enregistrement du travailleur de service. A partir de là, vous pouvez effectuer des tâches spécifiques de l’interface utilisateur selon les besoins.
Événements standard du travailleur de service
- install
- activate
- fetch
- push (non pris en charge par Safari)
- sync (pas encore pris en charge par la plupart des navigateurs)
Lorsqu’un travailleur de service est enregistré l’événement « install ». Dans cet événement, la tâche la plus commune à effectuer est appelée pré-cache.
Le pré-cache est l’endroit où une liste prédéfinie de fichiers d’actifs nécessaires pour former une page ou un site, et les ajouter au cache avant qu’ils ne soient demandés. Cela profite du cache du travailleur de service pour persister ces réponses.
self.addEventListener("install", event => { event.waitUntil( caches.open(preCacheName) .then(function (cache) { return cache.addAll(precache_urls); }) ); }); L’événement d’installation n’est déclenché qu’une fois dans la durée de vie d’un travailleur de service. L’événement ne se déclenchera plus jusqu’à ce que le travailleur de service soit mis à jour.
L’événement suivant qui se déclenche dans le cadre du cycle de vie de l’enregistrement est ‘activate’. Lorsqu’un travailleur de service est installé, il ne devient pas immédiatement actif. La séquence naturelle est qu’un nouveau travailleur de service attende jusqu’à ce que tous les ‘clients’ du travailleur de service soient fermés.
La raison pour laquelle les travailleurs de service sont conçus pour ne pas prendre immédiatement le relais est de les empêcher de briser l’expérience utilisateur.
La fonction skipWaiting force un travailleur de service en attente à devenir actif. Cela ne devrait être employé que lorsque vous êtes certain que le nouveau travailleur de service ne cassera aucun client existant.
self.skipWaiting(); 
Une fois que le travailleur de service devient actif, l’événement ‘activate’ se déclenche.
self.addEventListener("activate", event => { //on activate event.waitUntil(clients.claim()); }); Cet événement est généralement utilisé pour effectuer toute tâche de nettoyage ou de migration. Par exemple, la suppression des caches hérités qui pourraient entrer en conflit avec les caches du nouveau travailleur de service.
Combien de temps durent les travailleurs de service ?
Il n’y a pas de règle absolue quant à la durée d’exécution d’un travailleur de service par un navigateur. En interne, le moteur du navigateur utilisera un ensemble d’heuristiques pour déterminer quand mettre fin au processus du travailleur de service.
En général, si une page Web est dormante, le processus se mettra en rotation après une minute ou deux, peut-être dès 30 secondes.
En réalité, le temps exact dépendra du matériel, des habitudes d’utilisation, etc.
La bonne nouvelle est qu’il faut une poignée de millisecondes pour activer un travailleur de service. C’est si rapide que vous ne remarquerez vraiment aucune latence. Vous n’avez pas non plus besoin de programmer quelque chose de spécial pour faire face à un scénario sans le travailleur de service, votre site fonctionnera simplement. La magie de l’amélioration progressive.
Comment puis-je vérifier si un travailleur de service est enregistré?
Il existe plusieurs façons de vérifier si un travailleur de service est enregistré. La plus simple est d’appeler la méthode serviceworkers.getRegistrations.
navigator.serviceWorker.getRegistrations().then(registrations => { console.log(registrations); });C’est un code que vous pouvez ajouter à votre script de pages pour enregistrer l’enregistrement pour le support technique ou le débogage du développeur.
La méthode ‘getRegistrations’ renvoie un tableau de tous les travailleurs de service enregistrés sous la portée ou le site web actuel.
Si vous ne faites que consigner l’enregistrement dans la console, vous feriez mieux de consulter l’onglet ‘Application’ de Dev Tools. Il comporte un sous-panneau qui affiche un visuel du travailleur de service enregistré de l’origine. Vous pouvez également déclencher des événements de synchronisation en arrière-plan et tester les notifications push.
Vous pouvez également supprimer le travailleur de service, forcer une mise à jour et d’autres gestions générales qui aident au développement.
La vraie valeur que getRegistrations offre est pour une sorte de fonctionnalité de support back-door. Nous savons tous ce que c’est que d’essayer d’aider quelqu’un à distance et que vous ne pouvez pas accéder aux DevTools pour vraiment dépanner le problème. Parfois, vous voudrez une sorte de page de support visuel ou une modale pour fournir des informations sur l’état de l’application.
Le consommateur moyen ne saura pas comment accéder au panneau de la console DevTools. Au lieu de cela, vous pouvez créer une interface utilisateur au sein de l’application pour faire écho aux propriétés de l’objet d’enregistrement du travailleur de service.
Comment puis-je désenregistrer un travailleur de service
Hélas, vous ne rencontrerez pas un scénario où votre code de travailleur de service a créé un bug d’expérience utilisateur. Dans le cas où vous le faites, il y a quelques choses que vous pouvez faire pour supprimer ou désenregistrer un travailleur de service.
La plupart des scénarios où vous devez supprimer un travailleur de service sera lorsque vous développez l’application. Dans ce cas, vous pouvez utiliser les DevTools pour retirer ou supprimer le travailleur de service.
Si vous devez retirer ou supprimer un service worker déployé, cela devient un peu plus délicat. Il existe des moyens programmatiques pour vous sortir du pétrin.
Lisez-en plus sur les techniques de suppression.
Service Worker Caching
La spécification du service worker inclut des capacités de mise en cache natives. Cela remplace le traditionnel appCache qui a causé de nombreux problèmes de gestion depuis sa création. La mise en cache du travailleur de service est beaucoup plus facile à gérer.
L’API de cache fournit une couche de persistance qui stocke les réponses du réseau qui peuvent être interrogées par la requête correspondante.
La clé de l’utilisation de la mise en cache du travailleur de service est l’événement ‘fetch’ du travailleur de service. Cet événement se déclenche pour chaque requête réseau vous permettant d’intercepter la requête et de vérifier si la réponse a été mise en cache avant d’aller sur le réseau.
En accédant aux actifs dans le cache local, vous pouvez renoncer aux requêtes réseau coûteuses. Cela signifie que le site peut fonctionner lorsqu’il n’y a pas de réseau, hors ligne, ou une mauvaise connectivité réseau, des barres faibles ou une fausse connectivité cellulaire (connue sous le nom de LiFi).
self.addEventListener("fetch", event => { event.respondWith( fetchFromCache(event) .catch(() => fetch(request) .then(response => addToCache(cacheKey, request, response)) .catch(() => offlineResponse(resourceType, opts)) ) ); }); Dans l’exemple ci-dessus, le code vérifie si une réponse a été précédemment mise en cache. Si c’est le cas, la réponse mise en cache est renvoyée. Sinon, la demande est transmise au réseau.
Lorsque la demande revient, la réponse est mise en cache et renvoyée à l’interface utilisateur.
Si le réseau échoue, la logique se rabat sur une réponse hors ligne.
Il y a beaucoup de pièces mobiles utilisées dans le code de l’exemple. Je fournirai plus de détails dans un suivi des articles.
Comment puis-je mettre à jour mon cache de travailleur de service
Une idée fausse commune est une fois que vous cachez une demande de réseau, il est stocké pour l’éternité. Ce n’est pas le cas. Vous avez un contrôle total sur quand et comment le cache est invalidé et mis à jour.
C’est un sujet très complexe et impliqué. Je pense que je peux personnellement détailler environ 3 douzaines de stratégies de mise en cache, toutes impliquent une façon de gérer l’invalidation du cache ou la mise à jour du cache.
Je pense que la clé de l’invalidation est de déterminer soit une valeur de temps pour invalider (time to live), un manifeste ou un processus de mise à jour en arrière-plan. Dans le dernier cas, vous pouvez faire une requête HEAD pour voir si une mise à jour a été faite sur le serveur en comparant la valeur de l’en-tête last-updated avec le moment où la réponse a été mise en cache.
Il n’y a pas de réponse unique pour chaque application. Vous devrez planifier votre stratégie et être prêt à ajuster au fur et à mesure que vous voyez comment votre application est utilisée.
Quels navigateurs prennent en charge les travailleurs de service ?
Tous les navigateurs modernes prennent en charge les travailleurs de service, au moins la mise en cache. Chrome, FireFox et Edge prennent en charge les notifications push natives et Chrome et Edge ont un support de synchronisation en arrière-plan.
Cela signifie que les fonctionnalités de base de la PWA sont disponibles dans tous les appareils et navigateurs. Le push et la synchronisation en arrière-plan sont des améliorations.
Nous avons construit plusieurs Progressive Web Apps qui ont nécessité des stratégies sophistiquées de mise en cache hors ligne pour permettre aux applications de fonctionner hors ligne, même sur iOS. Ces applications nécessitent que toutes les demandes, même les actions POST, PUT et DELETE soient mises en cache dans une file d’attente. Nous avons rendu ces applications synchrones même sur iOS lorsque les connexions étaient connues pour être disponibles.
Quelle est la différence entre un Service Worker et un Web Worker
Les Service Workers et les Web Workers sont des outils similaires. Tous deux exécutent des processus dans un thread séparé de l’interface utilisateur. La véritable différence réside dans le contexte d’utilisation réel.
Les deux n’ont pas accès au DOM ou à l’objet fenêtre. Ils sont meilleurs pour les tâches de niveau intermédiaire ou les tâches longues et intensives en processus.
Les travailleurs Web ne s’exécutent que lorsqu’une page Web est ouverte et qu’une tâche est déclenchée à partir d’un script dans la page.
Un travailleur de service peut également s’exécuter lorsqu’une page est ouverte, mais il peut aussi être déclenché par un événement de la plate-forme comme une notification push. Une page web ne doit pas nécessairement être ouverte pour qu’un travailleur de service s’exécute.
Les travailleurs de service agissent également comme un proxy entre le réseau et l’interface utilisateur. Si une page est utilisée (le scénario le plus courant), toutes les requêtes réseau HTTPS passent par le travailleur de service, comme vous l’avez appris dans la section sur la mise en cache.
La communication entre l’interface utilisateur et les deux travailleurs se fait à l’aide de la méthode postMessage et de l’événement message. Si vous avez fait de la programmation multithread, ce modèle est très familier.
Ce qu’un Service Worker ne peut pas faire
Les Service Workers ne peuvent pas accéder à l’objet Window
L’objet window s’exécute dans le thread de l’UI, séparé du thread du Service Worker. Cela signifie qu’un travailleur de service ne peut pas manipuler directement les éléments du DOM. Le travailleur de service et la fenêtre peuvent communiquer via la méthode postMessage. Cela permet de transmettre des messages dans les deux sens. Vous devrez avoir une logique de chaque côté pour traiter les messages et déclencher différents flux de travail.
Les travailleurs de service nécessitent HTTPS
Parce que les travailleurs de service ont tant de pouvoir, ils ne sont activés que si la page est servie en utilisant HTTPS. Cela garantit un niveau de sécurité pour permettre au travailleur de service de faire les choses pour lesquelles il est conçu.
Sur HTTP, le travailleur de service serait susceptible d’attaques de type man in the middle. Les développeurs peuvent travailler sur localhost, ce qui nous évite d’installer un certificat TLS local.
En d’autres termes, la réponse à la question est-ce qu’un service worker fonctionne sur HTTP est non. Le site rendra toujours, mais le travailleur de service ne s’enregistre pas et n’est pas exécuté.
Sont uniquement asynchrones
Les travailleurs de service sont asynchrones, ce qui signifie qu’ils utilisent et s’appuient sur les Promesses et les API qui utilisent des Promesses. Cela signifie que les API synchrones comme XHR et localStorage ne sont pas disponibles pour un travailleur de service. N’ayez crainte, vous pouvez utiliser l’API Fetch (qui a remplacé XHR) et IndexedDB. La plupart des API qui n’interagissent pas directement avec l’objet fenêtre sont accessibles dans un travailleur de service.