Turbopack chunking : optimiser le JavaScript de vos sites web
Le dilemme du bundler
Ouvrez l'inspecteur réseau de n'importe quel site Next.js. Vous verrez une liste de fichiers JavaScript aux noms aléatoires : 36wnellv-yn9q.js, 0wr0vk03pvu0l.js. Ce sont des chunks — des morceaux de code que Turbopack génère pour servir votre application.
Le chunking, c'est l'art de décider quel code va dans quel fichier. Et c'est un problème bien plus complexe qu'il n'y paraît.
La tentation naturelle, c'est de tout mettre dans un seul fichier. Après tout, un seul fichier = une seule requête HTTP, et une fois en cache, toutes les navigations sont instantanées. Sur nextjs.org, ça représenterait 1.09 MB et 355 modules dans un seul chunk. Problème : chaque visiteur télécharge le code de toutes les pages, même s'il ne visite que l'accueil. Plus le site grandit, plus chaque page devient lourde.
L'autre extrême, c'est un chunk par module. 355 chunks individuels. Plus jamais de code sur-commandé. Mais 355 requêtes HTTP, même multiplexées en HTTP/2, ça ralentit le chargement — chaque requête a son overhead, et la compression gzip fonctionne mal sur des fichiers trop petits.
Le défi est posé : moins de requêtes ou moins de code ? Les deux objectifs se tirent la bourre.
La solution : les chunk groups
Turbopack introduit une abstraction qui change la donne : le chunk group. Un chunk group est un ensemble de chunks chargés ensemble sur une même route. Les chunks de /home forment un groupe ; ceux de /blog en forment un autre.
L'idée est simple mais puissante : on ne fusionne jamais deux chunks qui appartiennent à des groupes différents. Puisque tous les chunks d'un même groupe sont toujours chargés ensemble, les fusionner n'ajoute rien que la page n'allait de toute façon pas télécharger. Problème réglé, presque.
Reste la question du cache. Imaginez deux chunks : A (le footer, utilisé sur toutes les pages) et B (un composant vidéo, uniquement sur l'accueil). Si on les fusionne pour l'accueil, un visiteur qui va ensuite sur la page "Mentions légales" devra re-télécharger tout le fichier fusionné. Il a maintenant téléchargé A deux fois.
| Navigation | Changement requêtes | Code téléchargé |
|---|---|---|
| A → A | 0 | 0 |
| A → A+B | 0 | +A |
| A+B → A | 0 | +A |
| A+B → A+B | -1 | 0 |
Quand fusionner devient rentable. La seule navigation où la fusion est gagnante, c'est quand les deux pages ont besoin des deux chunks. Sinon, le visiteur paie un surcoût.
Turbopack pondère ces scénarios par leur probabilité. Par défaut, il estime que 2/3 des sessions ne durent qu'une page, et 1/3 en font deux ou plus. Ce ratio pilote la décision de fusion.
Les résultats sur nextjs.org
Les chiffres parlent d'eux-mêmes. Voici la comparaison entre trois stratégies de chunking sur une série de navigations identiques :
| Navigation | Sans fusion | Défauts Turbopack | Tout fusionner |
|---|---|---|---|
| Page d'accueil (initiale) | 363.6 KiB (76 req.) | 344.2 KiB (24 req.) | 315.3 KiB (6 req.) |
| /blog | 35.0 KiB (4) | 35.0 KiB (3) | 34.0 KiB (2) |
| /blog/next-16-3-turbopack | 6.0 KiB (2) | 8.7 KiB (1) | 38.3 KiB (1) |
| /learn | 7.4 KiB (5) | 6.6 KiB (2) | 6.6 KiB (2) |
| /learn/dashboard-app | 109.6 KiB (3) | 115.0 KiB (3) | 142.0 KiB (1) |
| /showcase | 24.6 KiB (2) | 25.5 KiB (2) | 25.0 KiB (1) |
| /docs | 15.4 KiB (4) | 19.9 KiB (3) | 48.8 KiB (2) |
| Total | 561.6 KiB (96 req.) | 554.8 KiB (38 req.) | 610.0 KiB (15 req.) |
Les défauts de Turbopack coupent les requêtes de plus de moitié tout en téléchargeant légèrement moins de code. La fusion maximale réduit encore les requêtes à 15, mais au prix de 10% de code supplémentaire sur les navigations longues.
Les nouveautés de Next.js 16.3
Le chunking classique a deux limitations : il est décidé à la compilation, et il doit deviner comment les visiteurs naviguent. L'été 2026, Sam Poder (stagiaire chez Vercel) a travaillé sur trois axes qui lèvent ces verrous.
Generate Component Chunks : le chunking réactif
Plutôt que de choisir entre chunks mergés ou chunks séparés, Turbopack émet les deux versions. Le runtime côté navigateur sait exactement ce qui est déjà en cache et choisit la version la plus économique :
// next.config.ts
const nextConfig = {
experimental: {
turbopackChunking: {
generateComponentChunks: true,
},
},
};
Si le visiteur a déjà A en cache, le runtime ne télécharge que B. S'il a déjà A+B, il ne télécharge rien. Les navigations logicielles chargent moins de code inutile, et on récupère les bénéfices de la fusion sans le coût de navigation.
L'équipe explore aussi la directive HTTP only-if-cached, qui permettrait d'étendre ces améliorations aux visiteurs qui reviennent après avoir quitté le site.
Analytics-based chunking : votre trafic dicte la stratégie
Le ratio 2/3 (sessions d'une page) est une estimation par défaut raisonnable pour beaucoup de sites, mais pas forcément pour le vôtre. Si vous connaissez le comportement réel de vos visiteurs, vous pouvez maintenant le paramétrer :
// next.config.ts
const nextConfig = {
experimental: {
turbopackChunking: {
// Ratio de sessions à une page (0-1). 0.67 par défaut.
firstPageLoadPriority: 0.7,
// Pages prioritaires : on fusionne plus agressivement
priorityRoutes: ['/product', '/checkout'],
// Groupes de routes souvent visitées ensemble
clusters: [
['^/blog/.*', '^/learn/.*'],
['^/product/.*', '^/cart/.*'],
],
},
},
};
- firstPageLoadPriority : plus la valeur est haute, plus on optimise pour la première page (le bounce rate de votre site est un bon point de départ).
- priorityRoutes : liste des pages dont la vitesse de chargement est critique.
- clusters : groupes de routes souvent visitées ensemble. Les chunks chevauchants sont fusionnés plus agressivement à l'intérieur d'un cluster.
Tree-shaking CJS et runtime partagé
Deux fonctionnalités plus silencieuses mais tout aussi impactantes :
Tree-shaking CJS. Jusqu'à présent, Turbopack ne savait tree-shaker que les modules ESM. Le code mort dans les modules CommonJS (require) était systématiquement expédié au client. Avec le flag experimental.turbopackCjsTreeShaking, ce n'est plus le cas. Leurs travaux ont aussi amélioré le support des barrel files dans les imports dynamiques.
Runtime partagé. Auparavant, chaque page embarque sa propre copie du runtime Turbopack. Avec experimental.turbopackSharedRuntime, un seul runtime est partagé entre toutes les pages. Pour votre site, ça signifie une requête bloquante en moins et environ 10 KB de JavaScript économisés sur chaque navigation après la première. Les deux flags seront activés par défaut dans une future version de Next.js.
Pourquoi c'est important pour votre site vitrine ou e-commerce
Si vous lisez cet article, vous êtes probablement en train de développer ou d'optimiser un site web. Vitrine, e-commerce, SaaS, peu importe : le JavaScript est souvent le maillon faible des performances perçues.
Quelques chiffres pour contextualiser :
- Seulement 55.9% des sites passent les trois Core Web Vitals en 2026 (source : Chrome UX Report).
- Une seconde de latence supplémentaire réduit les conversions de 7% dans l'e-commerce (source : Google/SOASTA).
- Les sites modernes dépendent de plus en plus de JavaScript, poussant la charge critique sur le main thread.
Le chunking n'est pas un détail d'implémentation : c'est un levier direct sur le Largest Contentful Paint (LCP), le First Input Delay (FID) et le Cumulative Layout Shift (CLS). Un site Next.js correctement chunké charge moins de code, plus intelligemment, et réagit plus vite.
Comment passer à l'action
- Mettez à jour votre projet vers Next.js 16.3+ :
npm install next@latest - Activez les flags dans
next.config.ts:turbopackCjsTreeShaking,turbopackSharedRuntime, etgenerateComponentChunks - Analysez votre trafic : quel est votre bounce rate ? Quelles sont les pages importantes ? Utilisez ces données pour paramétrer
firstPageLoadPriorityetpriorityRoutes - Mesurez l'impact : comparez le nombre de requêtes JS et le volume téléchargé avec votre configuration actuelle, sur les pages clés
- Itérez : ajustez les clusters si votre site a des parcours utilisateur bien identifiés (blog → article, fiche produit → panier → checkout)
Le chunking n'est pas un sujet qu'on règle une fois pour toutes. C'est un réglage continu qui dépend de votre audience, de votre trafic et de votre architecture. Avec Next.js 16.3, vous avez enfin les outils pour le faire proprement.
