Améliorer les performances avec les Web Workers HTML

Le problème du thread principal en JavaScript

Par défaut, le JavaScript exécuté dans un navigateur est single-threaded (à fil d’exécution unique). Cela signifie qu’il ne peut effectuer qu’une seule tâche à la fois sur ce qu’on appelle le thread principal (main thread).

Ce thread principal a une double responsabilité : il exécute votre code JavaScript, mais il gère également les interactions de l’utilisateur (clics, défilement) et le rendu visuel de la page HTML. Par conséquent, si vous lancez une opération très gourmande en ressources (comme un calcul mathématique complexe, le traitement d’une grande image ou le filtrage d’un tableau massif), le thread principal est monopolisé.

Le résultat ? L’interface utilisateur se fige. Les boutons ne répondent plus et les animations saccadent. C’est ici qu’intervient une fonctionnalité majeure pour l’optimisation navigateur : les Web Workers.

Qu’est-ce qu’un Web Worker HTML ?

Introduits avec HTML5, les Web Workers HTML permettent d’exécuter des scripts dans des threads séparés, indépendants du thread principal. Ils offrent une véritable solution de traitement arrière-plan.

Grâce à eux, vous pouvez déléguer les tâches lourdes à un autre processus. Le thread principal reste ainsi libre de gérer l’interface graphique de manière fluide, tandis que le Worker effectue le travail difficile en silence. Bien qu’ils relèvent du JavaScript asynchrone dans leur mode de communication, les Workers exécutent le code de manière synchrone dans leur propre espace.

Créer et utiliser un Web Worker (Tutoriel)

La mise en place d’un Web Worker nécessite toujours au moins deux fichiers distincts :

• Le fichier JavaScript principal (lié à votre page HTML).
• Le fichier JavaScript dédié au Worker.

1. Préparer le script du Worker

Créons d’abord le fichier qui s’exécutera en arrière-plan. Nommons-le worker.js. Pour communiquer avec le script principal, le Worker écoute les messages entrants via l’événement onmessage et répond avec la fonction postMessage().

// Fichier : worker.js

// On écoute les messages envoyés par le script principal
self.onmessage = function(evenement) {
    const donnees = evenement.data;
    console.log("Données reçues dans le Worker :", donnees);

    // Simulation d'un calcul lourd
    let resultat = 0;
    for (let i = 0; i < 1000000000; i++) {
        resultat += i;
    }

    // On renvoie le résultat au script principal
    self.postMessage(resultat);
};

2. Initialiser le Worker dans le script principal

Dans votre fichier JavaScript principal (par exemple main.js), vous devez instancier le Worker en lui passant le chemin vers son fichier, puis configurer l’envoi et la réception des données.

// Fichier : main.js

// Vérifier si le navigateur supporte les Web Workers
if (window.Worker) {
    // 1. Instanciation du Worker
    const monWorker = new Worker('worker.js');

    // 2. Écouter les réponses du Worker
    monWorker.onmessage = function(evenement) {
        console.log("Résultat calculé par le Worker :", evenement.data);
    };

    // 3. Envoyer un message pour démarrer le travail
    console.log("Envoi du message au Worker...");
    monWorker.postMessage("Démarre le calcul");
} else {
    console.error("Votre navigateur ne supporte pas les Web Workers HTML.");
}

Dans cet exemple, l’interface utilisateur ne sera pas bloquée pendant que la boucle d’un milliard d’itérations s’exécute dans worker.js.

Gérer les erreurs et arrêter un Worker

Il est crucial de gérer le cycle de vie de vos Workers pour éviter les fuites de mémoire. Un Worker continue d’exister tant qu’il n’est pas explicitement arrêté, même s’il a terminé sa tâche.

Écouter les erreurs

Vous pouvez intercepter les erreurs survenant dans le Worker grâce à l’événement onerror :

monWorker.onerror = function(erreur) {
    console.error("Erreur dans le Worker à la ligne " + erreur.lineno + " : " + erreur.message);
};

Terminer un Worker

Lorsque le Worker a terminé son travail et que vous n’en avez plus besoin, détruisez-le depuis le script principal à l’aide de la méthode terminate() :

monWorker.onmessage = function(evenement) {
    console.log("Tâche terminée :", evenement.data);
    
    // Arrêt immédiat du Worker
    monWorker.terminate();
    console.log("Worker arrêté.");
};

Il est également possible pour un Worker de s’arrêter lui-même en appelant self.close() à l’intérieur de son propre script.

Les limites des Web Workers

Bien que puissants, les Web Workers HTML possèdent des restrictions importantes liées à leur exécution dans un thread séparé :

• Aucun accès au DOM : Un Worker ne peut pas manipuler les éléments HTML de la page (pas de document.getElementById).
• Pas d’accès à l’objet Window : Des objets globaux comme window ne sont pas disponibles.
• Politique de même origine (CORS) : Le fichier JavaScript du Worker doit être hébergé sur le même domaine que la page web. Vous ne pouvez pas charger un Worker depuis une URL externe.
• Communication par copie : Les données échangées via postMessage sont copiées, et non partagées en mémoire. L’envoi d’objets extrêmement volumineux peut donc prendre un peu de temps (bien qu’il existe des solutions avancées comme les Transferable Objects).

Bonnes pratiques

Pour tirer le meilleur parti de cette technologie, réservez les Workers aux véritables goulots d’étranglement de votre application :

• Analyse de gros fichiers (comme des CSV ou des JSON massifs).
• Traitement d’images ou de vidéos côté client.
• Calculs cryptographiques ou mathématiques complexes.

N’utilisez pas un Worker pour de simples requêtes API ou des opérations rapides, car le temps de création du Worker et l’échange de messages pourraient s’avérer plus coûteux que l’opération elle-même.