3,2 secondes en moyenne pour recompiler l’ensemble des scripts d’un thème WordPress après une modification mineure d’un seul fichier, avec la configuration Webpack héritée du projet — un délai suffisant pour casser la concentration à chaque sauvegarde, plusieurs dizaines de fois par heure de développement actif.
Le thème en question comptait cinq points d’entrée JavaScript distincts : le script principal du site, un script dédié à l’éditeur de blocs, un script pour le tableau de bord d’administration personnalisé, et deux scripts pour des fonctionnalités interactives spécifiques. Chaque modification, même limitée à un seul fichier, déclenchait la recompilation de l’ensemble via la configuration Webpack en place, configurée avec plusieurs chargeurs et transformations accumulés au fil des besoins successifs du projet.
Pourquoi esbuild compile aussi rapidement
esbuild est un outil de compilation JavaScript et TypeScript écrit en Go plutôt qu’en JavaScript lui-même, ce qui lui permet de tirer parti d’une exécution native et d’un parallélisme plus direct que les outils de l’écosystème Node.js traditionnel. Il n’implémente qu’un sous-ensemble volontairement restreint de fonctionnalités par rapport à des empaqueteurs plus anciens, ce qui réduit la surface de traitement pour chaque fichier compilé, au prix d’un écosystème de greffons moins étoffé.
Une configuration minimale suffisante
Pour ce thème, la configuration esbuild tient dans un script de quelques lignes, sans fichier de configuration séparé :
esbuild src/main.js src/editeur.js src/tableau-bord.js \
--bundle --minify --sourcemap \
--outdir=build/ \
--define:process.env.NODE_ENV='"production"'Pour le développement, un mode surveillance recompile automatiquement à chaque modification de fichier :
esbuild src/main.js src/editeur.js src/tableau-bord.js \
--bundle --outdir=build/ --watch --sourcemap
Cette configuration couvre déjà la majorité des besoins d’un thème WordPress classique : regroupement de plusieurs modules en un seul fichier par point d’entrée, minification pour la production, génération de fichiers de correspondance source pour faciliter le débogage dans les outils de développement du navigateur.
Mesurer le gain réel
La mesure a porté sur le temps écoulé entre la sauvegarde d’un fichier modifié et la disponibilité du fichier compilé correspondant, dans les mêmes conditions matérielles :
| Configuration | Temps de recompilation |
|---|---|
| Webpack, configuration héritée | 3,2 secondes en moyenne |
| esbuild, mode surveillance | 140 millisecondes en moyenne |
Ce gain d’un facteur supérieur à vingt s’explique en partie par la nature même d’esbuild, mais aussi par la simplification de la chaîne de transformation qu’a exigée la migration : plusieurs chargeurs Webpack accumulés au fil du temps, dont certains n’étaient plus réellement nécessaires, ont été abandonnés faute d’équivalent direct dans esbuild, ce qui a incidemment allégé le traitement appliqué à chaque fichier.
Ce qui a demandé un ajustement lors de la migration
Tout ne s’est pas transposé sans effort. Un greffon Webpack spécifique, utilisé pour générer automatiquement un fichier de métadonnées listant les dépendances de scripts enregistrées côté PHP, n’avait pas d’équivalent direct dans esbuild. Ce besoin a été couvert par un petit script séparé, exécuté après la compilation, qui analyse les fichiers de sortie et génère le fichier de métadonnées attendu par la fonction wp_register_script — une solution plus explicite, bien que demandant quelques lignes de code supplémentaires à maintenir.
Un choix qui ne convient pas à tous les projets
Ce gain de vitesse se ressent surtout sur un projet comptant plusieurs points d’entrée et des cycles de modification fréquents en phase de développement actif. Sur un thème plus simple, avec un seul point d’entrée et des modifications peu fréquentes, la différence de confort resterait marginale, et le choix d’un outil plus richement outillé en greffons pourrait rester préférable si des besoins de transformation avancée se présentent.
Notre verdict
La migration vers esbuild sur ce thème a apporté un gain de confort quotidien largement supérieur à l’effort d’adaptation requis, concentré presque entièrement sur un seul greffon à réimplémenter manuellement. Pour un projet à plusieurs points d’entrée où la vitesse de recompilation affecte directement la fluidité du travail, ce choix mérite sérieusement d’être envisagé plutôt que reconduit par habitude avec l’outil déjà en place.
