Nous observions la maturation de Turbopack depuis son annonce en 2022, l'utilisant en mode dev depuis Next.js 14, et jetant des coups d'œil prudents aux flags "turbo" en CI. Quand Next.js 16 est sorti début 2025 avec Turbopack comme bundler de production par défaut, nous savions que la migration ne pouvait pas attendre plus longtemps. Nous avions trois projets clients sur Next.js 15 qui devaient être mis à jour, et je vais vous expliquer chaque changement significatif, les pièges que nous avons rencontrés, et les chiffres de performance que nous avons observés.

Ce n'est pas une reformulation des notes de version. C'est ce qui s'est réellement passé quand nous avons exécuté next build avec Turbopack sur de vraies bases de code avec une vraie complexité.

Table des matières

Next.js 16 Turbopack Production Builds: What Changed and How We Migrated

Pourquoi Next.js 16 est un grand changement

Next.js 16 n'est pas simplement un numéro de version incrémenté. Il représente le changement le plus significatif de l'infrastructure de build depuis que le framework est passé des pages à l'App Router. La fonctionnalité phare est évidente : Turbopack remplace webpack comme bundler par défaut pour les builds de développement et de production.

Mais il y a plus. Next.js 16 inclut également :

  • React 19 comme version minimale supportée — pas de compatibilité avec React 18
  • Amélioration de la maturité du streaming et du prerendering partiel
  • Nouveaux paramètres de cache qui sont réellement sensés (ils ont appris de la réaction de Next.js 15 concernant le cache)
  • APIs de requête asynchrones entièrement appliquées — cookies(), headers(), et params sont tous asynchrones maintenant sans aucun support hérité synchrone
  • Exigence minimale Node.js 20 — Le support de Node 18 est supprimé

Pour les agences comme la nôtre qui font du développement Next.js, c'est le type de version qui affecte tout. Vous ne pouvez pas simplement augmenter le numéro de version et appeler ça un jour.

Ce qui a réellement changé avec Turbopack en production

Soyons spécifiques. Pendant Next.js 14 et 15, Turbopack était disponible pour next dev avec le flag --turbo. Les builds de production utilisaient toujours webpack. Next.js 15.3 a introduit un flag --turbopack expérimental pour next build, et au moment où 16 est sorti, cela est devenu le défaut.

Voici ce qui est fondamentalement différent dans la façon dont Turbopack gère les builds de production par rapport à webpack :

Architecture de compilation incrémentale

Webpack traite tout votre graphique de dépendances à chaque build. Turbopack utilise un système de cache au niveau des fonctions construit sur le moteur Turbo (écrit en Rust). En pratique, cela signifie que les builds suivants ne recompilent que ce qui a réellement changé. Votre premier build pourrait ne pas être dramatiquement plus rapide, mais votre deuxième, troisième et dixième builds le seront.

Améliorations du tree shaking

Le tree shaking de Turbopack opère à un niveau plus granulaire que celui de webpack. Nous avons remarqué que les bundles de nos clients étaient en moyenne 8-15% plus petits sans aucun changement de code. Les plus grands gains proviennent du traitement des fichiers barrel — Turbopack est vraiment meilleur pour éliminer les réexportations inutilisées des fichiers index.

Résolution de modules

Turbopack résout les modules différemment. C'est plus rapide, mais c'est aussi plus strict. Si vous aviez des chemins d'importation maladroits que webpack résolvait silencieusement (comme des extensions de fichiers manquantes dans certains cas limites, ou des chemins insensibles à la casse sur macOS qui cassent sur Linux), Turbopack les attrapera. Cela a causé environ 30% de nos problèmes de migration.

Stratégie de code splitting

L'algorithme de division de chunks est nouveau. Turbopack crée plus de chunks plus petits par défaut. Cela améliore généralement les performances de chargement pour les navigateurs modernes avec HTTP/2, mais cela peut augmenter le nombre total de requêtes. Nous avons vu le nombre de chunks augmenter d'environ 40% tandis que la taille totale du bundle diminuait.

SWC est maintenant obligatoire

Si vous vous acgrochiez encore à une configuration Babel, c'est terminé. Turbopack utilise exclusivement SWC pour la transformation. C'était déjà la direction que les choses prenaient, mais Next.js 16 supprime tout recours à Babel entièrement.

Benchmarks de performance de build

