Web Workers : définition, cas d'usage, exemples

Qu'est-ce qu'un Web Worker ?

Un Web Worker est un fichier JavaScript que le navigateur exécute dans un thread d'arrière-plan, distinct du thread principal chargé du rendu et des saisies de l'utilisateur. MDN le décrit comme un moyen d'exécuter des scripts dans des threads d'arrière-plan sans gêner l'interface utilisateur. Y déplacer le travail lourd garde la page réactive, ce qui aide des indicateurs comme l'Interaction to Next Paint (INP).

Comment fonctionnent les Web Workers

La page crée un worker avec new Worker("worker.js"). Les deux côtés ne partagent aucune variable : ils communiquent en envoyant des messages avec postMessage et en les recevant dans l'événement message. Un worker n'a pas accès au DOM ni aux objets de la page, il ne peut donc pas modifier ce que voit l'utilisateur. Il renvoie des résultats et le thread principal met la page à jour.

// main.js
const worker = new Worker('worker.js');
worker.postMessage({ rows: largeArray });
worker.addEventListener('message', (event) => {
  console.log('Result:', event.data);
});

// worker.js
self.addEventListener('message', (event) => {
  const result = expensiveCompute(event.data.rows);
  self.postMessage(result);
});

Les types de workers

Ce qu'un worker peut et ne peut pas faire

Les workers peuvent utiliser fetch, les WebSockets, IndexedDB et les minuteries, et charger des scripts avec importScripts(). Ils ne peuvent pas manipuler le DOM ni utiliser certaines parties de window ; utilisez self à la place. localStorage est une fonctionnalité de window et n'est pas exposé dans les workers : utilisez IndexedDB pour stocker des données. Consultez le guide MDN sur les web workers et sa liste des fonctions disponibles avant de compter sur une API.

Quand un Web Worker vaut la peine

• Les tâches longues. Selon web.dev, une tâche qui s'exécute plus de 50 ms sur le thread principal est une tâche longue. Le travail qui franchit régulièrement ce seuil est un candidat.
• Analyser et transformer de gros volumes de données, comme de gros fichiers JSON, CSV ou XML.
• La cryptographie et le hachage qui figeraient sinon l'interface.
• Le traitement d'images, de sons et de documents, par exemple redimensionner, compresser ou faire de l'OCR.
• Les récupérations et synchronisations en arrière-plan pendant que l'utilisateur continue de travailler.

Transmettre les données efficacement

Par défaut, les messages sont copiés par clonage structuré. Pour de grosses charges, cette copie est le vrai coût. Les objets transférables, comme un ArrayBuffer, passent de l'autre côté par un transfert sans copie, et l'original devient inutilisable :

const bytes = new Uint8Array(1024 * 1024 * 32);
worker.postMessage(bytes.buffer, [bytes.buffer]);

SharedArrayBuffer permet aux threads d'utiliser la même mémoire, mais MDN signale des problèmes de déterminisme, de sécurité et de performance : ne l'utilisez que si nécessaire. Quand un worker a terminé, appelez worker.terminate() depuis le thread principal pour l'arrêter immédiatement.

Exemple : un import CSV qui saccade

Un tableau de bord analyse un gros CSV quand l'utilisateur le dépose sur la page. Sur le thread principal, la page se fige pendant plusieurs secondes, les clics s'accumulent et l'INP est mauvais. En déplaçant l'analyseur dans un worker et en renvoyant les données par blocs, l'interface reste fluide et vous pouvez afficher une barre de progression. L'analyse prend le même temps, mais l'utilisateur peut continuer à interagir pendant qu'elle tourne.

Erreurs fréquentes

• Envoyer sans cesse de gros objets. Le clonage coûte du temps et de la mémoire. Transférez des buffers ou envoyez des blocs plus petits.
• Toucher au DOM depuis le worker. Cela lève une erreur. Renvoyez des données et mettez la page à jour dans le thread principal.
• Créer un worker à chaque clic. Le démarrage a un coût. Réutilisez un worker ou un petit pool.
• Oublier de les terminer. Les workers inactifs gardent de la mémoire. Appelez terminate() ou laissez le worker se fermer lui-même.
• Ajouter un worker pour de minuscules tâches. Sous le seuil de tâche longue, le coût des messages dépasse en général le gain.
• Ignorer les erreurs. Écoutez l'événement error du worker, sinon les échecs passent inaperçus.

Web Workers, tests de performance et supervision

Les workers améliorent la réactivité du front-end, alors mesurez-la. web.dev décrit le Total Blocking Time (TBT) comme une métrique de laboratoire qui va souvent de pair avec un INP bas, et recommande de rester sous 200 ms sur un mobile moyen. L'INP est une métrique de terrain : web.dev juge bon un résultat de 200 ms ou moins au 75e percentile. La supervision de la vitesse de page de LoadFocus exécute Lighthouse depuis plusieurs lieux pour suivre les résultats de laboratoire dans le temps, et le vérificateur de Core Web Vitals gratuit affiche l'INP d'utilisateurs réels à partir des données du Chrome UX Report, sans inscription. Pour le contexte, voir les Core Web Vitals et mastering JavaScript for performance (en anglais). Les tests de charge, eux, sollicitent vos serveurs ; ils ne révèlent pas le blocage du thread principal dans le navigateur.

Questions fréquentes sur les Web Workers

Quelle différence entre un Web Worker et un Service Worker ?

Un Web Worker exécute du JavaScript général en arrière-plan pour une page. Un service worker se place entre la page et le réseau et gère le cache, le hors-ligne, les notifications push et la synchronisation en arrière-plan.

Un Web Worker peut-il accéder au DOM ?

Non. Les workers s'exécutent dans leur propre contexte, sans DOM. Ils envoient leurs résultats avec postMessage et le thread principal met la page à jour.

Les Web Workers rendent-ils le code plus rapide ?

Pas à eux seuls. Le calcul prend à peu près le même temps, mais il ne bloque plus l'interface. Répartir le travail sur plusieurs workers peut aussi le terminer plus tôt sur les appareils multicœurs.

Comment les workers partagent-ils des données ?

Par échange de messages, qui copie les données, par transfert d'objets comme un ArrayBuffer, ou avec un SharedArrayBuffer quand ses exigences de sécurité sont remplies.

Ai-je besoin d'un Web Worker pour mon application ?

Seulement si un travail gourmand en processeur bloque le thread principal. La plupart des pages n'en ont pas besoin ; celles qui en ont besoin y gagnent nettement en réactivité.