cssChunking: why is there no merge pass for CSS chunks with identical audiences?

[dlehmhus]

Summary

TL;DR: In loose mode (the default), every shared component's CSS ends up as its own render-blocking stylesheet, and as far as I can tell from the source there is no merge pass for CSS chunks at all, even when chunks are requested by exactly the same set of routes in the same order. Is that intentional, or is a merge pass for CSS just missing?

Our situation

Next 16.3.0, App Router, Turbopack. Fairly large app, zero-runtime CSS-in-JS, so every component file emits a small CSS module, about 288 of them across the app. The production build turns that into 114 CSS chunks, and our heaviest routes load between 56 and 74 stylesheets depending on whether you count error/not-found segments. 64 of the 114 chunks contain a single component's CSS. The smallest one is 35 bytes.

I built a repro/measurement setup while chasing this: https://github.com/dlehmhus/nextjs-turbopack-css-merge-ceiling. The script reads entryCSSFiles out of the client reference manifests and groups chunks by which routes actually request them.

What the chunker does (from reading the source)

At first I suspected our CSS-in-JS emission (it imports CSS as data: URIs), then next/dynamic, but synthetic trees kept chunking fine no matter what shape I gave them. So I ended up reading the chunker source on the v16.3.0 tag, and if I'm reading the Rust correctly, this is just how loose mode works:

• Style chunks go through make_style_production_chunks (turbopack-core/src/chunk/chunking/style_production.rs), which turns module batches into chunks 1:1. The ecmascript path in production.rs groups items by their chunk-group set and then merges under size heuristics. The style path doesn't seem to have any merge step at all.
• The CSS ChunkingConfig that next-core sets up is { max_merge_chunk_size: 100_000, ..Default::default() } (in crates/next-core/src/next_client/context.rs), so min_chunk_size and max_chunk_count_per_group are 0 and the size-driven merge triggers are off anyway.
• Batches themselves (module_graph/module_batches.rs) break at chunk-group-set boundaries, at shared modules (anything reachable from two batches gets extracted into its own batch), and at dynamic imports.

Why that explodes with a component library

The shared-module rule is the one that hurts. Import a component from two different places and its CSS becomes its own chunk, which means its own render-blocking request. For an app with a component library that's one request per shared component: our typography, spinner and button primitives all pay it. Components imported from exactly one spot stay in their importer's batch, so our header+footer CSS travels as a single 19-module chunk. The fragmentation tracks sharing, not size and not audience.

What I don't understand is why nothing merges afterwards. 27 of our chunks are requested by exactly the same 39 segment entries, in a consistent order, contiguous in every route's stylesheet list. As far as I can tell, merging those into one file changes nothing except the request count. No route gets bytes it doesn't need, and no cascade order changes. The JS side already does this kind of same-audience grouping. For us it's the difference between roughly 57 CSS requests and 8 to 10.

What I ruled out

• It's not the data-URI emission. The repro compares plain .css imports with data:text/css imports in the same build, and they chunk identically in every shape I tried.
• cssChunking: { type: 'graph' } doesn't get there either. On our app it plateaus around 119 chunks for any requestCost above roughly 20k, and requestCost: 0 gives one chunk per module. Different algorithm, same outcome.
• next/dynamic makes it maximally bad. One dynamic() per component in the repro turns 250 modules into 250 chunks, which makes sense now, since dynamic imports are batch boundaries. But we barely use next/dynamic, so that's not our problem.

The question

Is the missing merge pass for CSS intentional (some ordering or correctness concern I'm not seeing), or just not implemented yet? If it's something you'd consider, chunks with identical chunk-group sets look like the safe first case, since they're contiguous and order-consistent everywhere they appear. Happy to share the measurement script and the full numbers from our app if useful.

Additional information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.5.0
  Available memory (MB): 49152
  Available CPU cores: 18
Binaries:
  Node: 24.18.0
  npm: 11.16.0
  Yarn: N/A
  pnpm: 10.33.4
Relevant Packages:
  next: 16.3.0
  eslint-config-next: N/A
  react: 19.3.0-canary-28cd4bb0-20260723
  react-dom: 19.3.0-canary-28cd4bb0-20260723
  typescript: 5.9.3
Next.js Config:
  output: N/A

Example

https://github.com/dlehmhus/nextjs-turbopack-css-merge-ceiling

[MILLERMARRU]

Worth separating two different things here, because they have different odds of getting fixed.

loose mode (the default) not merging same-audience chunks is by design, not a missing pass. From the source you already found, module_batches.rs splits out shared modules into their own batch specifically to keep cascade ordering safe across arbitrary import graphs, and style_production.rs maps batches to chunks 1:1 with no merge step afterward. That's a correctness-over-request-count tradeoff for the default mode, and I wouldn't expect it to change without a dedicated opt-in, since retrofitting a merge pass into loose risks the exact cascade-order bugs it's designed to avoid.

graph mode is that dedicated opt-in, and this is where your numbers get interesting. Per the config's doc comment, graph mode's whole job is to "analyze the most common style orderings across the application and produce shared chunks accordingly", with requestCost explicitly biasing toward "fewer, larger shared chunks" as it increases. Your 27 same-audience, order-consistent chunks are precisely the case that heuristic is supposed to catch. If bumping requestCost up doesn't move the count at all (you mentioned it plateaus around 119), that's graph mode not doing what its own doc comment says it should for this shape, which reads less like "the merge pass doesn't exist" (true for loose) and more like "the merge pass exists but its cost model isn't picking up your case" (a graph-mode gap).

I'd file two separate things if you go the issue route: a docs request for loose mode to state plainly that it doesn't merge (saves the next person your investigation), and a bug report specifically on graph mode's requestCost insensitivity for identical-chunk-group-set batches, with the plateau numbers you already have. The second one is the more actionable bug, since it contradicts graph mode's documented behavior rather than asking for new behavior in loose.