Voici des chiffres réels de nos trois projets de migration. Ce ne sont pas des benchmarks synthétiques — ils proviennent d'applications clients réelles exécutées dans notre pipeline CI sur GitHub Actions (Ubuntu, runners 4 vCPU, 16GB RAM).

Métrique Projet A (E-commerce) Projet B (Tableau de bord SaaS) Projet C (Site de contenu)
Pages/Routes 847 124 2,340
webpack build (Next 15) 4m 32s 1m 48s 6m 15s
Turbopack build (Next 16, cold) 3m 10s 1m 22s 4m 44s
Turbopack build (Next 16, warm cache) 1m 05s 28s 1m 52s
Changement de taille du bundle -12% -8% -14%
JS First Load (page d'accueil) -18KB -7KB -22KB
Pic mémoire du build 3.8GB → 2.9GB 1.6GB → 1.2GB 4.2GB → 3.1GB

Les nombres du cache chaud sont la véritable histoire. Une fois que Turbopack a construit votre projet une fois, les rebuilds incrémentiels sont dramatiquement plus rapides. Pour notre Projet C riche en contenu (qui utilise un CMS headless avec des milliers de pages générées statiquement), passer de 6+ minutes à moins de 2 minutes sur les builds en cache était significatif. C'est un vrai argent économisé sur les minutes CI.

Les améliorations de l'utilisation de la mémoire étaient également significatives. Le Projet A atteignait occasionnellement des erreurs OOM sur les runners CI plus petits avec webpack. Ce problème a disparu avec Turbopack.

Next.js 16 Turbopack Production Builds: What Changed and How We Migrated - architecture

Changements majeurs que vous devez connaître

Voici une liste des changements qui ont réellement cassé pendant nos migrations. Le guide de mise à niveau de Next.js 16 couvre certains d'entre eux, mais quelques-uns nous ont surpris.

1. Configuration Webpack personnalisée

C'est le gros. Si vous avez une clé webpack dans votre next.config.js, cela ne fonctionne plus. Turbopack a sa propre API de configuration sous turbopack dans la configuration Next.js. Pas tout a un mappage 1:1.

// next.config.js — AVANT (Next.js 15 avec webpack)
module.exports = {
  webpack: (config) => {
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'],
    });
    return config;
  },
};

// next.config.js — APRÈS (Next.js 16 avec Turbopack)
module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
};

2. APIs de requête synchrone supprimées

Next.js 15 a déprécié l'accès synchrone à cookies(), headers(), params, et searchParams. Next.js 16 les supprime entièrement. Si vous avez ignoré ces avertissements de dépréciation, vous allez passer un mauvais moment.

// AVANT — cela crash dans Next.js 16
export default function Page({ params }) {
  const { slug } = params;
  return <div>{slug}</div>;
}

// APRÈS
export default async function Page({ params }) {
  const { slug } = await params;
  return <div>{slug}</div>;
}

