Turbopack dans Next.js 16.3 : moins de mémoire, un cache disque pour les builds

Le compromis mémoire de Turbopack rattrapé

Turbopack met en cache le résultat de chaque compilation pour ne jamais retravailler un fichier inchangé. Le compromis assumé depuis le lancement : plus de mémoire retenue en échange de moins de CPU. Problème, en session de développement longue, avec un IDE, un typechecker et un agent de code qui tournent en parallèle, cette mémoire retenue finit par peser lourd.

Next.js 16.3 introduit l'éviction mémoire : Turbopack peut désormais retirer du cache en mémoire les résultats déjà persistés sur disque (une fonctionnalité posée en 16.1), au lieu de garder indéfiniment chaque route visitée. Sur le dashboard vercel.com, l'équipe Next.js mesure une empreinte mémoire qui passe de 21,5 Go à 2 Go après compilation de 50 routes ; sur nextjs.org, de 4 600 Mo à 840 Mo. Les deux options (cache disque + éviction) sont activées par défaut en 16.3, et peuvent être désactivées pour du diagnostic via un flag expérimental :

const nextConfig = {
  experimental: {
    turbopackMemoryEviction: false, // désactive l'éviction, valeur par défaut : 'full'
  },
};

Le cache disque arrive aussi sur next build

Le cache fichier persistant accélérait déjà next dev depuis la 16.1. Après plusieurs mois de rodage sur les sites internes de Vercel, il devient disponible pour next build. Turbopack lit les entrées déjà compilées sur disque avant de traiter les fichiers modifiés, ce qui profite particulièrement aux pipelines CI capables de faire persister le dossier .next d'un run à l'autre.

Les gains mesurés varient fortement selon la taille du projet et ce qui a changé entre deux builds : ×2,3 sur nextjs.org (21 s → 9,2 s), ×1,4 sur vercel.com/home (66 s → 46 s), et jusqu'à ×5,5 sur un plus petit projet comme vercel.com/geist (30 s → 5,5 s). La fonctionnalité reste derrière un flag expérimental :

const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForBuild: true,
  },
};

Un React Compiler porté en Rust

Le React Compiler est stable dans Next.js depuis la 16.0, mais uniquement sous forme de transform Babel — un goulot d'étranglement sur les grosses applications, le temps que le moteur JS traite chaque fichier. L'équipe React a publié un portage natif en Rust, que Turbopack intègre désormais en mode expérimental. Les premiers tests internes sur v0, une application React de grande taille, montrent des gains de compilation de 20 à 50 %.

const nextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

import.meta.glob, compatible Vite

Turbopack supporte désormais l'API import.meta.glob, jusque-là propre à l'écosystème Vite : importer un ensemble de modules par pattern, sans lister chaque chemin à la main.

const posts = import.meta.glob("./posts/*.mdx");
 
for (const path in posts) {
  const post = await posts[path]();
}

L'implémentation s'appuie sur le file watcher de Turbopack : ajouter ou retirer un fichier qui correspond au pattern déclenche une recompilation en dev. C'est le genre d'API directement utile pour un système de contenu par fichiers — proche, d'ailleurs, de ce que fait déjà ce portfolio pour charger content/blog/. Elle n'est disponible qu'avec Turbopack, pas avec l'option --webpack.

Ces changements sont documentés dans la série de billets publiée le 29 juin 2026 à l'approche de la version stable 16.3 ; à ce stade, les flags cités restent expérimentaux et valent surtout le détour sur de gros projets où le temps de build ou la mémoire dev deviennent un vrai point de friction.