App Router bundles non-critical CSS from other routes into initial page CSS

[ChellappanRajan]

We have a large e-commerce application using the Next.js App Router with a structure similar to:

[locale]/
  page1/
    page.tsx
  page2/
    page.tsx
  ...

Most routes share a common layout.tsx, while some pages also include their own component-level styles.

The issue we are seeing is that CSS from components used in other routes/pages is still getting bundled into the homepage CSS, even when those components are not rendered initially. This increases the amount of non-critical CSS loaded during the first paint.

We already tried:

• next/dynamic
• Lazy loading below-the-fold components
• Route-level code splitting

However, the CSS for those lazy-loaded components still appears in the initial CSS bundle.

Our goal is to:

• Load only critical CSS required for the initial render
• Defer or split non-critical CSS
• Avoid bundling unrelated route/component styles into the homepage

Questions:

1. Is there any supported way to influence CSS chunking behavior in the App Router?
2. Can webpack configuration or custom plugins help control how style tags are generated/injected during build time?
3. Is this related to the CSS optimization behavior discussed in issue CSS Styles from unrelated layouts are merged if they have one CSS file in common #64773
4. Are there recommended strategies for granular CSS splitting in large-scale multi-locale applications?

[Saakhavat-Prime]

Review: Next.js App Router CSS Chunking — Community Answer Fact-Check

Verdict: Directionally reasonable, but it understates what's actually configurable. The claim "no supported configuration exists" is the weakest part — experimental.cssChunking is a real, documented option that directly addresses this.

---

1. CSS chunking control

Claim: No supported config to force CSS into separate files or prevent merging.

Verdict: ❌ Partially wrong.

experimental.cssChunking in next.config.js controls exactly this:

const nextConfig = {
  experimental: {
    cssChunking: 'strict', // try this first
  },
}

• true (default): Next.js merges CSS aggressively based on import-graph analysis to minimize requests. This is almost certainly why the homepage is pulling in other components' CSS.
• 'strict': Loads CSS in exact import order instead of merging — more/smaller chunks, but no cross-route leakage. This is the one most likely to fix the reported issue.
• false: Disables chunking entirely — one large bundle (worse for this use case).

This is the single biggest gap in the original answer. Test 'strict' before concluding nothing is configurable.

---

2. Webpack / custom plugins

Claim: Not supported, may break across releases.

Verdict: ✅ Correct.

The App Router's CSS pipeline runs through internal loaders/plugins tied to the build, and Turbopack increasingly handles CSS through its own internals that don't route through the standard webpack config at all. A hand-rolled competing extraction plugin is not realistically maintainable long-term. Good practical advice as written.

---

3. Relation to issue #64773

Claim: Yes, closely related.

Verdict: ✅ Correct, but worth being precise.

