Summary

  • Le W3C a publié le premier projet Web Workers le 23 avril 2009. Une page pouvait lancer un script dans un environnement parallèle distinct et échanger avec lui par messages.
  • Dans l’exemple des nombres premiers, un worker effectue le calcul et envoie les résultats successifs à la page, qui les affiche tout en continuant à traiter les interactions.

Il suffit parfois d’un petit bouton pour juger une grande architecture. Vous cliquez. Rien. Vous recliquez. La page semble avoir pris votre demande en otage pendant qu’elle accomplit un calcul. Quelques secondes plus tard, tout se met à bouger d’un seul coup, comme un employé qui revient de pause avec une pile de dossiers et affirme qu’il était là depuis le début.

Le premier projet Web Workers publié par le W3C le 23 avril 2009 voulait casser cette file d’attente. Son champ d’application décrit des scripts exécutés en arrière-plan, indépendamment de ceux qui répondent aux clics et aux autres gestes. L’exemple choisi calcule des nombres premiers. Le document principal démarre un worker ; celui-ci cherche le nombre suivant et l’envoie ; la page l’affiche. Le guichet peut accueillir le lecteur pendant que le bureau du fond fait ses additions.

La nouvelle organisation tient dans une adresse et un échange. La page crée un Worker à partir de l’URL d’un script. Le navigateur exécute ce script dans un environnement parallèle séparé. Les deux côtés communiquent avec postMessage et des gestionnaires de messages. Le worker s’occupe du calcul, la page garde l’interface. Pour afficher le dernier nombre premier, le résultat traverse cette frontière et le code de la page modifie le texte visible. Chaque acteur a un travail précis.

Le projet de décembre 2009 parlait d’un fonctionnement comparable à des fils d’exécution, coordonné par l’envoi de messages. Cette poste intérieure impose une discipline utile. La page formule une tâche, le worker rapporte une valeur, puis la page décide ce que le lecteur voit. Si le lecteur a changé de demande entre-temps, l’arrivée tardive du résultat devient une question de l’interface. Le calcul n’obtient pas le droit de redécorer l’écran simplement parce qu’il a travaillé dur.

Pourquoi des nombres premiers ? Parce qu’ils n’ont aucune excuse pour bloquer un bouton. L’exemple isole le coût d’un calcul effectué au mauvais endroit. Il n’y a ni serveur distant ni réseau capricieux à accuser. Un programme occupe le temps dont la page avait besoin pour répondre. Déplacer la boucle dans un worker permet à l’interface de continuer à écouter, puis de montrer le nouveau nombre dès qu’un message arrive. Le lecteur voit progresser le travail sans devoir deviner si le navigateur a quitté la pièce.

La solution avait ses frais généraux. Le texte de décembre 2009 avertissait que les workers étaient relativement lourds : démarrage et mémoire coûtaient. Il donnait un contre-exemple délicieux, lancer un worker pour chacun des pixels d’une image de quatre mégapixels. Quatre millions de petits employés ne forment pas une équipe efficace ; ils forment une réunion qui a avalé l’ordinateur. Le bon grain de travail comptait autant que la possibilité de travailler en parallèle.

Les versions suivantes ont précisé les formes de collaboration. L’instantané candidat de 2012 distinguait workers dédiés et workers partagés. Le premier échange avec son créateur par un canal implicite. Le second accepte plusieurs connexions d’une même origine grâce à des ports. Le projet de 2015 détaillait la création de Worker, onmessage, postMessage et le MessagePort explicite d’un worker partagé. À chaque type d’aide son adresse de retour.

Un worker déplace l’exécution ; le rangement des données pose une autre question. Une page peut garder un choix dans le stockage de son origine et demander à un worker de calculer quelque chose à partir de ce choix. Le message fait le lien entre ces deux tâches. Le navigateur sait où tourne le calcul ; l’application sait quel résultat mérite de revenir à l’écran. Cette répartition a transformé une longue opération en échange suivi plutôt qu’en silence imposé au lecteur.

L’historique officiel du W3C relie le premier projet de 2009 aux étapes de 2012 et 2015. Son calcul de nombres premiers reste la meilleure carte de visite du dispositif : l’atelier peut travailler longtemps, le guichet peut continuer à recevoir du monde, et les nouvelles passent par une porte identifiée.