Next.js 14.2 inclut des améliorations pour le développement, la production et la mise en cache. Avec notamment de nouvelles options de configuration, 99% des tests Turbopack validés, et plus encore.
Next.js 14.2 apporte des améliorations pour le développement, la production et la mise en cache.
Ces derniers mois, nous avons travaillé à améliorer les performances en développement local avec Turbopack. Dans la version 14.2, la Release Candidate de Turbopack est désormais disponible pour le développement local :
Nous avons intégré Lightning CSS, un bundler et minifier CSS rapide, écrit en Rust.
Nous avons largement testé Turbopack avec les applications de Vercel. Par exemple, avec vercel.com, une grande application Next.js, nous avons observé :
Jusqu'à 76,7% plus rapide au démarrage du serveur local.
Jusqu'à 96,3% plus rapide pour les mises à jour de code avec Fast Refresh.
Jusqu'à 45,8% plus rapide pour la compilation initiale des routes sans cache (Turbopack n'a pas encore de cache disque).
Turbopack reste optionnel et vous pouvez l'essayer avec :
Terminal
next dev --turbo
Nous allons maintenant nous concentrer sur l'amélioration de l'utilisation mémoire, l'implémentation du cache persistant et next build --turbo.
Utilisation mémoire - Nous avons développé des outils bas niveau pour analyser l'utilisation mémoire. Vous pouvez maintenant générer des traces incluant à la fois des métriques de performance et des informations sur l'utilisation mémoire. Ces traces nous permettent d'analyser sans avoir besoin d'accéder à votre code source.
Cache persistant - Nous explorons les meilleures options d'architecture et partagerons plus de détails dans une future version.
next build - Bien que Turbopack ne soit pas encore disponible pour les builds, 74,7% des tests passent déjà. Suivez la progression sur areweturboyet.com/build.
En plus des améliorations de bundling avec Turbopack, nous avons travaillé à améliorer les performances globales des builds et de la production pour toutes les applications Next.js (Pages et App Router).
Nous avons identifié une optimisation pour la frontière entre les composants Serveur et Client qui permet d'élaguer les exports inutilisés. Par exemple, importer un seul composant Icon depuis un fichier avec "use client" n'inclut plus tous les autres icônes du package. Cela peut réduire considérablement la taille des bundles JavaScript en production.
Testée sur une bibliothèque populaire comme react-aria-components, cette optimisation a réduit la taille finale du bundle de -51,3%.
Note : Cette optimisation ne fonctionne pas encore avec les fichiers barrel. En attendant, vous pouvez utiliser l'option optimizePackageImports :
Pour les applications Next.js très volumineuses, nous avons constaté des plantages par manque de mémoire (OOM) pendant les builds de production. Après investigation, nous avons identifié que le problème venait d'un sur-bundling et de la minification (Next.js créait moins de fichiers JavaScript plus gros avec des duplications). Nous avons refactorisé la logique de bundling et optimisé le compilateur pour ces cas.
Nos premiers tests montrent que sur une application Next.js minimale, l'utilisation mémoire et la taille des fichiers de cache ont diminué de 2,2GB à moins de 190MB en moyenne.
Pour faciliter le débogage des performances mémoire, nous avons ajouté un flag --experimental-debug-memory-usage à next build. Plus d'informations dans notre documentation.
Nous avons mis à jour la façon dont le CSS est optimisé pendant les builds de production Next.js en découpant le CSS pour éviter les conflits de styles lors de la navigation entre pages.
L'ordre et la fusion des chunks CSS sont maintenant définis par l'ordre d'import. Par exemple, base-button.module.css sera ordonné avant page.module.css :
base-button.tsx
import styles from './base-button.module.css';export function BaseButton() { return <button className={styles.primary} />;}
page.tsx
import { BaseButton } from './base-button';import styles from './page.module.css';export function Page() { return <BaseButton className={styles.primary} />;}
Pour maintenir le bon ordre CSS, nous recommandons :
D'importer un CSS Module dans un seul fichier JS/TS.
Si vous utilisez des classes globales, importer les styles globaux dans le même fichier JS/TS.
Nous ne pensons pas que ce changement affectera négativement la majorité des applications. Cependant, si vous constatez des styles inattendus après la mise à jour, vérifiez l'ordre de vos imports CSS comme recommandé dans notre documentation.
La mise en cache est essentielle pour créer des applications web rapides et fiables. Lors des mutations, utilisateurs et développeurs s'attendent à ce que le cache reflète les derniers changements. Nous avons exploré comment améliorer l'expérience de cache dans l'App Router de Next.js.
Le Cache du routeur côté client est une couche de cache conçue pour offrir une navigation rapide en mettant en cache les routes visitées et préchargées côté client.
Suite aux retours de la communauté, nous avons ajouté une option expérimentale staleTimes pour configurer la période d'invalidation du cache du routeur client.
Par défaut, les routes préchargées (avec le composant <Link> sans prop prefetch) sont mises en cache pendant 30 secondes, et 5 minutes si prefetch est à true. Vous pouvez remplacer ces valeurs par défaut en définissant des durées de revalidation personnalisées dans next.config.js :
staleTimes vise à améliorer l'expérience actuelle des utilisateurs voulant plus de contrôle sur les heuristiques de cache, mais ce n'est pas la solution complète. Dans les prochaines versions, nous nous concentrerons sur l'amélioration globale de la sémantique du cache et sur des solutions plus flexibles.
En savoir plus sur staleTimes dans notre documentation.
Les routes parallèles et interceptées qui invoquent des actions serveur (Server Actions) avec revalidatePath ou revalidateTag revalideront le cache et rafraîchiront les emplacements visibles tout en conservant la vue actuelle de l'utilisateur.
De même, l'appel à router.refresh rafraîchit désormais correctement les emplacements visibles, tout en conservant la vue actuelle.
Dans la version 14.1, nous avons commencé à travailler sur l'amélioration de la lisibilité des messages d'erreur et des traces de pile (stack traces) lors de l'exécution de next dev. Ce travail s'est poursuivi dans la version 14.2 pour inclure désormais de meilleurs messages d'erreur, des améliorations de conception de l'overlay pour le routeur d'application (App Router) et le routeur de pages (Pages Router), la prise en charge des modes clair et sombre, et des journaux dev et build plus clairs.
Par exemple, les erreurs d'hydratation (Hydration errors) de React sont une source fréquente de confusion dans notre communauté. Bien que nous ayons apporté des améliorations pour aider les utilisateurs à identifier la source des incohérences d'hydratation (voir ci-dessous), nous collaborons avec l'équipe React pour améliorer les messages d'erreur sous-jacents et afficher le nom du fichier où l'erreur s'est produite.
Avant :
Un exemple de l'overlay d'erreur de Next.js avant la version 14.2.
Après :
Un exemple de l'overlay d'erreur de Next.js après la version 14.2.
En février, l'équipe React a annoncé la prochaine sortie de React 19. Pour préparer React 19, nous travaillons à intégrer les dernières fonctionnalités et améliorations dans Next.js, et prévoyons de publier une version majeure pour orchestrer ces changements.
Les nouvelles fonctionnalités comme les Actions et leurs hooks associés, qui étaient disponibles dans Next.js via le canal canary de React (React canary channel), seront désormais accessibles à toutes les applications React (y compris les applications côté client uniquement). Nous sommes impatients de voir une adoption plus large de ces fonctionnalités dans l'écosystème React.
[Docs] Nouvelle documentation sur l'optimisation vidéo (PR).
[Docs] Nouvelle documentation sur instrumentation.ts (PR)
[Fonctionnalité] Nouvelle prop overrideSrc pour next/image (PR).
[Fonctionnalité] Nouvel argument revalidateReason pour getStaticProps (PR).
[Amélioration] Refonte de la logique de streaming, réduisant le temps de streaming des pages en production (PR).
[Amélioration] Prise en charge des actions serveur imbriquées (Nested Server Actions) (PR).
[Amélioration] Prise en charge de la localisation dans les sitemaps générés (PR).
[Amélioration] Améliorations visuelles des journaux de développement et de build (PR)
[Amélioration] La protection contre les décalages (Skew protection) est stable sur Vercel (Docs).
[Amélioration] Rendre useSelectedLayoutSegment compatible avec le routeur de pages (Pages Router) (PR).
[Amélioration] Ignorer les avertissements metadataBase lorsque les URL absolues n'ont pas besoin d'être résolues (PR).
[Amélioration] Correction des actions serveur qui ne se soumettaient pas sans JavaScript activé lors du déploiement sur Vercel (PR)
[Amélioration] Correction d'une erreur concernant une action serveur introuvable dans le manifeste des actions si déclenchée après une navigation hors de la page référente, ou si utilisée dans un segment de route parallèle inactif (PR)
[Amélioration] Correction des imports CSS dans les composants chargés par next/dynamic (PR).
[Amélioration] Avertissement lorsqu'une image animée manque la prop unoptimized (PR).
[Amélioration] Affichage d'un message d'erreur si images.loaderFile n'exporte pas une fonction par défaut (PR)
Next.js compte désormais plus d'un million de développeurs actifs mensuels. Nous sommes reconnaissants du soutien et des contributions de la communauté. Rejoignez la conversation sur GitHub Discussions, Reddit, et Discord.
Next.js est le résultat du travail combiné de plus de 3 000 développeurs individuels, de partenaires industriels comme Google et Meta, et de notre équipe principale chez Vercel. Cette version a été rendue possible par :
