App Router includes unused CSS module in unrelated routes (bundle analyzer + runtime)

[t18n]

Link to the code that reproduces this issue

https://github.com/t18n/next-js-app-router-css-bundle-repro/tree/main

To Reproduce

1. pnpm install
   2.pnpm build:analyzer
2. Open http://localhost:4000/ and check the analyzer output for dashboard and dashboard/users
3. Note Button.module.scss is included and loaded on those routes

Current vs. Expected behavior

• Expected: Button.module.scss only loads on home and not-found routes where Button is used.

• Actual: Button.module.scss is included and loaded for dashboard and dashboard/users, and blocks render.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:40 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 24.6.0
  npm: 11.5.1
  Yarn: 1.22.22
  pnpm: 10.24.0
Relevant Packages:
  next: 16.1.6 // Latest available version is detected (16.1.6).
  eslint-config-next: N/A
  react: 19.2.3
  react-dom: 19.2.3
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

CSS, Turbopack

Which stage(s) are affected? (Select all that apply)

next build (local), Other (Deployed), next start (local)

Additional context

• Repro is local and also impacts production (CSS loads on unrelated routes and blocks render).
• On a larger project with 100+ components this adds ~11s blocking time on Lighthouse/CWV.

[Shanmukha27-web]

Thanks for looking into this.

I can confirm this is reproducible consistently and appears to be Turbopack-specific:

• Does not reproduce when Turbopack is disabled (experimental.turbo = false)
• Webpack scopes the CSS correctly to only the routes where the component is rendered
• With Turbopack, component-level CSS Modules are included in unrelated route chunks and block render

This has a significant production impact in larger apps (multiple seconds of render-blocking CSS).

If this issue is not already being worked on, I’d be happy to take it and work on a fix. Please let me know if that’s okay.

[dev-rohit-gupta]

Hi! I’ve been investigating this CSS behavior and wanted to confirm intent before prototyping a fix.

After testing production builds with both Turbopack and Webpack, this is not Turbopack-only. CSS from universal routes (specifically app/not-found) is promoted into a shared chunk and preloaded globally.

This creates a scaling issue in large apps:

• fallback CSS is render-blocking even on unrelated routes
• unused styles block paint
• Lighthouse blocking time grows with app size

Additionally, the preload for universal CSS appears before route-critical CSS, effectively prioritizing fallback styles over active route styles.

This looks like an architectural side effect of universal route hoisting rather than a bundler bug.

---

Evidence

Production dashboard route loading not-found CSS:

---

Is this preload behavior intentional for error/not-found safety, or unintended?
If intentional, would there be interest in a lower-priority or deferred loading strategy so route CSS remains unblocked?

Happy to investigate or prototype once direction is clarified.

[t18n]

Hi guys, any updates on this? Any advices on how to mitigate the issue?

Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!

[t18n]

Just wanted to confirm that I've tried to revert back to Webpack, and the blocking render CSS still include other pages, confirm what @dev-rohit-gupta said

[dev-rohit-gupta]

I confirmed that this is currently expected behaviour (architecture trade off) of next.js
In the App Router model, app/not-found and app/error are treated as part of the Global Shell availability. Since any route segment can potentially throw a 404 or an Error during streaming or navigation, Next.js eagerly preloads these fallback UI styles to ensure an instant, layout-shift-free transition to the error state.
Currently,What we can do is try keep not-found ultra lightweight, use tailwind utility class instead of other heavy libraries

[t18n]

@dev-rohit-gupta removing not-found.tsx from my repro actually eliminate the error, which confirm what you said. However, in my production application, removing it didn't help at all. Components from other pages still load eventhough it says Import Chain - No dependents found in Turbopack

Again, this doesn't seem like Turbopack issue since the CSS actually load and block the render.

Here is my current file structure (after removing all not-found.tsx pages)

├── [locale]
│   ├── ...
│   ├── (product)
│   │   ├── product-templates
│   │   ├── software-templates
│   ├── about-us
│   │   ├── layout.module.scss
│   │   └── page.tsx
│   ├── blog
│   │   ├── [slug]
│   │   ├── authors
│   │   ├── categories
│   │   ├── layout.tsx
│   │   ├── page.module.scss
│   │   └── page.tsx

│   └── utils
│       ├── ...
├── api
│   └── ....
├── favicon.ico
├── manifest.ts
├── robots.ts
├── sitemap.ts
└── types.ts

After removing the not-found page, run pnpm builld:analyze and look into the CSS analyzer again, the components are included exactly the same as before. For example, I would check [locale]/blog/[slug] and it would include also /product-templates, /software-templates and /about-us components as well. I also checked if the components are shared in the shared layout but they are not, only included in the page. Do you have any suggestions?

[robert-j-webb]

Hey I've been investigating this and I have found that this is WAI prefetching. My setup is to do a production build like

pnpm build && pnpm start

We need to Disable Prefetch in order to stop the importing of the button component and the index page. There are two places the index page is linked to where we need to disable prefetch.

Firstly, the not-found.tsx route is being pre-loaded in this application, so we need to replace the <Button> with <Link prefetch={false} ...>.

Secondly the <Header> component has a <LInk> to / that also needs to have prefetch disabled.

I wrote the code that demonstrates this as a PR to the reproduction repo: t18n/next-js-app-router-css-bundle-repro#1

Let me know if I misunderstood or missed something. I hope this explains it but if not I'm happy to dig deeper.

[dev-rohit-gupta]

@robert-j-webb thanks for testing and sharing the PR appreciate the investigation

I tried your changes locally, but unfortunately the issue still persists on my side.

Disabling <Link prefetch={false}> does reduce some extra page prefetching, but the CSS from unrelated routes is still being bundled and loaded even when there is no navigation or prefetch happening.

So it doesn’t seem to be only a prefetch problem.

From my testing, this looks more like an architectural behavior:

• not-found / error routes are treated as globally reachable
• their CSS is hoisted to shared chunks
• which makes it render-blocking

@t18n Removing not-found technically “fixes” the CSS load, but that hurts UX (blank/unstyled fallback), so it’s not really a practical solution.

For now, the only safe workarounds I’ve found are:

1. (Recommended) Use Tailwind utility classes in not-found
   → already global, zero extra CSS, no CLS

2. Dynamically import CSS modules
   → avoids hoisting but causes layout shift (CLS), so not production friendly

3. styled-jsx
   → similar behavior, still loaded at render time

So realistically the best approach today is just keeping not-found extremely lightweight and avoiding heavy component/library imports.

A proper fix probably needs a framework-level change (like lower-priority loading or optional CSS isolation), which feels more like a feature request than something we can fully solve at the app level.

Happy to keep experimenting if we find more clues 🙂