Présentation des nœuds de calcul

Comment les web workers et les service workers peuvent améliorer les performances de votre site, et quand utiliser un web worker plutôt qu'un service worker.

Andrew Guan

Demián Renzulli

Cette présentation explique comment les web workers et les service workers peuvent améliorer les performances de votre site Web, et quand utiliser un web worker plutôt qu'un service worker. Consultez le reste de cette série pour découvrir des modèles spécifiques de communication entre les fenêtres et les service workers.

Comment les travailleurs peuvent améliorer votre site Web

Le navigateur utilise un seul thread (le thread principal) pour exécuter tout le code JavaScript d'une page Web, ainsi que pour effectuer des tâches telles que l'affichage de la page et la récupération de mémoire. L'exécution d'un code JavaScript excessif peut bloquer le thread principal, ce qui retarde l'exécution de ces tâches par le navigateur et nuit à l'expérience utilisateur.

Dans le développement d'applications iOS/Android, un modèle courant pour s'assurer que le thread principal de l'application reste libre de répondre aux événements utilisateur consiste à décharger les opérations sur des threads supplémentaires. En fait, dans les dernières versions d'Android, le blocage du thread principal pendant trop longtemps entraîne le plantage de l'application.

Sur le Web, JavaScript a été conçu autour du concept de thread unique et ne dispose pas des fonctionnalités nécessaires pour implémenter un modèle multithread comme celui des applications, tel que la mémoire partagée.

Malgré ces limites, un modèle similaire peut être obtenu sur le Web en utilisant des workers pour exécuter des scripts dans des threads d'arrière-plan, ce qui leur permet d'effectuer des tâches sans interférer avec le thread principal. Les workers sont un champ d'application JavaScript complet s'exécutant sur un thread distinct, sans mémoire partagée.

Dans cet article, vous allez découvrir deux types de workers (les Web Workers et les service workers), leurs similitudes et leurs différences, ainsi que les modèles les plus courants pour les utiliser sur des sites Web en production.

Scripts Web Worker et service workers

Similitudes

Les web workers et les service workers sont deux types de workers disponibles pour les sites Web. Ils ont quelques points communs :

• Tous deux s'exécutent dans un thread secondaire, ce qui permet d'exécuter du code JavaScript sans bloquer le thread principal ni l'interface utilisateur.
• Ils n'ont pas accès aux objets Window et Document. Ils ne peuvent donc pas interagir directement avec le DOM et ont un accès limité aux API du navigateur.

Différences

On pourrait penser que la plupart des tâches pouvant être déléguées à un Web Worker peuvent être effectuées dans un service worker et inversement, mais il existe des différences importantes entre les deux :

• Contrairement aux web workers, les service workers vous permettent d'intercepter les requêtes réseau (via l'événement fetch) et d'écouter les événements de l'API Push en arrière-plan (via l'événement push).
• Une page peut générer plusieurs Web Workers, mais un seul service worker contrôle tous les onglets actifs dans le champ d'application avec lequel il a été enregistré.
• La durée de vie du web worker est étroitement liée à l'onglet auquel il appartient, tandis que le cycle de vie du service worker en est indépendant. C'est pourquoi la fermeture de l'onglet dans lequel un web worker est exécuté l'arrête, tandis qu'un service worker peut continuer à s'exécuter en arrière-plan, même si le site n'a pas d'onglet actif ouvert.

Remarque : Pour les tâches relativement courtes, comme l'envoi d'un message, le navigateur ne mettra probablement pas fin à un service worker lorsqu'il n'y a pas d'onglets actifs. Toutefois, si la tâche prend trop de temps, le navigateur mettra fin au service worker, sinon cela risque de compromettre la confidentialité et la batterie de l'utilisateur. Des API telles que Background Fetch, qui peuvent vous permettre d'éviter l'arrêt du service worker.

Cas d'utilisation

Les différences entre les deux types de nœuds de calcul suggèrent dans quelles situations vous pouvez utiliser l'un ou l'autre :

Les cas d'utilisation des web workers sont plus souvent liés au déchargement du travail (comme les calculs lourds) vers un thread secondaire, afin d'éviter de bloquer l'UI.

• Exemple : L'équipe qui a créé le jeu vidéo PROXX souhaitait laisser le thread principal aussi libre que possible pour gérer les entrées utilisateur et les animations. Pour ce faire, ils ont utilisé des Web Workers afin d'exécuter la logique du jeu et la maintenance de l'état sur un thread distinct.

Les tâches des service workers sont généralement plus liées au rôle de proxy réseau, à la gestion des tâches en arrière-plan, ainsi qu'à la mise en cache et au mode hors connexion.

Exemple : Dans une PWA de podcast, vous pouvez autoriser les utilisateurs à télécharger des épisodes complets pour les écouter hors connexion. Un service worker, et en particulier l'API Background Fetch, peut être utilisé à cette fin. Ainsi, si l'utilisateur ferme l'onglet pendant le téléchargement de l'épisode, la tâche ne sera pas interrompue.

L'UI est mise à jour pour indiquer la progression d'un téléchargement (à gauche). Grâce aux service workers, l'opération peut continuer à s'exécuter lorsque tous les onglets ont été fermés (à droite).

Outils et bibliothèques

La communication entre la fenêtre et le worker peut être implémentée à l'aide de différentes API de niveau inférieur. Heureusement, il existe des bibliothèques qui simplifient ce processus en prenant en charge les cas d'utilisation les plus courants. Dans cette section, nous allons aborder deux d'entre elles qui gèrent respectivement les Web Workers et les Service Workers : Comlink et Workbox.

Comlink

Comlink est une petite bibliothèque RPC (1,6 ko) qui gère de nombreux détails sous-jacents lors de la création de sites Web utilisant des Web Workers. Il a été utilisé sur des sites Web tels que PROXX et Squoosh. Vous trouverez un résumé de ses motivations et des exemples de code ici.

Workbox

Workbox est une bibliothèque populaire permettant de créer des sites Web qui utilisent des service workers. Il regroupe un ensemble de bonnes pratiques concernant la mise en cache, le mode hors connexion, la synchronisation en arrière-plan, etc. Le module workbox-window permet d'échanger facilement des messages entre le service worker et la page.

Étapes suivantes

Le reste de cette série se concentre sur les modèles de communication entre la fenêtre et le service worker :

• Guide de mise en cache impérative : appeler un service worker à partir de la page pour mettre en cache les ressources à l'avance (par exemple, dans les scénarios de préchargement).
• Diffuser des mises à jour : appeler la page depuis le service worker pour informer l'utilisateur de mises à jour importantes (par exemple, une nouvelle version du site Web est disponible).
• Communication bidirectionnelle : déléguer une tâche à un service worker (par exemple, un téléchargement lourd) et tenir la page informée de la progression.

Pour connaître les modèles de communication entre les fenêtres et les Web Workers, consultez Utiliser des Web Workers pour exécuter JavaScript en dehors du thread principal du navigateur.