Découvrez comment les Web workers et les service workers peuvent améliorer les performances de votre site, et quand utiliser un service 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 les utiliser plutôt qu'un service worker. Consultez le reste de cette série pour connaître les modèles spécifiques de communication entre fenêtre et service worker.
Comment les collaborateurs 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 excessive de code JavaScript peut bloquer le thread principal, ce qui peut retarder l'exécution de ces tâches par le navigateur et nuire à 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 disponible pour 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 d'un seul thread et ne dispose pas des fonctionnalités nécessaires pour implémenter un modèle de traitement 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 nœuds de calcul 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 représentent un champ d'application JavaScript entier s'exécutant 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 de leur utilisation dans des sites Web de production.
Les Web workers et service workers
Points communs
Les web workers et les service workers sont deux types de workers disponibles pour les sites Web. Ils ont des points communs:
- Tous deux s'exécutent dans un thread secondaire, ce qui permet au code JavaScript de s'exécuter 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 disposent d'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 nœud de calcul Web peuvent être effectuées dans un service worker et inversement, mais il existe des différences importantes entre elles:
- 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 workers Web, 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 calcul Web est étroitement liée à l'onglet auquel il appartient, tandis que son cycle de vie en est indépendant. Pour cette raison, la fermeture de l'onglet où un nœud de calcul est en cours d'exécution met fin à l'opération. En revanche, un service worker peut continuer à s'exécuter en arrière-plan, même si aucun onglet actif n'est ouvert sur le site.
Cas d'utilisation
Les différences entre les deux types de nœuds de calcul suggèrent dans quelles situations il peut être utile d'utiliser l'un ou l'autre:
Les cas d'utilisation des workers Web sont plus souvent liés au déchargement des tâches (comme les calculs lourds) vers un thread secondaire, pour é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 se charger des entrées utilisateur et des animations. Pour ce faire, elle a utilisé des nœuds de calcul Web afin d'exécuter la logique de jeu et la maintenance de l'état sur un thread distinct.
Les tâches de 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 et à des éléments tels que la mise en cache et l'activité hors connexion.
Exemple:Dans une PWA de podcasts, il peut être judicieux d'autoriser les utilisateurs à télécharger des épisodes complets pour les écouter hors connexion. Un service worker, et en particulier l'API de récupération en arrière-plan, 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 nœuds de calcul peut être implémentée à l'aide de différentes API de niveau inférieur. Heureusement, certaines bibliothèques font abstraction de ce processus et s'occupent des cas d'utilisation les plus courants. Dans cette section, nous aborderons deux d'entre eux qui s'occupent respectivement de fenêtres pour les service workers et les workers Web: Comlink et Workbox.
Comlink
Comlink est une petite bibliothèque RPC (1,6 k) qui prend en charge de nombreux détails sous-jacents lors de la création de sites Web utilisant des nœuds de calcul Web. Il est utilisé dans 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 qui permet 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 constitue un moyen pratique d'échanger 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 service workers:
- 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 des scénarios de préchargement)
- Diffusez des mises à jour: appelez la page depuis le service worker pour être informé des mises à jour importantes (par exemple, une nouvelle version du site Web est disponible).
- Communication bidirectionnelle: déléguer une tâche à un service worker (un téléchargement volumineux, par exemple) et tenir la page informée de sa progression
Pour découvrir des modèles de communication entre les fenêtres et les nœuds de calcul Web, consultez la section Utiliser des workers Web pour exécuter JavaScript en dehors du thread principal du navigateur.