Turbopack production build duplicates shared client modules across chunks (no splitChunks-equivalent extraction)

[lkm36486938]

Goals

1. Add a shared-chunk extraction pass to Turbopack production builds (equivalent to webpack's splitChunks): a module reachable from many chunk groups should be emitted once into a shared chunk, instead of being copied into every group's chunk.
2. Make it size-independent — it should deduplicate a shared dependency composed of many small modules, not only a single large module (Turbopack already gives a large single module its own chunk).
3. Reduce total client JS for apps that code-split features which share a common dependency tree.

Non-Goals

1. Not asking to change dev-mode chunking (next dev uses lazy, per-request bundling; this is a production-build concern only).
2. Not requesting exact chunk-graph/filename parity with webpack — only that shared modules aren't physically duplicated.
3. Not asking to remove per-route / next/dynamic code splitting.
4. Not the server-side instanceof correctness bug ([Turbopack] Duplicate class definitions across route chunks, breaking instanceof #89192); that is the same underlying behavior but tracked separately as a bug.

Background

webpack's splitChunks extracts modules shared across chunk groups into shared chunks, so each module is emitted once. Turbopack's production chunking instead groups modules by the exact set of chunk groups that reference them, and has no usage-count-based extraction. As a result, when features import an overlapping-but-distinct subset of a shared dependency, the shared modules are duplicated across chunks.

Minimal reproduction (no external deps beyond Next/React — 40 small shared modules imported by four next/dynamic features, each using a different overlapping window):

https://github.com/lkm36486938/turbopack-shared-chunk-dup

Measured on next@16.2.10 (objective copy counts from .next/static/chunks):

Metric	Turbopack (next build)	webpack (next build --webpack)
modules in 1 chunk	8 of 40	40 of 40
modules in 2 chunks	21 of 40	0
modules in 3 chunks	11 of 40	0
total physical copies (40 modules)	83	40
avg copies per module	2.08	1.00

The effect scales with (shared-module count) × (number of chunk groups sharing them): a large dependency tree of small modules (e.g. a rich-text / math editor bundling KaTeX) imported by ~15–20 lazily-loaded feature entries duplicates the same modules ~15–20×, adding tens of MB of client JS. Turbopack's docs also note that production-optimized JS chunking is not yet fully implemented.

Current alternatives, all unsatisfactory:

• next build --webpack — deduplicates, but gives up Turbopack.
• Manual import restructuring / optimizePackageImports / barrel-splitting — partial, high-maintenance, and doesn't reliably deduplicate shared modules across chunk groups.

Proposal

Add a production chunking pass that extracts a module into a shared chunk when it is referenced by ≥ N chunk groups (or when extraction saves more than a byte threshold), even if the referencing chunk-group sets are not identical — analogous to webpack splitChunks minChunks / cacheGroups. In the current implementation this is where modules are bucketed by the exact chunk-group RoaringBitmap in turbopack-core/src/chunk/chunking/production.rs; the extraction would run before/alongside that bucketing. A config flag to opt in (and tune the threshold) would be a reasonable first step.

[Mr-Nilarnab]

@lkm36486938

This is a well-written proposal, and the reproduction makes the trade-off very clear.

The metrics demonstrate that Turbopack currently optimizes large individual modules into separate chunks, but doesn't perform a second pass to extract shared dependency graphs that are referenced across multiple chunk groups. As a result, many small shared modules are emitted multiple times, increasing the total client JavaScript shipped.

The comparison with webpack's splitChunks is particularly useful:

Metric	Turbopack	webpack
Modules emitted once	8/40	40/40
Total physical copies	83	40
Average copies per module	2.08×	1.00×

That provides an objective demonstration of the current behavior rather than relying solely on bundle size comparisons.

I also agree with the scope you've outlined:

• This is a production build optimization, not a development-mode concern.
• It shouldn't require reproducing webpack's exact chunk graph or filenames.
• The goal is simply to avoid emitting identical modules multiple times when extracting them into a shared chunk would reduce the overall client payload.

A configurable extraction threshold (similar in spirit to webpack's minChunks and cacheGroups) also seems like a reasonable design, allowing projects with different priorities to balance additional requests against reduced download size.

Since the Turbopack documentation already notes that production chunking is still evolving, this proposal feels like a natural optimization for future work. The included reproduction repository and quantitative measurements should make it much easier for the team to evaluate the impact and compare alternative chunking strategies.

Overall, this seems like a valuable enhancement request, especially for applications with many lazily loaded features that share substantial dependency trees composed of smaller modules.

[sentience]

This proposal matches what we've been measuring on Next.js 16.2.11, Pages Router, exactly — the "buckets by the exact set of chunk groups, no usage-count extraction" framing is spot on, and it accounts for every behaviour we saw. Adding a corroborating repro from a slightly different angle plus the user-facing cost, in case it's useful for the case.

Repro: https://github.com/cultureamp/turbopack-chunk-duplication-repro

Corroboration — and a static-route repro (no next/dynamic)

@lkm36486938's repro uses four next/dynamic features as the chunk groups. Ours uses plain static page entries instead — 12 Pages Router routes, each statically importing a different overlapping subset of date-fns (no next/dynamic, no dynamic import()). Same duplication, which confirms this is about chunk groups in general, not a next/dynamic artifact.

The "exact chunk-group set" bucketing you describe predicts precisely what we see:

• A dependency (or subset) used by the identical set of routes → same bucket → one shared chunk (Turbopack handles this fine, same as webpack).
• The same modules used by different overlapping subsets → different buckets → duplicated per route.

It's also size-independent exactly as you note: a single large module does get its own shared chunk; it's the many-small-module dependencies (date-fns, react-aria, prosemirror, design systems) that duplicate, because their small members land in different exact-set buckets per route.

Numbers (next@16.2.11, React 19)

	Turbopack	webpack
date-fns submodule copies (Σ embeddings over chunks)	312	166
core helpers (constructFrom, toDate, constants)	in all 12 route chunks	≤ 8, in shared chunks
Total client JS	284 KB gzip	164 KB gzip

Same shape as your 83-vs-40 physical-copy count.

The user-facing cost: multi-route navigation

One dimension worth adding to the motivation — the impact isn't on first load, it's on navigation:

	Turbopack	webpack
First page visit	117 KB gzip	146 KB gzip
Full session (visit all 12 routes, browser cache reuse)	269 KB gzip	164 KB gzip (+64%)
— per additional route navigated	~14 KB gzip	~2 KB gzip

First-page-load is actually smaller under Turbopack (webpack's shared chunk carries the union of every route's usage). The cost lands on multi-route sessions: because the shared code isn't extracted into a cacheable shared chunk, each new route re-downloads its own copy (~14 KB/route here) instead of reusing one already cached (~2 KB/route under webpack). So the proposal's shared-extraction pass would primarily improve cross-route navigation payload and total client JS, not initial load.

At real-world scale

On a 13-route production app (same Next 16, same config, only the bundler differs) the same mechanism inflates total client JS ~+84% gzip, with the heavy many-small-module deps copied per route — consistent with the "scales with (shared-module count) × (chunk groups sharing them)" scaling you describe.

Strong +1 on the proposal — a splitChunks-style extraction pass (with a minChunks-like threshold, at the production.rs bucketing step you point to) would resolve this for us. In the meantime next build --webpack is our workaround.

[sampoder]

Thanks @lkm36486938 for the original post! And @sentience for the expansion.

I've just put up an experimental PR to give users more options here: #96398.

This allows you to configure minChunkSize. The reason why these small modules get loaded as part of multiple chunks is they are often to small to exist on their own in Turbopack's chunker so we sweep them up into a remainder chunk. This is because every additional request to fetch a new chunk has a cost itself. So for small chunk items, even if shared, we choose to put them into the remainder chunk.

I found that setting minChunkSize to 0 KB on @sentience's reproduction brought the client side JavaScript and enabling experimental.turbopackSharedRuntime brought the full session down to 126 KB, with only 1 KB extra per route.

This was my next.config.js:

module.exports = { 
    productionBrowserSourceMaps: true,
    experimental: {
        turbopackChunking: {
            minChunkSize: 0,
        },
        turbopackSharedRuntime: true,
    }
}

And this was the results:

full session (all routes, browser cache reuse): 126 KB gzip
  -> per additional route: 1 KB gzip
date-fns submodule embeddings (sum over chunks): 52
  most-copied helpers: startOfWeek×1  differenceInHours×1  differenceInMinutes×1  addDays×1  endOfMonth×1

Compared to Webpack:

full session (all routes, browser cache reuse): 165 KB gzip
  -> per additional route: 2 KB gzip
date-fns submodule embeddings (sum over chunks): 166
  most-copied helpers: addDays×8  addMonths×6  subMonths×6  addWeeks×6  setDay×6

[sampoder]

Additionally, I did want to say that switching to App Router would likely also improve performance. For example, we have a new option experimental.turbopackGenerateComponentChunks that counter-balances our aggressive merging at times by keeping the components of each merged chunk so if you've already loaded part of it, you don't have to load the full thing. I had Claude generate an app-router equivalent of your fixture and it was reporting about 165KB of client-side JS when component chunks are enabled compared to about 200KB with them disabled (both numbers from Turbopack).

experimental.turbopackGenerateComponentChunks supports chunks loaded through React Flight on navigation (App Router) and also dynamic imports.

[sampoder]

Just adding on to my message above, I tried experimental.turbopackGenerateComponentChunks with @lkm36486938's reproduction and I found that it loaded 163.2 KB of client-side JS in the session in 13 requests (across the session). Compared to Webpack's 163.6 KB in 15 requests. Seems like it closes the gap!

[sentience]

Hi @sampoder! Thanks for getting this experimental feature into 16.3.0! I'm looking forward to trying it.

I notice that the documentation for this feature only appears under the App Router docs. It's not shown in the Pages Router docs. Is that intentional? Is this an App Router only feature?

[sampoder]

Heuristics & size thresholds are also supported on pages router! I'll port the documentation over. Component chunks aren't supported, however.

[lkm36486938]

Thanks, @sampoder, @Mr-Nilarnab, and @sentience!

[gurkerl83]

Maybe this is relevant in the discussion https://github.com/project-millipede/next-slug-splitter

[mischnic]

This fixes a particular case with Pages router: #97664