-
Notifications
You must be signed in to change notification settings - Fork 27.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSS Styles from unrelated layouts are merged if they have one CSS file in common #64773
Comments
+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 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 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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 |
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 → #67373. @onigoetz I can no longer reproduce the issue! As described in the |
…67373) ### What? This disallows merging of global css with styles that appear on other pages/chunk groups. ### Why? Before we made the assumption that all CSS is written in a way that it only affects the elements it should really affect. In general writing CSS in that way is recommended. In App Router styles are only added and never removed. This means when a user uses client-side navigations to navigate the application, styles from all previous pages are still active on the current page. To avoid visual artefacts one need to write CSS in a way that it only affects certain elements. Usually this can be archived by using class names. CSS Modules even enforce this recommendation. Assuming that all styles are written this way allows to optimize CSS loading as request count can be reduced when (small) styles are merged together. But turns out that some applications are written differently. They use global styles that are not scoped to a class name (e. g. to `body` directly instead) and use them in different sections of the application. They are structured in a way that doesn't allow client-side navigations between these sections. This should be valid too, which makes our assumption not always holding true. This PR changes the algorithm so we only make that assumption for CSS Modules, but not for global CSS. While this affects the ability to optimize, applications usually do not use too much global CSS files, so that can be accepted. fixes #64773
@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. |
Link to the code that reproduces this issue
https://github.com/onigoetz/nextjs-css-issue-repro
To Reproduce
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:
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 : #63157
The text was updated successfully, but these errors were encountered: