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.
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-ils 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 le nettoyage de la 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 entraîne une expérience utilisateur médiocre.
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 à transférer les opérations vers des threads supplémentaires. En fait, dans les dernières versions d'Android, le blocage du thread principal pendant trop longtemps cause un plantage de l'application.
Sur le Web, JavaScript a été conçu autour du concept d'un seul thread et ne dispose pas des fonctionnalités nécessaires pour implémenter un modèle multithread comme celui des applications, comme 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 en arrière-plan, ce qui leur permet d'effectuer des tâches sans interférer avec le thread principal. Les nœuds de calcul sont un champ d'application JavaScript complet exécuté sur un thread distinct, sans mémoire partagée.
Dans cet article, vous allez découvrir deux types de workers différents (web workers et service workers), leurs similitudes et leurs différences, ainsi que les modèles les plus courants pour les utiliser dans des sites Web de production.
Scripts Web Worker et service worker
Similitudes
Les nœuds de calcul Web et les nœuds de calcul de service sont deux types de nœuds de calcul disponibles pour les sites Web. Ils présentent certains points communs:
- Les deux s'exécutent dans un thread secondaire, ce qui permet au code JavaScript d'être exécuté sans bloquer le thread principal et l'interface utilisateur.
- Ils n'ont pas accès aux objets
WindowetDocument. Ils ne peuvent donc pas interagir directement avec le DOM et leur accès aux API du navigateur est limité.
Différences
On pourrait penser que la plupart des tâches pouvant être déléguées à un worker Web peuvent être effectuées dans un worker de service et inversement, mais il existe des différences importantes entre eux:
- 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énementpush). - 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 nœud de travail Web est étroitement liée à l'onglet auquel il appartient, tandis que le cycle de vie du nœud de travail de service en est indépendant. C'est pourquoi fermer l'onglet dans lequel un worker Web s'exécute le met fin, tandis qu'un service worker peut continuer à s'exécuter en arrière-plan, même lorsque le site n'a pas d'onglets actifs ouverts.
Cas d'utilisation
Les différences entre les deux types de workers suggèrent dans quelles situations vous pouvez utiliser l'un ou l'autre:
Les cas d'utilisation des web workers sont plus couramment liés au transfert de tâches (telles que 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 s'occuper de l'entrée utilisateur et des animations. Pour ce faire, ils ont utilisé des web workers pour exécuter la logique de jeu et la maintenance de l'état sur un thread distinct.
Les tâches de service worker sont généralement plus liées à l'action en tant que proxy réseau, à la gestion des tâches en arrière-plan, et à des éléments tels que le cache et la mise 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 peuvent être utilisés à cette fin. Ainsi, si l'utilisateur ferme l'onglet pendant le téléchargement de l'épisode, la tâche n'a pas besoin d'être interrompue.
Outils et bibliothèques
La communication entre les fenêtres et les workers peut être implémentée à l'aide de différentes API de niveau inférieur. Heureusement, il existe des bibliothèques qui abstraient ce processus et gèrent les cas d'utilisation les plus courants. Dans cette section, nous allons en aborder deux qui gèrent respectivement les fenêtres vers les nœuds de calcul Web et les nœuds de calcul de service: 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 qui utilisent 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 sur cette page.
Workbox
Workbox est une bibliothèque populaire permettant de créer des sites Web qui utilisent des services workers. Il regroupe un ensemble de bonnes pratiques concernant le cache, la mise en cache 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 les fenêtres et les services workers:
- Guide de mise en cache impérative: appel d'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: appel de la page à partir du service worker pour informer de mises à jour importantes (par exemple, une nouvelle version du site Web est disponible).
- Communication bidirectionnelle: délégation d'une tâche à un service worker (par exemple, un téléchargement lourd) et mise à jour de la page sur la progression.
Pour connaître les modèles de communication entre les fenêtres et les threads de travail Web, consultez Utiliser des threads de travail Web pour exécuter JavaScript en dehors du thread principal du navigateur.