Next.js 16 + Turbopack : retour d'expérience sur un vrai projet

Quand Vercel a annoncé Turbopack, la promesse était claire : un bundler plus rapide que Webpack, pensé pour les gros projets. Beaucoup de promesses dans le JavaScript, on a l'habitude. Sauf que cette fois, après des mois en beta, le File System Caching est maintenant stable dans Next.js 16.

J'utilise Turbopack au quotidien sur mes projets clients depuis plusieurs mois. Pas sur un side project un samedi après-midi. Sur de vrais projets, avec de vrais utilisateurs, de vraies deadlines. Voici ce que j'en pense.

Le démarrage du serveur de dev

C'est le gain le plus viscéral. Celui qu'on ressent physiquement. Sur un projet avec une centaine de composants et plusieurs routes dynamiques, le next dev passait de 8 à 12 secondes avec Webpack. Avec Turbopack ? Entre 2 et 3 secondes.

Ça paraît anodin. Ça ne l'est pas. Sur une journée de développement où on redémarre le serveur dix, quinze, vingt fois, ces secondes gagnées s'accumulent. Mais surtout, c'est le flow de travail qui change. Quand le feedback est instantané, on itère plus vite, on teste plus de choses, on hésite moins à redémarrer pour vérifier un doute.

Le HMR sous la seconde

Les changements s'affichent quasi instantanément dans le navigateur. J'ai chronométré sur un projet complexe avec Webpack : entre 1 et 3 secondes de latence entre la sauvegarde et le rafraîchissement visible. Avec Turbopack, c'est systématiquement sous la seconde. Souvent autour de 200 à 300 millisecondes.

Ça semble technique et ennuyeux. En pratique, c'est la différence entre un outil qui répond quand on lui parle et un outil qui met un temps de réflexion agaçant avant chaque réponse.

Le cache sur le système de fichiers

C'est la nouveauté majeure de la version stable et celle qui m'a le plus surpris au quotidien. Les résultats de compilation sont mis en cache sur le disque. Ce qui signifie que même après un redémarrage complet du serveur (la nuit, un reboot, un changement de branche), le temps de compilation est drastiquement réduit.

En pratique, quand je reprends un projet le matin avec mon café, la première page se charge presque aussi vite que si le serveur tournait déjà. Avant, le cold start du matin c'était 15 secondes de contemplation existentielle devant le terminal. Maintenant c'est 3 secondes et je suis dedans.

Ce qui ne change pas

Le build de production. Turbopack ne remplace pas encore Webpack pour le next build dans tous les cas. Honnêtement, ce n'est pas un problème. Les builds de production tournent une fois en CI, pas toutes les 30 secondes sur ma machine. Le gain en dev est tellement significatif que le build prod peut attendre.

La compatibilité est bonne. La plupart des packages npm fonctionnent sans accroc. J'ai rencontré quelques soucis avec des plugins Webpack très spécifiques il y a quelques mois, mais les cas de bord se réduisent à chaque version. Si vous n'utilisez pas de configuration Webpack exotique, vous ne verrez probablement aucune différence.

Et surtout, la qualité du code produit ne change pas. Turbopack change la vitesse de compilation, pas le code généré. Vos composants React, votre architecture, vos patterns, tout reste identique. C'est transparent pour le produit final.

Cloudflare vinext, faut-il s'inquiéter ?

Cloudflare a récemment présenté vinext, une réimplémentation expérimentale de Next.js basée sur Vite. Les premiers benchmarks sont impressionnants : builds 4x plus rapides dans certains cas.

Mon avis franc : c'est intéressant à surveiller, mais ce n'est pas un signal pour changer de stack. vinext est expérimental, couvre un sous-ensemble des fonctionnalités de Next.js, et n'a pas l'écosystème de production de Vercel. Pour un projet qui doit tourner en production aujourd'hui, Next.js reste le choix pragmatique.

Le meilleur scénario ? vinext mûrit, fait pression sur Vercel pour accélérer encore, et c'est tout l'écosystème qui en bénéficie. La concurrence, c'est toujours bon pour les développeurs.

Quand migrer

Si vous êtes déjà sur Next.js 15+, activer Turbopack en dev se fait en une ligne dans votre next.config. Dix minutes pour tester, risque minimal, gain immédiat. Il n'y a vraiment aucune raison de ne pas essayer. Si un plugin bloque, vérifiez s'il existe une alternative (souvent oui), et si le problème persiste, vous pouvez revenir en arrière en commentant une seule ligne.

Si vous êtes sur une version plus ancienne, la migration vers Next.js 16 vaut le coup pour d'autres raisons aussi : React 19, Server Components améliorés, meilleure gestion du cache. Turbopack est la cerise, pas le gâteau.

Sur mes projets, je configure Turbopack dès le départ. Mes clients ne voient pas la différence dans le produit final. Mais ils voient la différence dans les délais de livraison.

Un projet Next.js à lancer ou à moderniser ? Prenez un créneau et on regarde ensemble quelle stack correspond à votre besoin.