Si vous vous demandez si la mise à jour en vaut la peine, la réponse est un grand oui. Cette version ne se contente pas d'ajouter des fonctionnalités, elle repense des aspects fondamentaux du framework pour résoudre des frustrations de longue date.
Au programme : des builds jusqu'à 5 fois plus rapides, une gestion du cache enfin transparente et des optimisations automatiques qui vous feront oublier useMemo et useCallback. Plongeons dans les changements concrets qui vont impacter votre quotidien.
Turbopack devient le bundler par défaut
C'est sans doute le changement le plus attendu. Turbopack, le successeur de Webpack écrit en Rust, n'est plus une option expérimentale. Il est désormais le moteur par défaut pour les commandes next dev et next build.
Des performances de build décuplées
Qu'est-ce que cela signifie concrètement pour vous ?
- Builds de production 2 à 5 fois plus rapides : Le temps d'attente pour vos déploiements est drastiquement réduit.
- Fast Refresh jusqu'à 10 fois plus rapide : Les modifications dans votre code apparaissent quasi instantanément pendant le développement.
Pour les projets qui dépendent encore d'une configuration Webpack très personnalisée, pas de panique. Vous pouvez toujours forcer l'utilisation de Webpack avec le flag --webpack.
Mise en cache sur le système de fichiers
Pour aller encore plus loin, Turbopack introduit une mise en cache sur le système de fichiers (en bêta). Une fois activée dans votre next.config.js, cette option permet de sauvegarder le travail de compilation entre les redémarrages du serveur de développement. Sur les gros projets, le premier démarrage reste le même, mais les suivants sont quasi instantanés.
L'arrivée des Cache Components : le contrôle total sur le cache
La gestion du cache dans Next.js a longtemps été une boîte noire. Le framework prenait des décisions pour nous, de manière implicite, ce qui entraînait souvent des comportements inattendus et des heures de débogage. Next.js 16 met fin à cela avec les Cache Components.
La nouvelle philosophie est simple : rien n'est mis en cache par défaut. C'est à vous, développeur, de décider explicitement ce qui doit l'être.
Pour mettre en cache le rendu d'un composant, d'une page ou le résultat d'une fonction, il suffit d'ajouter la directive "use cache" au début du fichier ou de la fonction.
'use server' 'use cache' export default async function Page() { const products = await getProductsFromDatabase(); // Le rendu de cette page sera mis en cache return <ProductList products={products} />; }
Ce changement fondamental apporte une clarté et une prévisibilité bienvenues. Vous savez exactement ce qui est mis en cache et pourquoi, ce qui simplifie la gestion des données dynamiques et statiques. Cette approche s'appuie sur le Partial Prerendering (PPR), permettant de générer une "coquille" statique de la page au build, tout en laissant des espaces pour du contenu dynamique chargé à la volée.
Le React Compiler est enfin stable
Oubliez les useMemo et useCallback que vous ajoutiez partout pour optimiser les rendus. Le compilateur de React, désormais stable et intégré à Next.js 16, s'en charge pour vous, automatiquement.
Il analyse votre code et applique la mémoïsation là où c'est nécessaire, sans que vous ayez à intervenir. Le résultat est un code plus propre, plus simple à lire et souvent plus performant, car le compilateur prend des décisions d'optimisation plus fines que ce qu'un humain ferait manuellement.
Pour l'activer, il suffit d'ajouter une ligne à votre configuration :
// next.config.js const nextConfig = { reactCompiler: true, };
Même s'il est stable, il n'est pas activé par défaut pour l'instant, le temps pour l'équipe de Vercel de collecter plus de données sur son impact sur les temps de compilation.
Des améliorations significatives du routage
Deux optimisations intelligentes viennent améliorer la navigation dans vos applications.
- Déduplication des layouts : Si vous avez une page listant 50 produits qui partagent le même layout, Next.js 15 préchargeait ce layout 50 fois. Next.js 16 le précharge une seule fois et le réutilise pour tous les liens, réduisant considérablement la quantité de données transférées.
- Préchargement incrémental : Le framework ne précharge plus des pages entières, mais uniquement les segments qui ne sont pas déjà en cache. C'est plus efficace et plus respectueux de la bande passante de l'utilisateur.
De nouvelles API pour une gestion fine du cache
La gestion de l'invalidation du cache a été entièrement repensée pour être plus intuitive et puissante.
revalidateTag : la revalidation intelligente
La fonction revalidateTag adopte désormais une stratégie de type "stale-while-revalidate". Lorsque vous appelez revalidateTag('my-tag'), les données existantes sont marquées comme obsolètes. L'utilisateur continue de voir l'ancienne version pendant que Next.js récupère la nouvelle en arrière-plan. Une fois prête, la nouvelle version est affichée. Cela évite les écrans de chargement et améliore l'expérience utilisateur.
updateTag : pour des mises à jour immédiates
Pour les cas où une mise à jour doit être visible instantanément (par exemple, après la soumission d'un formulaire), la nouvelle fonction updateTag est là. Utilisée dans une Server Action, elle invalide le cache et force un rafraîchissement immédiat, garantissant que l'utilisateur voit ses changements sans délai.
refresh : rafraîchir uniquement les données dynamiques
Enfin, l'API refresh permet de relancer uniquement les fetches de données qui ne sont pas mises en cache, sans toucher au reste. C'est parfait pour des éléments comme un compteur de notifications qui doit être à jour sans pour autant invalider toute la page.
| API | Comportement | Cas d'usage principal |
|---|---|---|
revalidateTag(tag)
|
Stale-while-revalidate. Sert le contenu obsolète pendant que le nouveau est récupéré en arrière-plan. | Mettre à jour des listes, des articles de blog. L'instantanéité n'est pas critique. |
updateTag(tag)
|
Invalide et rafraîchit immédiatement le cache. Bloque la navigation jusqu'à la fin. | Après une action utilisateur (formulaire, suppression) où le retour visuel doit être immédiat. |
refresh()
|
Relance uniquement les fetches de données non mises en cache (cache: 'no-store'). |
Mettre à jour des données dynamiques (notifications, statut en temps réel) sans invalider le cache statique. |
Les breaking changes et la migration à prévoir
Toute version majeure vient avec son lot de changements cassants. Heureusement, Next.js 16 les limite et fournit des outils pour faciliter la transition.
Les API asynchrones deviennent la norme
Les fonctions comme cookies(), headers() ou searchParams sont désormais toutes asynchrones. Vous devrez les await pour y accéder.
- Avant (Next.js 15) :
const cookieStore = cookies(); - Maintenant (Next.js 16) :
const cookieStore = await cookies();
Ce changement rend le code plus explicite : si vous await une de ces fonctions, la page devient dynamique. Il n'y a plus de magie implicite. Un codemod est disponible pour automatiser une grande partie de cette mise à jour.
Adieu middleware.ts, bonjour proxy.ts
Le fichier middleware.ts est renommé en proxy.ts. Ce changement est purement sémantique, mais il est important. Le terme "middleware" prêtait à confusion avec l'écosystème Express/Node.js. "Proxy" décrit mieux son rôle : intercepter une requête à la périphérie (edge), avant même qu'elle n'atteigne votre application.
La migration est simple :
- Renommez le fichier
middleware.tsenproxy.ts. - Renommez la fonction
export function middleware(...)enexport function proxy(...).
Prérequis techniques mis à jour
- Node.js : La version 20.9.0 ou supérieure est désormais requise.
- TypeScript : La version 5.1 ou supérieure est nécessaire.
Autres améliorations notables pour les développeurs
- Logs de build améliorés : La console vous donne désormais un détail précis du temps passé à chaque étape du build (compilation, rendu, génération des pages), vous aidant à identifier les goulots d'étranglement.
- Support natif de
next.config.ts: Plus besoin de contournements, la configuration en TypeScript est mieux prise en charge. - Répertoires de sortie séparés :
next devetnext buildutilisent maintenant des dossiers différents (.next/devet.next), ce qui évite les conflits si vous lancez les deux processus en parallèle.
Faut-il mettre à jour vers Next.js 16 ?
Oui, sans hésiter. Next.js 16 n'est pas une simple mise à jour incrémentale. C'est une version de maturité qui apporte des gains de performance massifs grâce à Turbopack, une clarté bienvenue dans la gestion du cache avec les Cache Components, et une expérience de développement simplifiée grâce au React Compiler.
La migration demandera un peu de travail, notamment pour adapter les appels aux API asynchrones, mais les outils fournis et les bénéfices à long terme en valent largement l'effort. Vous obtiendrez une application plus rapide, un code plus simple et, surtout, un contrôle total sur le comportement de votre framework.
