Universal route CSS preload causing render-blocking bloat in turbopack and webpack

[dev-rohit-gupta]

While analyzing a Turbopack CSS issue, I noticed that CSS from universal routes (specifically app/not-found) is being preloaded globally.

After testing production builds with both Turbopack and Webpack, this does not appear to be Turbopack-only. The same behavior occurs in both pipelines.

Reproduction summary

• Button.module.scss is only used in home + not-found
• dashboard routes do not import Button
• however, the CSS is still preloaded and render-blocking there

The preload link appears in unrelated routes:

<link rel="preload" href="/_next/static/...not-found...css" as="style">

This suggests universal route hoisting is promoting CSS into a higher shared chunk.

Impact

In small apps this is harmless, but in large apps it scales poorly:

• unused fallback CSS blocks paint
• CSS chunk size grows with app complexity
• Lighthouse blocking time increases

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

Question about intent

Before attempting a fix, I want to confirm:

Is this preload behavior intentional to optimize transitions, or an unintended side effect of the bundling heuristic?

If intentional, would there be interest in exploring an opt-out or heuristic tweak (e.g. lower-priority or deferred loading for universal error routes) so route-critical CSS remains unblocked?

Happy to prototype or explore implementation once design intent is clarified.

---

Related: #89252

[Dagris]

Yes, this is currently expected behavior (Architecture Trade-off), but your observation on scaling is valid.

The "Why" (Intent)

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.

• If these were lazy-loaded, a user hitting a 404 would likely see a blank screen or unstyled content while the browser fetches the new chunk, degrading the UX during a critical failure moment.

The Optimization Gap

However, you are absolutely right that for large applications, blocking the critical path of the successful render to optimize for the failure path is a suboptimal trade-off (Lighthouse impact).

Recommendations

1. Immediate Mitigation: Ensure your not-found.tsx is extremely lightweight. Avoid importing heavy UI libraries in that specific file; stick to Tailwind utility classes or inline styles to keep that hoisted chunk minimal.
2. Next Steps: Since you mentioned interest in prototyping a heuristic tweak , you should definitely open a Feature Request Issue with your findings. The core team would likely be open to moving these "universal routes" to a non-blocking loading strategy.

Hope this clarifies the "Intent" vs "Side effect" question

[dev-rohit-gupta]

Thanks for the clarification that makes sense.
I understand the intent behind treating app/not-found / app/error as part of the global shell to guarantee an instant, layout-shift-free transition during streaming or navigation failures.

My concern is mostly about the scaling trade-off, not the behavior itself. As apps grow, prioritizing the failure path on the critical render path of every successful route starts to become noticeable especially with:

• Render-blocking unused CSS
• Growing shared CSS chunks
• Lighthouse blocking time regressions
• fallback CSS being prioritized ahead of route-critical styles

I agree that lazy-loading error UI entirely would be a UX regression, but there may be a middle ground worth exploring for example:

• lower-priority preload (or non-blocking stylesheet) for universal error routes

• deferring error-route CSS until after route-critical CSS is applied

• or a heuristic/opt-out for applications that accept a brief fallback flash in exchange for better steady-state performance

I’ll open a dedicated feature request to explore this more formally and attach reproduction details + measurements.
Happy to prototype or experiment with a heuristic tweak if there’s interest from the core team.

Thanks again for confirming the intent this helped a lot in understanding whether this was a bug or an architectural trade-off.

[Dagris]

I'm glad it helped! If you don't mind, could you mark my answer as accepted answer so the thread status is not "Unanswered".

[samselikoff]

Hey @dev-rohit-gupta, Sam from the Next.js team here. Let me check with some others to make sure this is expected behavior. I'll follow up shortly.

[samselikoff]

@dev-rohit-gupta Seems we do preload the global 404 page, to prevent a blocking navigation in the event of a notFound() error. The CSS preloading should not block the current page's rendering though, and regarding the scaling concerns, there's only a single not-found page. So the size or complexity of your app shouldn't affect how much is preloaded.

Do you have a reproduction you could share where you're seeing the render-blocking CSS?