Le next dev qui démarre en moins de deux secondes, ça surprend. Pas parce que je n'attendais pas d'améliorations — la version 16.1 avait déjà rendu Turbopack stable — mais parce que la différence se sent vraiment sur un projet qui avait commencé à prendre du poids.
Next.js 16.2 est sorti le 18 mars 2026. Ce n'est pas une release majeure au sens "tout change", mais c'est le genre de version qui améliore votre quotidien sans que vous ayez à faire quoi que ce soit de spécial pour en bénéficier.
Avant de rentrer dans les détails, les métriques clés :
next dev) par rapport à 16.1ImageResponseCe ne sont pas des chiffres marketing. Vercel les mesure sur de vrais projets — dont le site de Payload CMS — et les publie avec les benchmarks bruts.
C'était le point de douleur principal depuis des mois. Sur les projets qui accumulent des routes, des composants et du middleware, next dev pouvait prendre 8 à 12 secondes avant d'être prêt.
16.2 passe à ~87% plus vite que 16.1. Sur le projet que j'ai mis à jour ce matin, ça donne environ 1,4 seconde contre 9 secondes avant. La différence se ressent immédiatement quand on travaille avec plusieurs fenêtres de terminal ou qu'on redémarre régulièrement le serveur.
[!NOTE] Le chiffre "400% plus rapide" qu'on voit circuler fait référence à la comparaison avec des versions antérieures à 16.x. Par rapport à 16.1 spécifiquement, c'est 87%. Les deux chiffres sont exacts, ils ne mesurent pas la même baseline.
Celui-là est plus subtil mais potentiellement plus impactant en production.
L'équipe Next.js a contribué un changement directement dans React qui rend la désérialisation du payload des Server Components jusqu'à 350% plus rapide. Le problème venait du JSON.parse avec un callback reviver — chaque paire clé/valeur traversait la frontière C++/JavaScript dans V8, ce qui rendait le parsing environ 4x plus lent qu'un JSON.parse simple.
La nouvelle implémentation fait un JSON.parse classique suivi d'un parcours récursif en JavaScript pur. Résultat en conditions réelles :
| Scénario | Avant | Après | Gain |
|---|---|---|---|
| Server Component (tableau 1000 éléments) | 19ms | 15ms | 26% |
| Server Component avec Suspense imbriqué | 80ms | 60ms | 33% |
| Homepage Payload CMS | 43ms | 32ms | 34% |
| Payload CMS avec rich text | 52ms | 33ms | 60% |
Les gains varient selon la taille du payload RSC. Plus votre page charge de données côté serveur, plus vous bénéficiez du changement.
[!IMPORTANT] Ce gain s'applique en production. Si vos Core Web Vitals (TTFB, LCP) stagnaient malgré un bon hébergement, une mise à jour vers 16.2 peut débloquer des améliorations sans toucher à votre code.
Voilà quelque chose que j'attendais depuis longtemps.
Jusqu'ici, déboguer une Server Action, c'était soit ajouter des console.log partout, soit prier pour que l'erreur remonte bien dans l'interface. Avec 16.2, Next.js log automatiquement chaque exécution de Server Function dans le terminal de dev : nom de la fonction, arguments, durée, fichier source.
POST /api/contact 200 in 34ms
→ ServerAction: submitContactForm (app/actions/contact.ts:12)
• name: "Jean Dupont"
• email: "jean@example.ch"
Executed in 31ms
C'est exactement ce qu'on avait avec les API routes classiques, maintenant disponible pour les Server Actions. Le debug devient nettement plus rapide.
Les erreurs d'hydratation sont parmi les plus frustrantes à déboguer en Next.js. Le message d'erreur existait, mais comprendre exactement ce qui différait entre le HTML serveur et le rendu client relevait de la devinette.
16.2 ajoute un diff visuel + Client / - Server directement dans l'overlay d'erreur. On voit exactement quel élément diverge, sans avoir à comparer manuellement deux arbres DOM.
Sur les projets où on utilise des données dépendantes de la locale (dates, formatage de nombres), c'est un gain de temps réel.
--inspect pour le serveur de productionNext.js 16.1 avait introduit next dev --inspect pour attacher le débogueur Node.js en développement. 16.2 étend ça à la production :
next start --inspect
Ça permet d'attacher Chrome DevTools (ou n'importe quel client Node.js inspector) à votre serveur de production — utile pour profiler des problèmes de mémoire ou de CPU qui n'apparaissent pas en local.
[!NOTE] À n'utiliser que sur un environnement de staging, jamais directement sur la prod publique. Le port d'inspection doit rester inaccessible depuis l'extérieur.
transitionTypes sur next/linkPetite feature, mais bien pensée. Le composant <Link> accepte maintenant un prop transitionTypes qui permet de déclencher des View Transitions CSS différentes selon le contexte de navigation :
<Link href="/projet/design-identite" transitionTypes={['slide-left']}>
Projet suivant
</Link>
<Link href="/projet/wordpress-sion" transitionTypes={['slide-right']}>
Projet précédent
</Link>
Combiné avec les View Transitions CSS natives, ça permet des animations de navigation fluides sans dépendance à Framer Motion pour les cas simples. Le prop est ignoré silencieusement sur le Pages Router, donc les composants partagés entre les deux routers fonctionnent sans modifications.
ImageResponse : jusqu'à 20x plus rapideSi vous générez des images Open Graph dynamiques (les previews qui s'affichent quand on partage un lien), ImageResponse vient d'être significativement optimisé :
text-indent, box-sizing, display: contentsSur un site qui génère des dizaines d'images OG dynamiques, c'est du temps de build récupéré directement.
npm install next@latest react@latest react-dom@latest
Ou avec le codemod automatique qui gère les breaking changes éventuels :
npx @next/codemod@canary upgrade latest
Il n'y a pas de changements cassants majeurs dans 16.2. La mise à jour devrait être transparente sur la grande majorité des projets.
La release note mentionne des Adapters (stable dans cette version), une nouvelle API qui permet aux plateformes de personnaliser le processus de build. Vercel promet un article dédié — ça concerne surtout ceux qui déploient sur des infras custom plutôt que Vercel directement.
Il y a aussi experimental.prefetchInlining qui regroupe toutes les données d'une route dans une seule réponse de prefetch au lieu de plusieurs requêtes par segment. L'idée est bonne, mais j'attends que ça sorte de l'expérimental avant de le tester sur des projets clients.
Vous utilisez Next.js sur votre site et vous n'avez pas encore fait les dernières mises à jour ? Contactez-moi — une mise à jour bien gérée peut améliorer vos Core Web Vitals sans toucher au design ni au contenu.
Besoin d'aide ?
Container queries, :has(), nesting natif, view transitions — le CSS de 2026 fait ce que JavaScript et Sass faisaient avant. Tour d'horizon des fonctionnalités qui changent la donne.
Les sites statiques appartiennent au passé. Découvrez comment les micro-interactions fluides avec Framer Motion augmentent l'engagement utilisateur et le taux de conversion.
Un site WordPress qui mettait 12 secondes à charger est passé à 1,8 seconde en corrigeant trois erreurs courantes. Voici lesquelles.
