Les service workers sont extrêmement pratiques, mais il peut être difficile de les utiliser dans un premier temps. Workbox facilite l'utilisation des service workers. Cependant, comme les service workers résolvent des problèmes complexes, toute abstraction de cette technologie sera également délicate s'il ne la comprend pas. Ainsi, ces premiers extraits de la documentation couvriront la technologie sous-jacente avant d'aborder les spécificités de Workbox.
Pour afficher la liste en cours des service workers, saisissez chrome://serviceworker-internals/ dans votre barre d'adresse.
Que fournissent les service workers ?
Les service workers sont des éléments JavaScript spécialisés qui servent de proxys entre les navigateurs et les serveurs Web. Elles visent à améliorer la fiabilité en offrant un accès hors connexion et à booster les performances des pages.
Un cycle de vie semblable à celui d'une application qui s'améliore progressivement
Les service workers constituent une amélioration des sites Web existants. Cela signifie que si des utilisateurs de navigateurs non compatibles avec les service workers visitent des sites Web qui les utilisent, aucune fonctionnalité de référence n'est défaillante. C'est à cela que sert le Web.
Les service workers améliorent progressivement les sites Web tout au long d'un cycle de vie semblable à celui des applications spécifiques à la plate-forme. Réfléchissez à ce qui se passe lorsqu'une application native est installée depuis une plate-forme de téléchargement d'applications:
- Une requête est envoyée pour télécharger l'application.
- L'application est téléchargée et installée.
- L'application est prête à l'emploi et peut être lancée.
- L'application est mise à jour pour les nouvelles versions.
Le cycle de vie d'un service worker est similaire, mais avec une approche d'amélioration progressive. Lors de la toute première visite d'une page Web qui installe un nouveau service worker, la première visite sur une page fournit ses fonctionnalités de base pendant le téléchargement du service worker. Une fois qu'un service worker est installé et activé, il contrôle la page afin d'améliorer la fiabilité et la vitesse.
Accès à une API de mise en cache basée sur JavaScript
L'interface Cache est un aspect indispensable de la technologie des service workers. Il s'agit d'un mécanisme de mise en cache entièrement distinct du cache HTTP.
L'interface Cache est accessible dans le champ d'application du service worker et du thread principal.
Cela offre de nombreuses possibilités pour les interactions pilotées par l'utilisateur avec une instance Cache.
Alors que le cache HTTP est influencé par les instructions de mise en cache spécifiées dans les en-têtes HTTP, l'interface Cache est programmable via JavaScript.
Cela signifie que la mise en cache des réponses aux requêtes réseau peut être basée sur la logique la plus adaptée pour un site Web donné.
Exemple :
- Stockez les éléments statiques dans le cache lors de la première requête correspondante et ne les diffusez qu'à partir du cache pour chaque requête suivante.
- Stockez le balisage de la page dans le cache, mais ne le diffusez qu'à partir du cache dans les scénarios hors connexion.
- Diffuser des réponses obsolètes pour certains éléments à partir du cache, mais les mettre à jour à partir du réseau en arrière-plan.
- Diffusez du contenu partiel à partir du réseau et assemblez-le avec un shell d'application à partir du cache afin d'améliorer les performances perceptives.
Chacune de ces options est un exemple de stratégie de mise en cache. Les stratégies de mise en cache permettent d'offrir des expériences hors connexion et peuvent améliorer les performances en évitant les vérifications de revalidation à latence élevée effectuées lors du lancement du cache HTTP. Avant de nous plonger dans Workbox, nous passerons en revue quelques stratégies de mise en cache et le code permettant de les faire fonctionner.
API asynchrone et basée sur des événements
Le transfert de données sur le réseau est par nature asynchrone. Il faut du temps pour demander un élément, qu'un serveur réponde à cette requête et que la réponse soit téléchargée. Les délais sont variables et indéterminés. Les service workers gèrent cette asynchronisme via une API basée sur des événements, à l'aide de rappels pour des événements tels que:
- Lorsqu'un service worker est en cours d'installation.
- Lorsqu'un service worker est en cours d'activation.
- Lorsqu'un service worker détecte une requête réseau.
Les événements peuvent être enregistrés à l'aide d'une API addEventListener que vous connaissez déjà.
Tous ces événements peuvent potentiellement interagir avec l'interface Cache.
En particulier, la possibilité d'exécuter des rappels lorsque des requêtes réseau sont distribuées est essentielle pour offrir la fiabilité et la rapidité recherchées.
L'exécution de tâches asynchrones en JavaScript implique l'utilisation de promesses.
Comme les promesses sont également à la base de async et await, ces fonctionnalités JavaScript peuvent également être utilisées pour simplifier le code des service workers (et de Workbox) et améliorer l'expérience développeur.
Mise en cache préalable et mise en cache de l'environnement d'exécution
L'interaction entre un service worker et une instance Cache implique deux concepts de mise en cache distincts : la mise en cache préalable et la mise en cache de l'environnement d'exécution.
Chacun de ces éléments est au cœur des avantages qu'un service worker peut offrir.
La mise en cache préalable est le processus de mise en cache des éléments à l'avance, généralement pendant l'installation d'un service worker.
Avec la mise en cache préalable, les éléments statiques clés et les matériaux nécessaires à l'accès hors connexion peuvent être téléchargés et stockés dans une instance Cache.
Ce type de mise en cache améliore également la vitesse de chargement des pages suivantes, qui nécessitent des éléments en pré-cache.
On parle de mise en cache pendant l'exécution lorsqu'une stratégie de mise en cache est appliquée aux éléments lorsqu'ils sont demandés au réseau pendant l'exécution. Ce type de mise en cache est utile, car il garantit un accès hors connexion aux pages et aux éléments que l'utilisateur a déjà consultés.
Lorsqu'elles sont combinées, ces approches d'utilisation de l'interface Cache dans un service worker offrent des avantages considérables pour l'expérience utilisateur et offrent des comportements semblables à ceux d'une application sur des pages Web autrement ordinaires.
Isolation du thread principal
L'état des performances JavaScript est un défi en constante évolution pour le Web. Du point de vue de l'utilisateur, il dépend des capacités de l'appareil et de l'accès à l'Internet haut débit. Plus vous utilisez JavaScript, plus il devient difficile de créer des sites Web rapides offrant des expériences utilisateur agréables.
Les service workers sont comme des web workers, dans la mesure où toutes leurs tâches sont effectuées sur leurs propres threads. Cela signifie que les tâches des service workers ne sont pas en concurrence pour attirer l'attention avec d'autres tâches du thread principal. Les service workers sont conçus pour donner la priorité à l'utilisateur.
La voie à suivre
Cette documentation n'est qu'un aperçu. Avant d'aborder Workbox correctement, vous devez aborder d'autres sujets concernant les service workers, mais ne vous inquiétez pas: grâce à une solide compréhension des service workers, l'utilisation de Workbox s'avère plus simple et plus productive.