Why Is cssChunking option enabled by default if It’s experimental?

[simonepizzamiglio]

Summary

Hi!

While reviewing the documentation for experimental.cssChunking, I noticed a bit of ambiguity and wanted to ask for clarification.

The docs mention that:

• cssChunking is experimental
• It’s not recommended for production
• But it’s also enabled by default

Because of this mix, I'm not entirely sure what the intended guidance is for production apps.

In this discussion:
#70168 (reply in thread)

It seems like the option to disable CSS chunking was introduced after users started reporting issues with the default behavior.

The documentation says:

Next.js will try to merge CSS files whenever possible to reduce the number of chunks and therefore the number of requests.

However, in my project the opposite is happening.

I’m working on a dynamic app that consumes content from a CMS, and enabling cssChunking produces significantly more CSS chunks instead of fewer:

• With cssChunking enabled: 28 CSS chunks
• With cssChunking disabled: 18 CSS chunks

So instead of merging, CSS appears to be splitting more aggressively in practice.

I'd love some clarification on:

1. Is it expected that production apps keep this feature enabled?
2. Should teams consider disabling it if they see the opposite of what the docs describe (e.g., more chunks instead of fewer)?

Any clarification would be super appreciated 🙂

Additional information

No response

Example

No response

[icyJoseph]

What sizes to the chunks have? I think there's an upper bound when the option is active.

[simonepizzamiglio]

cssChunking: false

cssChunking: true

I think I may have identified what’s happening.

We have a catch-all route at the root, and this route pulls in a large number of components.

When cssChunking is disabled, as you can see in the above screenshot, the bundler produces a single very large CSS file for that route (626 KB in my case). My guess is that since everything ultimately passes through the catch-all, Next.js ends up merging most of the CSS into that one big output file.

When cssChunking is enabled, that big CSS file disappears completely and is replaced by many smaller CSS chunks. So it looks like the bundler is splitting that large route-level CSS bundle into multiple pieces. The total CSS size is roughly the same, just distributed across more files. One side effect of this is that routes which do not fall under the catch-all route end up pulling in CSS they don’t actually need.

It would be great to know whether the current chunking strategy is optimized mostly for statically routed apps, or if dynamic CMS-driven apps are expected to benefit as well.