fix(css): avoid duplicate style for server rendered stylesheet link and client inline style during dev

[hi-ogawa]

Description

Currently Vite reuses server rendered <style data-vite-dev-id="..."> when the same css is imported on client. This PR adds the same logic for <link data-vite-dev-id="...">.

I haven't thought through the whole scenario, but this seems reasonable to have since Vite handles link stylesheet with special behavior such as:

• for dev, <link rel="stylesheet" /> supports HMR by rewriting href="...?t=..."

vite/packages/vite/src/client/client.ts

Lines 200 to 201 in bc6995e

	// css-update
	// this is only sent when a css file referenced with <link> is updated

• for build, client preload checks existing links and skips re-inserting

vite/packages/vite/src/node/plugins/importAnalysisBuild.ts

Line 118 in bc6995e

// check if the file is already preloaded by SSR markup

additional context

As far as I know, only Astro makes use of <style data-vite-dev-id="..."> for SSR to avoids duplicate css when the module on client imports the same css. Frameworks not using this trick but still injecting css from SSR to avoid FOUC have duplicate CSS on browser momentarily and then remove the server rendered <style> on hydration (Sveltekit, Nuxt, React router work like this). This behavior seems mostly harmless, but there's one issue about potential font glitch (cf. unjs/fontaine#665).

I'm trying to see if the same idea can be implemented for <link data-vite-dev-id="...">. The advantage of link over style is following:

• to generate <style> during SSR, it requires ssrLoadModule("...css?inline") to get the css content whereas <link> requires only module url.
• rendering entire inline css <style> can SSR output.
• on production, style is <link> by default (unless framework has some logic to inline them).

Btw, I'm currently using custom plugin to transform @vite/client to have this patch in hi-ogawa/vite-plugins#1168.

---

One more thought: it would be simpler if updateStyle/removeStyle handles href url directly instead of extra data-vite-dev-id. I haven't tried this yet though.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vite@20767

commit: 07abca2

[sapphi-red]

This means there'll be two requests for each CSS imports (one for <link> and one for the JS script that injects <style> when <link> doesn't exist). I wonder if that affects performance when the application is large.

[hi-ogawa]

Right, obviously it's not perfect either, but I think it's worth the try. I don't think this change itself has downside.
For ?assets import, we can mostly switch internal implementation and probably experiment with the difference and see trade off too.

[sapphi-red]

The life cycle feels strange to me, but I think that shouldn't be a blocker for this PR.
If <link> works better than <style>, we can migrate to it, rewriting import './foo.css' to client.injectStyle('./foo.css') which will inject a link tag.

[hi-ogawa]

The life cycle feels strange to me, but I think that shouldn't be a blocker for this PR. If <link> works better than <style>, we can migrate to it, rewriting import './foo.css' to client.injectStyle('./foo.css') which will inject a link tag.

Will think about it. There's something tricky with css module though (and likely other build-time css-in-js like solution which generates css). Js needs to know class name mapping, so import styles from "./foo.module.css" needs to be a separate request.

<link> centric approach is mostly verified to work on @vitejs/plugin-rsc including css module, hmr, etc. So, I'm somewhat optimistic.