Module 4 : Technologies Web avancées

4.2.3 Présentation des service workers

Les applications Web progressives doivent être rapides et installables, ce qui signifie qu'elles fonctionnent en ligne ou hors connexion, et sur des connexions lentes ou intermittentes. Pour cela, nous devons mettre en cache le shell d'application à l'aide d'un service worker, afin qu'il soit toujours disponible de manière rapide et fiable. 

Qu'est-ce qu'un service worker ?

Un service worker est un script exécuté par votre navigateur en arrière-plan, et séparé d'une page Web. Il permet d'accéder à des fonctionnalités qui n'ont pas besoin d'une page Web ni d'interaction utilisateur. Ils fournissent aujourd'hui des fonctionnalités telles que les notifications push et la synchronisation en arrière-plan. À l'avenir, les service workers offriront d'autres fonctionnalités comme la synchronisation périodique et le gardiennage virtuel. La fonctionnalité principale qui sera abordée dans ce didacticiel est la capacité à intercepter et à traiter des demandes réseau, y compris la gestion programmatique de la mise en cache des réponses.

Cette API est tout particulièrement intéressante, car elle permet une utilisation hors connexion, et offre ainsi aux développeurs un contrôle total de l'expérience.

Avant les service workers, il existait une autre API qui offrait aux utilisateurs une expérience hors connexion sur le Web. Elle s'appelait AppCache. Plusieurs problèmes majeurs se posaient avec AppCache. Tout d'abord, l'API présentait un grand nombre d'inconnus. De plus, même si la conception graphique fonctionnait très bien avec les applications Web monopage, elle n'était pas aussi convaincante pour les sites multipage. Les service workers, quant à eux, ont été conçus pour ne pas causer les mêmes problèmes.

Points à prendre en compte à propos des service workers :

  • Un service worker est un traitement JavaScript. Il ne peut donc pas accéder au DOM directement. En revanche, il peut communiquer avec les pages qu'il contrôle en répondant aux messages envoyés via l'interface postMessage, et ces pages peuvent manipuler le DOM si besoin.
  • Un service worker est un proxy réseau programmable qui vous permet de contrôler la manière dont sont traitées les demandes réseau venant de votre page.
  • Il est arrêté quand il n'est pas utilisé, et redémarré dès que vous en avez besoin. Vous ne pouvez donc pas compter sur un état global au sein des gestionnaires onfetch et onmessage du service worker. Si vous avez besoin de continuer à disposer des informations et de les réutiliser entre les redémarrages, les service workers ont accès à l'API IndexedDB.
  • Les service workers ont énormément recours aux promesses. S'il s'agit d'un concept nouveau pour vous, interrompez la lecture de cet article, et consultez celui-ci en anglais : Promises, an introduction.

Le cycle de vie d'un service worker

Le cycle de vie d'un service worker est entièrement distinct de votre page Web.

Pour installer un service worker sur votre site, vous devez l'enregistrer dans votre page JavaScript. Lors de l'enregistrement, le navigateur lance l'étape d'installation du service worker en arrière-plan.

Pendant cette étape d'installation, il est en général recommandé de mettre en cache certains éléments statiques. Si la mise en cache de tous les fichiers réussit, l'installation du service worker aussi. Si le téléchargement ou la mise en cache d'un des fichiers échoue, l'étape d'installation n'aboutit pas, et le service worker n'est pas activé (en d'autres termes, il n'est pas installé). Ne vous inquiétez pas si ce problème survient. L'étape d'installation sera à nouveau tentée la prochaine fois. En revanche, si l'installation réussit, rappelez-vous que vous disposez d'éléments statiques mis en cache.

Une fois l'installation effectuée, c'est au tour de l'étape d'activation. Profitez de cette occasion pour traiter et gérer d'anciennes mises en cache. Nous aborderons ce sujet dans la section de mise à jour du service worker.

Une fois l'étape d'activation terminée, le service worker contrôle toutes les pages qui sont à sa portée, sauf la page sur laquelle il a été enregistré pour la première fois. Il ne pourra contrôler cette dernière qu'une fois qu'elle sera à nouveau chargée. Une fois que le service worker a pris le contrôle, il présente un des deux états suivants : soit il est arrêté pour économiser de la mémoire, soit il traite des événements de récupération et de message qui proviennent d'une demande ou d'un message réseau effectué sur votre page.

Vous trouverez ci-dessous un schéma extrêmement simplifié du cycle de vie d'un service worker lors de sa première installation.

Les service workers nous obligent-ils à repenser notre manière de structurer nos applications ?

Les service workers entraînent quelques modifications subtiles dans l'architecture des applications. Au lieu de regrouper toute votre application dans une chaîne HTML, il peut être préférable d'opter pour une construction de style AJAX. De cette manière, vous disposez d'un shell (qui est en permanence mis en cache et peut toujours redémarrer sans le réseau) et d'un contenu qui est actualisé régulièrement et géré séparément.

Les implications de cette division sont diverses. Lors de la première visite, vous pouvez afficher du contenu sur le serveur et installer le service worker sur le client. Lors des visites suivantes, vous n'avez qu'à demander des données.

Ces informations vous-ont elles été utiles ?
Comment pouvons-nous l'améliorer ?