Il y a trois ans, j'étais en appel avec un client à Toronto, regardant un build Next.js avancer péniblement en 94 secondes tandis que nous prétendions tous les deux que ça allait. Webpack. Huit mille modules. Un monorepo avec des composants UI partagés que personne n'avait audités depuis 2021. Le client a demandé si on pouvait « le rendre plus rapide ». J'ai devisé deux jours de travail. Ça en a pris quatre. Et même là, on l'a réduit à 61 secondes, ce qui ressemblait à gagner une course que personne ne voulait faire.
Turbopack a changé cette histoire. Surtout. Mais ici en 2026, je vois régulièrement des développeurs supposer que passer à Turbopack est une ligne d'arrivée plutôt qu'un point de départ. Ils activent le flag, réduisent de 40% le démarrage du serveur dev, et arrêtent là. Les vrais goulots d'étranglement ont juste bougé quelque part de plus discret.
Laissez-moi vous montrer où va vraiment le temps de build quand vous exécutez Turbopack dans une vraie codebase de production. Pas une todo app. Pas le template d'exemple Next.js. Un vrai site avec 200+ routes, une intégration CMS, et un client qui remarque chaque seconde.
L'écart entre le mode dev et les builds de production
Voici ce que la plupart des gens ratent : les plus grandes victoires de Turbopack se font sur le serveur dev. Compilation incrémentale, cache au niveau du module, tout le graphe propulsé par Rust. En mode dev, c'est véritablement transformateur. J'ai chronométré un démarrage à froid sur un projet client Seahawk passant de 28 secondes sous webpack à moins de 4 avec Turbopack. Ce n'est pas une erreur d'arrondi.
Mais next build est une bête différente. Début 2026, le support des builds de production de Turbopack est stable mais ne réécrit pas tout le pipeline. L'analyse statique, l'optimisation des pages et le compilateur SWC font tous encore le gros du travail aux côtés du bundler de Turbopack. Vous n'obtenez pas un 10x uniforme sur la sortie de production.
C'est important parce que les développeurs mesurent la mauvaise chose. Ils regardent next dev démarrer et en conclut que le build est rapide. Puis CI prend 3 minutes et ils haussent les épaules.
Ce que l'architecture Turbopack fait vraiment
Turbopack fonctionne sur un modèle de calcul à la demande. Il ne construit que ce qui est demandé, cache au niveau du module, et invalide précisément plutôt que largement. C'est pourquoi le document d'architecture de l'équipe Vercel parle de « mémoïsation au niveau fonction ». Ce n'est pas du marketing. C'est le vrai mécanisme derrière la raison pour laquelle toucher un composant ne force pas un re-bundle complet.
L'implication : vos gains les plus rapides se produisent où l'invalidation était auparavant trop large. Les fichiers utilitaires partagés, les larges barrel exports, les re-exports profondément imbriqués. Ce sont les endroits où Webpack vous punissait silencieusement.
Où le temps disparaît vraiment en 2026
J'ai audité quatre codebases le trimestre dernier avec NEXT_TURBOPACK_TRACING=1. Oui, cette variable d'environnement existe et oui, elle crache un fichier trace que vous pouvez charger dans le panneau performance de Chrome. Je le recommande vivement avant de supposer que quelque chose en particulier est le coupable.
Voici ce que j'ai trouvé, classé à peu près par la fréquence à laquelle ils apparaissent :
- Explosions de fichiers barrel. Un seul
index.tsréexportant 60 composants d'un design system tire chacun de ces modules dans le graphe même si vous en utilisez deux. Turbopack gère ça mieux que Webpack mais ça ne fait pas disparaître le problème. La correction est des imports granulaires. Toujours. - Vérification des types non séparée du bundling. Exécuter
tsc --noEmitdans le même pipeline de build que Turbopack traite double votre wall time. Séparez-les. La vérification des types TypeScript et le bundling Turbopack doivent être des jobs parallèles en CI, pas des étapes séquentielles. - Des IDs de module instables dans les packages tiers. Certains packages npm livrent du CommonJS avec des require dynamiques. Turbopack doit revenir à des chemins d'analyse plus lents pour ceux-ci. J'ai rencontré ça le mois dernier avec une ancienne version d'une bibliothèque de génération de PDF. Je l'ai mise à jour, j'ai gagné 8 secondes.
- Optimisation des images au moment du build. Si vous pré-générez des milliers de variantes d'images avec
next/imageet une exportation statique, c'est synchrone et lié au CPU. Ce n'est pas Turbopack. Mais ça apparaît dans la trace de build et les gens blâment le bundler. - Les payloads de données `getStaticProps` volumineux. Récupérer 4 Mo de données CMS par page pendant le build, sur 300 pages, c'est un problème de réseau et de parsing. Encore une fois, pas Turbopack. Mais ça se situe dans le même build de 180 secondes et est blâmé collectivement.
La vérité inconfortable, c'est que Turbopack a tellement accéléré la phase de bundling que tout ce qui l'entoure semble maintenant lent en comparaison. C'est comme mettre à niveau la poubelle de votre cuisine pour s'ouvrir automatiquement, puis se rendre compte que la marche jusqu'à la poubelle roulante dehors est la vraie gêne.
Le Problème des Fichiers Barrel Mérite Sa Propre Section
Je ne peux pas assez le souligner. Les fichiers barrel sont la blessure la plus commune auto-infligée au build que je vois dans les agences.
Un client est venu nous voir fin 2025 avec une bibliothèque de composants qui avait cette structure :
`` components/ index.ts (exports 140 named components) ``
Chaque page important même un bouton tirait le graphe entier de 140 composants. Avec Webpack, le tree-shaking aidait partiellement au moment de la sortie. Avec Turbopack, le graphe de module devait toujours être traversé et compris avant que quoi que ce soit puisse être élaguée. Le serveur de dev n'était pas lent en soi, mais les démarrages à froid étaient douloureux.
Nous avons restructuré pour des imports spécifiques au chemin :
`` import { Button } from '@company/ui/button' import { Modal } from '@company/ui/modal' ``
Le démarrage à froid du dev est passé de 11 secondes à moins de 3. Le build de production a baissé de 22 secondes. Personne n'a touché à la config de Turbopack. La correction était juste... ne pas être paresseux avec les imports.
Il y a en fait une bonne règle eslint-plugin-import pour attraper ceux-ci : import/no-barrel-files. Ajoutez-la à votre config de lint et traitez les violations comme de la dette de build.
Mise en cache en CI : Vous laissez probablement 40 secondes sur la table
La mise en cache locale de Turbopack est excellente. La mise en cache en CI est un problème séparé et la plupart des équipes la configurent une fois et ne la revisitent jamais.
Le cache de Turbopack se trouve dans .next/cache/turbopack par défaut. Si votre pipeline CI (GitHub Actions, CircleCI, peu importe) ne persiste pas ce répertoire entre les exécutions, vous faites un build à froid complet à chaque fois. Sur une base de code de taille raisonnable, c'est 30 à 60 secondes de pur gaspillage par exécution.
Voici à quoi ressemble une clé de cache appropriée pour une configuration Next.js + Turbopack dans GitHub Actions :
- Clé de cache : hash de
package-lock.json+ hash denext.config.js+ hash detsconfig.json - Chemin de cache :
.next/cache - Clés de restauration : revenir à la cache précédente sur la même branche, puis main
C'est tout. La plupart des équipes ne hashent que package-lock.json . Mais si votre next.config.js change la config de Turbopack (fonctionnalités expérimentales, alias de module, chargeurs personnalisés), vous voulez que ce soit invalidé. J'ai vu des bugs où un cache périmé servait des résolutions de module incorrectes après un changement de config. Ennuyeux à déboguer à 23h.
Seahawk avait un projet fintech où simplement fixer la structure de la clé de cache a fait passer le build CI moyen de 4 minutes 20 secondes à 2 minutes 50 secondes. Même code. Même matériel. Juste une invalidation de cache plus intelligente.
Les Chargeurs Personnalisés et Pourquoi Ils Tuent Vos Gains
Turbopack supporte les chargeurs personnalisés, mais il y a un coût. Chaque chargeur personnalisé vous fait tomber hors du chemin rapide natif de Turbopack et dans une couche de compatibilité. L'équipe Vercel est assez honnête à ce sujet dans la documentation de configuration Turbopack de Next.js.
Je vois ça le plus souvent avec :
- Chargeurs SVG (personnes convertissant les SVG en composants React au moment de la compilation)
- MDX avec des chaînes de plugins remark/rehype intensives
- CSS Modules avec des configurations PostCSS personnalisées incluant des plugins rarement utilisés
Pour les SVG spécifiquement, la tendance en 2026 est de pré-compiler votre bibliothèque d'icônes en composants React dans une étape de compilation séparée, non au moment de la compilation Next.js. SVGR est excellent pour cela en tant que script autonome. Exécutez-le quand vos design tokens changent, committez le résultat, et laissez Turbopack les traiter comme des fichiers .tsx ordinaires.
MDX est plus délicat. Si vous exécutez 40 plugins remark, vous allez le sentir. Auditez lesquels vous avez réellement besoin. J'ai vu des bases de code exécutant remark-gfm, remark-smartypants, un plugin de notes de bas de page personnalisé, et deux autres, où seulement deux d'entre eux produisaient des différences de résultat visibles. Supprimez les inutilisés.
La taxe de résolution de module dont personne ne parle
Les alias de chemin. Tout le monde les utilise. @/components, @/lib, ~/utils. C'est pratique. C'est aussi une petite taxe qui s'accumule.
Turbopack résout les alias à chaque rencontre d'import. Dans une large base de code avec 4 000 imports et 12 alias configurés, c'est 48 000 opérations de résolution par compilation. Pas catastrophique. Mais pas gratuit non plus.
La solution n'est pas de supprimer les alias. C'est d'être précis avec eux. Évitez les alias avec caractères génériques où un chemin spécifique ferait l'affaire. Et gardez vos chemins tsconfig.json synchronisés avec votre configuration turbopack resolveAlias de next.config.js. Une dérive entre ces deux cause à Turbopack de faire du travail de résolution redondant. J'ai vu des économies de 4-5 secondes juste en nettoyant cela.
Ce que Turbopack 2026 ne fait toujours pas
J'aime bien Turbopack. Nous l'utilisons sur la plupart des nouveaux projets Seahawk. Mais l'honnêteté compte.
- L'analyse des bundles n'est pas aussi mature que l'écosystème Webpack.
@next/bundle-analyzerfonctionne mais la visualisation est moins granulaire que ce que vous obtiendriez dewebpack-bundle-analyzer. C'est en amélioration mais ce n'est pas encore là. - L'écosystème de plugins est plus petit. Si votre stack repose sur des plugins Webpack fortement personnalisés (certaines configurations d'entreprises héritées le font), la migration reste un vrai projet, pas une affaire d'après-midi.
- Les performances Windows ont historiquement traîné derrière macOS et Linux. C'est en s'améliorant avec chaque version de Next.js, mais si votre équipe est majoritairement Windows, mesurez avant de vous engager.
Aucun de ces éléments ne sont des obstacles majeurs. Mais ce sont des considérations réelles si vous évaluez si vous devez migrer un projet existant par rapport à recommencer de zéro.
Comment tracer réellement votre compilation
Arrêtez de deviner. Exécutez ceci :
- Définissez
NEXT_TURBOPACK_TRACING=1dans votre environnement - Exécutez
next build(ounext devsi vous profilez le démarrage de dev) - Ouvrez
.next/tracedans Perfetto UI ouchrome://tracingde Chrome - Filtrez par durée. Tout ce qui dépasse 2 secondes dans un seul module vaut la peine d'être investigué.
C'est la même approche que j'utilise avant tout engagement d'optimisation de compilation. La trace vous dit où le temps s'écoule. Tout le reste est de la conjecture présentée comme une expertise.
---
FAQ
Turbopack est-il assez stable pour les compilations de production en 2026 ?
Oui, le support des compilations de production est devenu stable fin 2024 et s'est considérablement amélioré au cours de 2025. Pour la plupart des projets Next.js démarrant de zéro, je choisirais Turbopack sans hésiter. Pour les projets hérités avec une forte personnalisation Webpack, faites d'abord une étude et mesurez.
Turbopack remplace-t-il SWC ?
Non. SWC est le transpileur TypeScript et JSX. Turbopack est le bundler. Ils travaillent ensemble. Turbopack utilise SWC sous le capot pour la transformation. Vous ne choisissez pas entre les deux.
Pourquoi mon serveur de développement Turbopack est rapide mais la build CI reste lente ?
C'est presque certainement l'une de ces raisons : type-checking exécuté en série avec le bundling, aucun cache CI configuré pour .next/cache, ou l'optimisation d'images dominant la phase de génération statique. Lancez la trace. Elle vous montrera laquelle.
Devrais-je basculer un projet Webpack existant vers Turbopack maintenant ?
Si c'est un projet greenfield ou peu customisé, oui. Si vous avez 15 plugins Webpack personnalisés et une chaîne de loaders complexe, prévoyez un sprint de migration approprié. Ne le faites pas en tant qu'afterthought un vendredi après-midi. (Je le dis d'expérience personnelle. Ne demandez pas de détails sur le vendredi.)
Turbopack fonctionne-t-il avec les monorepos Nx ou Turborepo ?
Oui, et plutôt très bien. Le cache Turborepo s'empile correctement sur le cache interne de Turbopack, et les deux outils partagent un héritage de la même équipe. La combinaison est vraiment efficace pour les grands monorepos où seul un sous-ensemble de packages change par PR.
---
Les outils de build sont ennuyeux jusqu'au moment où votre facture CI atteint 800 $ par mois et que votre équipe de développement se plaint des cold starts à la standup. Turbopack a déplacé le goulot d'étranglement, ce qui est un progrès. Mais il n'a pas éliminé le besoin de bien réfléchir à la répartition du temps. Tracez d'abord. Optimisez ensuite. Et pour l'amour de tout, corrigez vos barrel files.