> It kind of breaks how CSS is supposed to work.
Can you elaborate on this?
> You easily run the risk of sending redundant bytes if the same styles are still in your external CSS.
I think we're up against 2 less-than-optimal situations. Suppose you have 50KB of CSS.
* Ship it the traditional way. User waits on all 50KB before first paint.
* Ship it the code splitting way. User gets 10KB upfront, and leaves before the rest loads. But if they interact with the site extensively, then they trigger the redundant bytes that you're mentioning, so that the total download size comes out to be 75KB.
Disclaimer: I write the docs for Lighthouse. I'm speaking from my general knowledge of the project but haven't vetted these comments with my team. So consider all comments my own.
It breaks CSS, because having styles on the page couples presentation with content. The selling point of CSS is to change a style in one place, and have it affect multiple pages. If you break it up, you end up having to maintain multiple versions of your CSS. To do this in the name of performance strikes me as one of the very last things to do, given it's unfavorable maintenance cost.
> I think we're up against 2 less-than-optimal situations. Suppose you have 50KB of CSS.
> Ship it the traditional way. User waits on all 50KB before first paint.
Best practice for CSS is to link it in the first kilobyte or so of HTML[2][3]. Browsers have optimized for it: it makes the CSS request happen immediately, before the browser parses the rest of the HTML. Unless the user has a slow connection (<10 Mbps), bad round trip time (>200 ms), or the server is slow to serve a 50K static file (average CSS size[0]), that CSS will load within half a second, with first paint soon after. If you need to cut down that down, you should consider a CDN before deferred CSS.
> Ship it the code splitting way. User gets 10KB upfront, and leaves before the rest loads. But if they interact with the site extensively, then they trigger the redundant bytes that you're mentioning, so that the total download size comes out to be 75KB.
If CSS was split, and the user leaves[1] before the CSS completely loads, CSS isn't the source of slow page loads.
Google's tools need check if styles load within a second or two. If it's any more than 3 or 4 seconds, deferred CSS starts to make sense. If styles (or the entire page) load in less than that, don't bother.
[0] https://httparchive.org/reports/page-weight
[1] https://www.nngroup.com/articles/how-long-do-users-stay-on-w...
[2] https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduc...
[0] I have a strict Content Security Policy that forbids inline JS and CSS, and am considering using a require-sri-for declaration. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP