# Bun contre Node pour lancer les scripts de build d’un thème WordPress

> Sur un projet concret, mesurer les gains de temps réels de Bun face à Node sur l'installation des dépendances et l'exécution des scripts de build.

- Auteur : Clément Hadrot
- Publié le : 2025-04-17
- Mis à jour le : 2025-04-17
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/bun-node-scripts-build-theme-wordpress/

## L’essentiel

- L'installation des dépendances est le principal poste de gain avec Bun
- L'exécution des scripts de build gagne moins que promis en marketing
- La compatibilité reste le vrai risque, pas la vitesse

Le comparatif général entre npm, pnpm et Bun a déjà été publié sur ce blog. Ce texte va plus loin sur un point précis : que se passe-t-il quand on remplace concrètement Node par Bun pour exécuter les scripts de build d'un thème WordPress réel, celui d'un client e-commerce dont le thème embarque une trentaine de blocs Gutenberg personnalisés, un build Vite, et une suite de tests unitaires JavaScript avec Vitest ?

La mesure a porté sur trois opérations distinctes : l'installation des dépendances depuis zéro, l'exécution du build de production, et l'exécution de la suite de tests. Chaque mesure a été répétée cinq fois sur la même machine, un cache de paquets vidé avant chaque série pour l'installation des dépendances.

## Installation des dépendances : l'écart le plus net

Avec Node et npm, l'installation complète des 640 paquets du projet (dépendances directes et transitives confondues) a pris en moyenne 38 secondes, cache npm vidé. Avec Bun, la même opération, `bun install` à la place de `npm install`, s'est terminée en moyenne en 9 secondes.

```
# Avec npm
time npm ci
# real  0m38,412s

# Avec Bun
time bun install --frozen-lockfile
# real  0m9,047s
```

Cet écart de 4,2 fois s'explique par l'architecture de Bun, écrit en Zig et compilé nativement, qui télécharge et extrait les paquets avec un parallélisme et une gestion de fichiers nettement plus efficaces que le runtime Node/npm classique. Ce résultat rejoint les mesures déjà connues sur d'autres projets, sans surprise particulière ici.

## Le build de production : un gain plus modeste

Ici les choses se corsent. Le script de build repose sur Vite, qui utilise esbuild pour la transformation et Rollup pour le bundling final. Node exécute ce script en environ 14 secondes. Bun, utilisé simplement comme remplaçant de `node` pour lancer le même script (`bun run build` au lieu de `npm run build`), l'exécute en environ 12 secondes.

> L'essentiel à retenir : L'installation des dépendances est le principal poste de gain avec Bun ; L'exécution des scripts de build gagne moins que promis en marketing ; La compatibilité reste le vrai risque, pas la vitesse

| Opération | Node / npm | Bun | Gain |
| --- | --- | --- | --- |
| Installation des dépendances | 38,4 s | 9,0 s | ×4,2 |
| Build de production (Vite) | 14,1 s | 12,3 s | ×1,15 |
| Suite de tests (Vitest) | 21,7 s | 19,8 s | ×1,10 |

Ce résultat s'explique simplement : une fois le code chargé, le gros du travail de build repose sur esbuild, déjà écrit en Go et compilé nativement, indépendamment du runtime JavaScript qui orchestre l'appel. Bun accélère surtout le démarrage du processus et l'exécution du code JavaScript pur du script de build, mais la majorité du temps passé dans un build Vite se trouve déjà dans du code natif optimisé, peu importe le runtime qui l'invoque.

## La compatibilité, le vrai sujet

Le gain de vitesse, réel sur l'installation mais modeste sur l'exécution, ne suffit pas à trancher seul. La bascule vers Bun a révélé deux incompatibilités sur ce projet précis :

- Un plugin Vite qui dépendait d'une API Node spécifique liée aux *worker threads*, non totalement implémentée par Bun au moment du test, a nécessité un contournement temporaire.
- Un script de post-installation d'un paquet npm tiers, qui supposait la présence de `node-gyp` pour compiler un module natif, a échoué sous Bun et a dû être remplacé par une alternative sans compilation native.

Ces frictions, mineures individuellement, ont représenté une demi-journée de travail de diagnostic avant de considérer la migration comme stable pour l'équipe de développement.

## Ce qui n'a pas changé

Le fichier `package.json` du thème n'a pas eu besoin d'être modifié : Bun lit le même format et respecte la même structure de scripts npm. Seul le fichier de verrouillage a changé, `bun.lockb` remplaçant `package-lock.json`, avec les implications habituelles sur la nécessité de le committer et de le tenir à jour dans le dépôt.

### Et en intégration continue ?

Sur GitHub Actions, remplacer `actions/setup-node` par `oven-sh/setup-bun` a suffi pour la configuration de base. Le gain de temps observé en local sur l'installation des dépendances s'est confirmé en CI, où le job de build est passé d'environ 55 secondes à 24 secondes, cache de dépendances GitHub Actions inclus dans les deux cas.

> Le gain de vitesse le plus spectaculaire ne se trouve jamais là où le marketing le promet le plus fort : ici, l'installation des dépendances explique presque tout l'écart, pas le build lui-même.

## Notre verdict

Pour ce projet, la bascule vers Bun a réduit le temps de pipeline CI de façon notable, portée presque entièrement par l'installation des dépendances plus rapide. Le gain sur le build de production lui-même reste marginal, car il dépend d'outils déjà natifs indépendamment du runtime. La compatibilité reste le vrai risque à évaluer avant de migrer un projet existant : sur un thème plus simple, sans dépendance à des modules natifs, cette bascule se ferait sans doute sans aucune friction. Sur un projet avec des dépendances plus exotiques, mieux vaut prévoir une phase de test dédiée avant de généraliser le changement à toute l'équipe.