-
-
Notifications
You must be signed in to change notification settings - Fork 1k
perf(vite): remove duplicate css links from rendered page when inlined #7264
Conversation
β Deploy Preview for nuxt3-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
ctx.nuxt.hook('build:manifest', (manifest) => { | ||
for (const key in manifest) { | ||
const entry = manifest[key] | ||
const shouldRemoveCSS = chunksWithInlinedCSS.has(key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will happen for a component with ssr inline syle enabled when rendering in hybrid/spa mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rendering in hybrid/spa mode would not be adding a <link>
for the CSS that is specific to the page anyway (as ssrContext.modules
would be empty). So there would be no change from these lines (L127-133).
However, there would be a change to the entry CSS, which would be prefetched and then loaded on client-side rather than preloaded. (This would have a negative performance impact.)
- <link rel="preload" as="style" href="/_nuxt/entry.6e3e3577.css">
- <link rel="stylesheet" href="/_nuxt/entry.6e3e3577.css">
+ <link rel="prefetch stylesheet" href="/_nuxt/entry.6e3e3577.css">
Note that this also has a negative impact for client-only components for SSR pages. We could disable L135-R143, and though we would have double-loaded entry CSS values, we would not have any negative perf impact for client-side/or hybrid spa:
I haven't looked into it too much but something in RC.10 is causing this issue windicss/nuxt-windicss#180, this PR seems like a likely candidate. Any ideas before I dig into it? |
π Linked issue
resolves nuxt/nuxt#14792
β Type of change
π Description
This improves the performance of inlining styles in SSR. We can complete remove styles from the manifest for individual/non-entry chunks, as we always know that these will be inlined. For entry CSS, it's a little more complex. Client-only components may have their CSS in the entry file, so we can't entirely exclude entry CSS. (And we deliberately tree shake client-only components from the server build.) I have lowered entry CSS priority via prefetching it; vite's preload helper then loads it.
Note: I think this is soluble, but it may require a secondary PR, which will also need to stop vite from preloading the entry css...
π Checklist