The actual fix (PR vercel/next.js#67373, by sokra) addressed global CSS leaking across chunk groups — specifically styles applied to unscoped selectors (e.g. body) rather than CSS Modules classes. The fix disallows merging global CSS with styles from other chunk groups, because the old chunking logic assumed all CSS only affects the elements it's meant to (an assumption CSS Modules enforce but plain global stylesheets don't).

That's relevant background, but it's narrower than "unrelated component CSS leaking into route bundles" — which is a broader, still-open complaint:

• One developer found that with a catch-all route, enabling cssChunking caused routes outside the catch-all to pull in CSS they didn't need.
• Another reported the chunking feature causing chunks to contain CSS unrelated to the current page — enough to trigger Lighthouse's "unused CSS" warning — with disabling the feature resolving it.

That second report matches the symptom described almost exactly, and it's still being discussed as unresolved in general form.

---

4. Recommendations (lean layouts, CSS Modules, route groups, dynamic imports)

Claim: Reasonable hygiene practices.

Verdict: ⚠️ Reasonable but incomplete — omits the two most directly relevant levers:

• experimental.cssChunking: 'strict' (see Added css using aphrodite #1)
• experimental.inlineCss — replaces <link> stylesheet tags with inline <style> tags in the <head>. Aimed squarely at "load only critical CSS," but:
  • Works best with atomic CSS (Tailwind) — output stays small regardless of how much UI grows.
  • Skip it if returning visitors matter — inlined CSS can't be cached separately from HTML and re-downloads every visit.
  • For larger CSS bundles, it increases TTFB since all CSS ships with every HTML response.
  • It does run on App Router (unlike optimizeCss/Critters — see below): supports both Webpack and Turbopack, with CSS precedence/deduping handled automatically by React 19.

const nextConfig = {
  experimental: {
    inlineCss: true, // all-or-nothing; not just "critical" CSS
  },
}

---

5. "No officially supported way to load only critical CSS while deferring dynamic component CSS"

Verdict: ✅ Correct — this is the honest bottom line.

True per-component critical-CSS extraction (à la Critters) is not supported on App Router: the optimizeCss/Critters approach relies on a library that doesn't support streaming, which is fundamental to how App Router renders. A Vercel team member confirmed this directly in the GitHub discussion. inlineCss is the closest sanctioned tool, but it's all-or-nothing (inlines everything, not just critical rules) and still experimental / not recommended for production per current docs.

---

Recommended next steps, in order

1. Set experimental.cssChunking: 'strict' and rebuild. Check whether the homepage bundle shrinks. Free to try, most likely fix for the described leakage.
2. Audit for global, unscoped selectors (styles on body, bare tags, or anything outside a CSS Modules class) — these are exactly what merges indiscriminately under the old chunking assumption.
3. If using Tailwind/atomic CSS, consider experimental.inlineCss for pages with mostly first-time visitors. Skip it if you depend on stylesheet caching for returning users.
4. For anything deeper (manual critical-CSS extraction, fine-grained chunk control), treat it as a userland post-build step (e.g. Beasties/Critters run against static output) rather than a Next.js config knob — and expect it to be fragile across Next.js versions, same conclusion as the original answer.

[ChellappanRajan]

Review: Next.js App Router CSS Chunking — Community Answer Fact-Check

Verdict: Directionally reasonable, but it understates what's actually configurable. The claim "no supported configuration exists" is the weakest part — experimental.cssChunking is a real, documented option that directly addresses this.

---

1. CSS chunking control

Claim: No supported config to force CSS into separate files or prevent merging.

Verdict: ❌ Partially wrong.

experimental.cssChunking in next.config.js controls exactly this:

const nextConfig = {

  experimental: {

    cssChunking: 'strict', // try this first

  },

}

• true (default): Next.js merges CSS aggressively based on import-graph analysis to minimize requests. This is almost certainly why the homepage is pulling in other components' CSS.

• 'strict': Loads CSS in exact import order instead of merging — more/smaller chunks, but no cross-route leakage. This is the one most likely to fix the reported issue.

• false: Disables chunking entirely — one large bundle (worse for this use case).

This is the single biggest gap in the original answer. Test 'strict' before concluding nothing is configurable.

---

2. Webpack / custom plugins

Claim: Not supported, may break across releases.

Verdict: ✅ Correct.

The App Router's CSS pipeline runs through internal loaders/plugins tied to the build, and Turbopack increasingly handles CSS through its own internals that don't route through the standard webpack config at all. A hand-rolled competing extraction plugin is not realistically maintainable long-term. Good practical advice as written.

---

3. Relation to issue #64773

Claim: Yes, closely related.

Verdict: ✅ Correct, but worth being precise.

The actual fix (PR vercel/next.js#67373, by sokra) addressed global CSS leaking across chunk groups — specifically styles applied to unscoped selectors (e.g. body) rather than CSS Modules classes. The fix disallows merging global CSS with styles from other chunk groups, because the old chunking logic assumed all CSS only affects the elements it's meant to (an assumption CSS Modules enforce but plain global stylesheets don't).

That's relevant background, but it's narrower than "unrelated component CSS leaking into route bundles" — which is a broader, still-open complaint:

• One developer found that with a catch-all route, enabling cssChunking caused routes outside the catch-all to pull in CSS they didn't need.

• Another reported the chunking feature causing chunks to contain CSS unrelated to the current page — enough to trigger Lighthouse's "unused CSS" warning — with disabling the feature resolving it.

That second report matches the symptom described almost exactly, and it's still being discussed as unresolved in general form.

---

4. Recommendations (lean layouts, CSS Modules, route groups, dynamic imports)

Claim: Reasonable hygiene practices.

Verdict: ⚠️ Reasonable but incomplete — omits the two most directly relevant levers:

• experimental.cssChunking: 'strict' (see Added css using aphrodite #1)

• experimental.inlineCss — replaces <link> stylesheet tags with inline <style> tags in the <head>. Aimed squarely at "load only critical CSS," but:

  • Works best with atomic CSS (Tailwind) — output stays small regardless of how much UI grows.

  • Skip it if returning visitors matter — inlined CSS can't be cached separately from HTML and re-downloads every visit.

  • For larger CSS bundles, it increases TTFB since all CSS ships with every HTML response.

  • It does run on App Router (unlike optimizeCss/Critters — see below): supports both Webpack and Turbopack, with CSS precedence/deduping handled automatically by React 19.

const nextConfig = {

  experimental: {

    inlineCss: true, // all-or-nothing; not just "critical" CSS

  },

}

---

5. "No officially supported way to load only critical CSS while deferring dynamic component CSS"

Verdict: ✅ Correct — this is the honest bottom line.

True per-component critical-CSS extraction (à la Critters) is not supported on App Router: the optimizeCss/Critters approach relies on a library that doesn't support streaming, which is fundamental to how App Router renders. A Vercel team member confirmed this directly in the GitHub discussion. inlineCss is the closest sanctioned tool, but it's all-or-nothing (inlines everything, not just critical rules) and still experimental / not recommended for production per current docs.

---

Recommended next steps, in order

1. Set experimental.cssChunking: 'strict' and rebuild. Check whether the homepage bundle shrinks. Free to try, most likely fix for the described leakage.

2. Audit for global, unscoped selectors (styles on body, bare tags, or anything outside a CSS Modules class) — these are exactly what merges indiscriminately under the old chunking assumption.

3. If using Tailwind/atomic CSS, consider experimental.inlineCss for pages with mostly first-time visitors. Skip it if you depend on stylesheet caching for returning users.

4. For anything deeper (manual critical-CSS extraction, fine-grained chunk control), treat it as a userland post-build step (e.g. Beasties/Critters run against static output) rather than a Next.js config knob — and expect it to be fragile across Next.js versions, same conclusion as the original answer.

It is not true that setting cssChuncing: true will reduce css bundle size.

[sokra]

CSS Chunking can intentionally lead to overshipping "unreleated" css to other pages. This is done to reduce the number of requests needed for pages (since they have a cost too).

We recently added a new css chunking mode experimental.cssChunking: { type: "graph" } which adds more options to control the heuristic how much overshipping it accepts.

[ChellappanRajan]

Thanks for the reply. Was this documented anywhere? Will it work with webpack? Could you please share how this graph will improve cssChunking?

[icyJoseph]

We will have more docs on this soon 👍 - though, it is a new feature, not available in stable yet.