CSS Styles from unrelated layouts are merged if they have one CSS file in common
Link to the code that reproduces this issue
https://github.com/onigoetz/nextjs-css-issue-repro
To Reproduce
- build the app and start it (not reproducible in dev mode)
- go to http://localhost:3000/
- you should see a green background as defined in its stylesheet
Current vs. Expected behavior
The background should be green but is red.
The styles from the subpage http://localhost:3000/leakingstyle are applied to http://localhost:3000/ but they have no layout in common and should not. It seems that because they have another CSS file in common they are merged
Another page next to it that has no css file in common does not have this issue : http://localhost:3000/otherstyle
Provide environment information
Operating System:
Platform: linux
Arch: x64
Version: #1 SMP Fri Jun 2 00:45:15 UTC 2023
Available memory (MB): 17991
Available CPU cores: 6
Binaries:
Node: 20.11.1
npm: 10.2.4
Yarn: 1.22.21
pnpm: 8.14.1
Relevant Packages:
next: 14.2.2
eslint-config-next: N/A
react: 18.2.0
react-dom: 18.2.0
typescript: N/A
Next.js Config:
output: N/A
Which area(s) are affected? (Select all that apply)
Not sure
Which stage(s) are affected? (Select all that apply)
next build (local), Vercel (Deployed)
Additional context
I tested multiple versions:
- 14.1.4 : OK
- 14.2.0-canary.27: OK
- 14.2.0-canary.28: BROKEN
- 14.2.0 : BROKEN
- 14.2.1 : BROKEN
- 14.2.2 : BROKEN
- 14.3.0-canary.11: BROKEN
Apparently the issue has been introduced in https://github.com/vercel/next.js/releases/tag/v14.2.0-canary.28
I would bet that the issue was introduced in this PR : https://github.com/vercel/next.js/pull/63157
+1
Experiencing the exact same, super annoying. Happens only on build though.
+1
This issue is directly responsible for a 5-10% performance drop on our SEO optimised pages, in which the Lighthouse "eliminate render blocking resources" diagnostic suggests a savings of 1080ms by removing unused CSS, whereas with 14.1.4 it was around 250ms.
Same here, happens only on build. It currently blocks us from upgrading next.js version from 14.1.4 to 14.2.3
Unfortunately running in to the same issue where my frontend styles are merged into the backend.
This actually also happens when there’s no CSS files in common. A single global css (non module) import in one parallel route layout results in those styles being imported in other parallel routes.
This is super annoying and makes it impossible to use next.js with the payloadcms 3.0, unless you have no global styles (which is rarely the case). Is there any update on this from the next team?
@onigoetz Thank you for sharing. I can confirm this is an issue we're there is different behavior happening from next dev / next dev --turbo and next build.
We are taking a look at several CSS issues at the moment and hopefully we can land several fixes at once! Will be sharing updates and testing these 
OMG I am not the only one. I just updated to the lastest version (14.2.4). I almost pulled the hair out of my head. xD
Any updates on this issue? Has anyone found a canary version that doesn't break the merged css files?
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!
Any updates on this issue?
No updates yet, but we are indeed prioritizing this issue!
@balatD The CSS merging works as expected versions prior to v14.2.0-canary.28 (just tested on v14.2.0-canary.27).
In lieu of a +1 I will just say that my project is stuck on 14.1.x because of this issue. We are using Sass + CSS Modules, with a single global css file that contains resets and utility classes (i.e. mobile-only).
Hi everyone—
Let us know if canary v15.0.0-canary.56 or higher fixes your issue—we recently shipped a bug fix that changes how we merge global css → https://github.com/vercel/next.js/pull/67373.
@onigoetz I can no longer reproduce the issue!
As described in the 
@samcx Appreciate that there is progress on this issue - Will these fixes be made in the Next 14.x?
@timhettler It's been backported to 14.2.5!
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.