Cela semble trivial mais cela a touché plus de 200 composants à travers nos projets. Nous avons écrit un codemod pour gérer la plupart (plus d'informations ci-dessous).

3. React 18 n'est plus supporté

Next.js 16 nécessite React 19. Si vous avez des dépendances fixées à React 18, elles doivent être mises à jour. La plupart des bibliothèques bien entretenues avaient le support de React 19 à la mi-2025, mais nous avons rencontré quelques traînards.

4. Node.js 18 supprimé

Le minimum est Node.js 20. Mettez à jour vos images Docker, configurations CI et fichiers .nvmrc.

5. Changements next/image

La prop onLoadingComplete est complètement supprimée (était dépréciée depuis Next.js 14). Utilisez onLoad à la place. Le pipeline d'optimisation d'image utilise également une nouvelle bibliothèque sous-jacente, ce qui signifie que vos images optimisées en cache seront régénérées à la première requête.

Notre processus de migration étape par étape

Voici le processus réel que nous avons suivi. Nous avons d'abord fait le Projet B (le plus petit) comme test, puis avons abordé A et C.

Étape 1 : Audit des dépendances

Avant de toucher à Next.js, nous avons audité chaque dépendance pour la compatibilité React 19 et Node.js 20. Nous avons utilisé un simple script :

npx npm-check-updates --target latest --filter '/react|next/'

Nous avons également vérifié manuellement nos packages les plus critiques : notre SDK CMS headless, notre bibliothèque d'authentification et notre bibliothèque de composants UI.

Étape 2 : Mise à jour de Node.js

Nous avons mis à jour notre .nvmrc à 20.18.0 (dernier LTS à l'époque), mis à jour les Dockerfiles et vérifié les runners CI. Simple mais facile à oublier.

Étape 3 : Mise à niveau de React en premier

npm install react@19 react-dom@19 @types/react@19 @types/react-dom@19

Nous avons exécuté la suite de tests complète ici avant de continuer. React 19 a ses propres changements majeurs (suppression de forwardRef comme nécessité, ref est maintenant une prop régulière, le hook use() est stable). Nous avons corrigé ces problèmes isolément pour ne pas déboguer les problèmes de React et de Next.js simultanément.

Étape 4 : Exécuter le codemod Next.js

Next.js fournit un codemod de mise à niveau qui gère beaucoup des changements mécaniques :

npx @next/codemod@latest upgrade

Cela a géré environ 70% des migrations d'API asynchrone automatiquement. Ce n'est pas parfait — cela a eu du mal avec certains de nos modèles de composants serveur plus complexes — mais cela nous a économisé des heures.

Étape 5 : Mise à niveau de Next.js

npm install next@16

Étape 6 : Migration de next.config.js

C'était l'étape la plus longue pour le Projet A, qui avait une personnalisation webpack importante. Je couvrirai les traductions spécifiques dans la section suivante.

Étape 7 : Corriger les erreurs de build de manière itérative

Nous avons exécuté next build et travaillé à travers les erreurs une par une. Les messages d'erreur de Turbopack sont en fait meilleurs que ceux de webpack dans la plupart des cas — plus spécifiques, avec des chemins de fichiers plus clairs et des suggestions.

Étape 8 : Tests de régression visuelle

Nous utilisons Playwright pour les tests E2E et avons exécuté notre suite de tests de régression visuelle pour attraper toute différence de rendu. Nous avons trouvé deux problèmes : une différence d'ordre CSS (Turbopack traite les importations CSS dans un ordre légèrement différent de webpack) et une importation dynamique qui ne faisait pas correctement le code splitting.

Étape 9 : Validation de la performance

Nous avons comparé les scores Lighthouse et les Core Web Vitals avant et après. Chaque projet s'est amélioré ou est resté neutre. Pas de régressions.

Traductions de configuration Webpack

Cette section est pour les équipes avec des configurations webpack personnalisées. Voici comment les modèles courants se traduisent en Turbopack.

Loaders personnalisés

// Équivalent Turbopack pour les loaders personnalisés
module.exports = {
  turbopack: {
    rules: {
      '*.md': {
        loaders: ['raw-loader'],
        as: '*.js',
      },
      '*.graphql': {
        loaders: ['graphql-tag/loader'],
        as: '*.js',
      },
    },
  },
};

Alias de module

// Les alias de résolution fonctionnent de manière similaire
module.exports = {
  turbopack: {
    resolveAlias: {
      'old-package': 'new-package',
      // Vous pouvez aussi pointer vers des fichiers locaux
      '@legacy/utils': './src/utils/legacy.ts',
    },
  },
};

Ce qui ne se traduit pas

Certains plugins webpack n'ont simplement pas d'équivalents Turbopack pour le moment :

  • webpack.DefinePlugin — Utilisez env dans next.config.js ou les variables d'environnement directement
  • BundleAnalyzerPlugin — Le package @next/bundle-analyzer fonctionne avec Turbopack à partir de v16, mais le format de sortie a changé
  • Fractionnement personnalisé des chunks via splitChunks — Turbopack gère cela automatiquement et n'expose pas le même niveau de contrôle. Honnêtement, les valeurs par défaut sont suffisantes pour la plupart des projets.
  • webpack.IgnorePlugin — Utilisez resolveAlias pour pointer les importations vers des modules vides

Gestion des packages tiers

Quelques packages ont causé des problèmes pendant la migration :

@sentry/nextjs — Nécessite v9+ pour la compatibilité Turbopack. Les versions antérieures se connectaient aux éléments internes de webpack. La mise à jour était simple mais nécessitait des changements de configuration.

next-intl — Fonctionne bien après mise à jour vers la dernière version. L'API du plugin s'est adaptée proprement.

@vanilla-extract/next-plugin — C'était notre plus gros casse-tête sur le Projet B. Le plugin webpack de Vanilla Extract n'avait pas d'équivalent Turbopack jusqu'à leur version 2.0. Nous avons dû attendre ou considérer des alternatives. Nous avons attendu.

Packages de fichiers barrel — Tout package qui exporte des centaines de composants à partir d'un seul fichier index (regardez les bibliothèques d'icônes) se fait maintenant faire du tree shaking beaucoup plus agressivement. C'est une bonne chose, mais nous avons vu un cas où une icône référencée dynamiquement n'était pas incluse. Nous avons basculé de recherches d'icônes basées sur des chaînes de caractères vers des importations directes, ce qui est de toute façon une meilleure pratique.

Considérations CSS et Tailwind

Si vous utilisez Tailwind CSS (et la plupart de nos projets le font), la migration est en grande partie sans problème. Tailwind v4 fonctionne très bien avec Turbopack. Mais il y a quelques choses à surveiller :

Ordre des importations CSS

Turbopack traite les importations CSS dans un ordre déterministe mais différent de webpack. Si vous comptiez sur l'ordre d'importation pour la spécificité (et vous ne devriez pas, mais soyons honnêtes — nous finissons tous là), vous pourriez voir des différences visuelles. Nous avions un projet où un reset global était surpassé par une CSS de composant parce que l'ordre d'importation s'est inversé.

La correction était l'utilisation explicite de @layer dans notre CSS, ce que nous aurions dû faire de toute façon.

Modules CSS

Les modules CSS fonctionnent de manière identique. Pas de changements nécessaires. Les noms de classe générés ressemblent à différents (plus courts, en fait), mais c'est cosmétique à moins que vous ne fassiez quelque chose de bizarre comme cibler les noms de classe générés dans les tests.

PostCSS

Les fichiers de configuration PostCSS sont toujours respectés. Votre postcss.config.js continue de fonctionner. Pas de changements nécessaires ici.

Mises à jour du déploiement et du pipeline CI

Nos cibles de déploiement sont principalement Vercel et AWS (via SST/OpenNext). Voici ce qui a changé :

Vercel : Détecté automatiquement Next.js 16 et utilisé Turbopack. L'intégration du cache de build fonctionne d'emblée. Nos temps de build sur Vercel ont chuté encore plus dramatiquement que sur CI local parce que Vercel a une intégration profonde avec la couche de cache de Turbopack. Le Projet C est passé de ~8 minutes à ~2.5 minutes sur Vercel.

AWS/OpenNext : Nécessaire de mettre à jour vers OpenNext 4.x, qui a ajouté le support de la sortie Turbopack. Le format de sortie a légèrement changé — la structure du répertoire .next est réorganisée — donc tous les scripts post-build qui référençaient des chemins de fichiers spécifiques avaient besoin de mise à jour.

Builds Docker : Si vous construisez Next.js dans Docker, mettez à jour votre image de base vers Node 20+ et soyez conscient que le répertoire de cache de Turbopack (.next/cache/turbopack) devrait être inclus dans votre stratégie de cache de couche Docker. Nous avons ajouté une couche COPY spécifique pour cela.

# Optimiser la mise en cache des couches Docker pour Turbopack
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
# Montage de cache pour Turbopack
RUN --mount=type=cache,target=/app/.next/cache \
    npm run build

Quand vous ne devriez pas migrer pour le moment

Je ne veux pas peindre cela comme tout en rose. Il y a des raisons légitimes de rester sur Next.js 15 pour le moment :

  • Dépendance heavy de plugins webpack : Si votre build dépend de 3+ plugins webpack personnalisés qui n'ont pas d'équivalents Turbopack, le coût de la migration pourrait ne pas en valoir la peine pour le moment.
  • Monorepo avec configuration webpack partagée : Si vous partagez la configuration webpack entre les projets Next.js et non-Next.js dans un monorepo, diviser cette configuration est un travail supplémentaire.
  • Exigences de stabilité : Next.js 16.0 est stable, mais 16.1 et 16.2 ont corrigé des bugs réels. J'attendrais au moins 16.2+ avant de migrer tout ce pour lequel vous ne pouvez pas tolérer les temps d'arrêt.
  • Dépendances héritées coincées sur React 18 : Si une dépendance critique n'a pas ajouté le support de React 19, vous êtes bloqué quoi qu'il en soit.

Pour les équipes qui font du développement de CMS headless, la migration est généralement plus fluide parce que les sites axés sur un CMS ont tendance à avoir des configurations de build plus simples.

FAQ

Turbopack est-il assez stable pour la production dans Next.js 16 ?

Oui. Turbopack a été en développement pendant plus de trois ans, a été testé au combat en mode dev dans millions de projets Next.js, et a traversé une bêta prolongée dans les builds de production pendant Next.js 15.3-15.5. Nous l'exécutons en production depuis la version 16.0 sur plusieurs sites clients sans aucun problème lié au bundler. Cela dit, si vous êtes spécifiquement sur 16.0, mettez à jour vers 16.2+ où plusieurs bugs de cas limites ont été résolus.

Puis-je toujours utiliser webpack avec Next.js 16 ?

Non, pas en tant que bundler principal. Turbopack est le seul bundler supporté dans Next.js 16. Si vous avez absolument besoin de webpack, vous devrez rester sur Next.js 15, qui recevra des patches de sécurité jusqu'à début 2026. Vercel a clairement indiqué que le support de webpack dans Next.js est terminé.

Combien plus rapide est Turbopack comparé à webpack pour les builds de production ?

Sur les builds à froid (pas de cache), nous avons vu des améliorations de 20-30%. Sur les builds chauds/en cache, l'amélioration saute à 50-70%. Les chiffres exacts dépendent fortement de la taille du projet, du nombre de routes et de la quantité de génération statique qui se produit. L'utilisation de la mémoire a également chuté de 20-30% de manière cohérente dans nos projets.

Dois-je réécrire mon next.config.js pour Turbopack ?

Si vous avez une configuration webpack personnalisée dans votre next.config.js, oui — ces blocs doivent être traduits au format de configuration turbopack. Si vous utilisez seulement les options de configuration Next.js standard (images, redirects, rewrites, variables d'environnement), elles fonctionnent exactement de la même manière. L'effort de migration est proportionnel au nombre de configuration webpack personnalisée que vous avez.

Mon pipeline CI/CD existant fonctionnera-t-il avec Next.js 16 ?

Principalement oui. Les principales choses à mettre à jour sont : version Node.js (minimum 20), tout script qui référence des fichiers de sortie spécifiques à webpack, et toute stratégie de cache qui cible .next/cache/webpack. Vous voudrez mettre en cache .next/cache/turbopack à la place. Si vous déployez sur Vercel, tout est géré automatiquement.

Turbopack supportet-il toutes les mêmes fonctionnalités que webpack dans Next.js ?

Pour les fonctionnalités spécifiques à Next.js, oui — App Router, Pages Router, routes API, middleware, ISR, SSG, SSR fonctionnent tous. Pour la configuration webpack personnalisée, il y a environ 90% de parité de fonctionnalités. Les lacunes restantes concernent surtout les plugins webpack de niche et les stratégies de fractionnement de chunks hautement personnalisées. Consultez la documentation de compatibilité Turbopack pour votre cas d'usage spécifique.

Dois-je migrer vers Next.js 16 ou considérer des alternatives comme Astro ?

Cela dépend de votre cas d'usage. Si vous construisez des applications hautement interactives avec une gestion d'état complexe, Next.js 16 est un choix fort et les améliorations de Turbopack rendent l'expérience développeur significativement meilleure. Si vous construisez des sites riches en contenu avec une interactivité minimale, Astro reste une excellente alternative avec son modèle d'hydratation partielle. Nous avons été construire avec les deux et choisir en fonction des exigences du projet. Si vous êtes incertain, contactez-nous et nous pouvons vous aider à évaluer.

Quel est le temps minimum nécessaire pour migrer une application Next.js 15 de taille moyenne vers 16 ?

Pour une application typique de taille moyenne (50-200 routes, dépendances standard, configuration webpack minimale), budgétisez 2-4 jours de temps de développeur. Cela inclut les mises à jour de dépendances, les migrations d'API asynchrone, les tests et la vérification du déploiement. Si vous avez une configuration webpack extensive personnalisée ou des dépendances héritées, cela pourrait prendre une semaine ou plus. Notre équipe chez Social Animal offre des services de migration si vous préférez ne pas brûler le sprint de votre équipe sur le travail d'infrastructure.