Présentation de Service Worker

Les service workers offrent un avantage incroyable, mais leur utilisation peut être difficile au début. Workbox simplifie 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 sans la comprendre. Par conséquent, ces premiers éléments de documentation couvrent cette technologie sous-jacente avant d'entrer dans les caractéristiques spécifiques aux boîtes de travail.

Pour afficher la liste des service workers en cours d'exécution, saisissez chrome://serviceworker-internals/ dans la barre d'adresse.

Liste en cours d'exécution de service workers.

Que fournissent les service workers ?

Les service workers sont des ressources JavaScript spécialisées qui agissent comme des proxys entre les navigateurs et les serveurs Web. Elles visent à améliorer la fiabilité en fournissant un accès hors connexion, ainsi qu'à booster les performances des pages.

Un cycle de vie de type application qui s'améliore progressivement

Les service workers permettent d'améliorer les sites Web existants. Cela signifie que si des utilisateurs de navigateurs non compatibles avec les service workers consultent des sites Web qui les utilisent, aucune fonctionnalité de base n'est défaillante. C’est ce qu’est le Web.

Les service workers améliorent progressivement les sites Web tout au long de leur cycle de vie, comme pour les applications spécifiques à une plate-forme. Pensez à 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 effectué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 sur une page Web qui installe un nouveau service worker, la première visite d'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 pour améliorer la fiabilité et la vitesse.

Accès à une API de mise en cache basée sur JavaScript

L'interface Cache, qui est un mécanisme de mise en cache entièrement distinct du cache HTTP, est un aspect indispensable de la technologie de service worker. L'interface Cache est accessible dans le champ d'application du service worker et dans le champ d'application du thread principal. Cela ouvre de nombreuses possibilités d'interactions basées sur l'utilisateur avec une instance Cache.

Alors que le cache HTTP est influencé par des 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 à un site Web donné. Exemple :

  • Stockez les éléments statiques dans le cache lors de la première requête les concernant et ne les diffusez à partir du cache que pour chaque requête suivante.
  • Stocker le balisage de la page dans le cache, mais ne diffuser le balisage du cache qu'en cas de connexion hors connexion.
  • Diffusion de réponses obsolètes pour certains éléments du cache, mais mettez-les à jour à partir du réseau en arrière-plan.
  • Diffusez du contenu partiel depuis le réseau et assemblez-le avec un shell d'application à partir du cache pour améliorer les performances perceptuelles.

Chacune d'entre elles est un exemple de stratégie de mise en cache. Les stratégies de mise en cache rendent possibles les expériences hors connexion et peuvent offrir de meilleures performances en ignorant les vérifications de revalidation à latence élevée lors du lancement du cache HTTP. Avant de vous plonger dans Workbox, nous examinerons quelques stratégies de mise en cache et le code permettant de les mettre en cache.

Une API asynchrone 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, pour qu'un serveur réponde à cette requête et pour télécharger la réponse. Le temps nécessaire est variable et indéterminée. Les service workers gèrent cette asynchronisité via une API basée sur les événements, à l'aide de rappels pour des événements tels que:

Les événements peuvent être enregistrés à l'aide d'une API addEventListener familière. Tous ces événements peuvent potentiellement interagir avec l'interface Cache. Plus particulièrement, la possibilité d'exécuter des rappels lors de l'envoi de requêtes réseau est essentielle pour assurer la fiabilité et la rapidité recherchées.

Le travail asynchrone dans JavaScript implique l'utilisation de promesses. Étant donné que les promesses sont également sous-jacentes à async et await, ces fonctionnalités JavaScript peuvent également être utilisées pour simplifier le code des service workers (et Workbox) et offrir ainsi une meilleure expérience aux développeurs.

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 prémise en cache et la mise en cache au moment de l'exécution. Chacun de ces avantages est au cœur des avantages qu'un service worker peut offrir.

La mise en cache est le processus de mise en cache des éléments à l'avance, généralement lors de l'installation d'un service worker. Avec la mise en cache préalable, les principaux éléments statiques et matériels nécessaires pour un 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 des pages suivantes qui nécessitent les éléments en pré-mise en 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 méthodes d'utilisation de l'interface Cache dans un service worker offrent un avantage considérable en termes d'expérience utilisateur et permettent d'utiliser 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 des appareils et de l'accès à une connexion Internet haut débit. Plus il est utilisé, plus il devient difficile de créer des sites Web rapides offrant une expérience utilisateur agréable.

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 du service worker ne seront pas mises en concurrence avec d'autres tâches du thread principal. Les service workers sont conçus pour donner la priorité à l'utilisateur.

Un projet d'avenir

Cette documentation n'est qu'un aperçu. Vous devez aborder d'autres sujets concernant les service workers avant de parler de Workbox, mais rassurez-vous: avec une solide compréhension des service workers, l'utilisation de Workbox sera plus simple et plus productive.