Atomic CSS is not ideal for performance. No tooling can extract the per-page critical CSS, so you end up shipping more CSS to the browser than necessary. The bigger and more dynamic the app, the more unnecessary code you will ship.
Isn’t this solved by using PurgeCSS? During your build phase it removes any unused classes from the final build. You end up with a single CSS file, which is usually quite small, that your browser only downloads once and then caches it.
Do people actually generate a CSS file for every page?
Yes, CSS-in-JS actually generates critical CSS for every page and user! Quite mind-blowing, right? That's possible because it knows exactly which components were rendered in which state, which no other tool can do.
See the footnote in the blogpost that explains this more in-depth. I'll copy and paste it here:
> CSS-in-JS automatically extracts the critical CSS for the requested page and inlines it into a <style> tag. That means the first-paint with CSS-in-JS will always be faster as it saves both an extra network request for the .css file as well as sending less CSS code to the client. While the Time To Interactive for small apps will be slightly slower (as the JavaScript bundle includes the CSS-in-JS library you use) once your app grows the network request for the larger CSS file can outweigh any CSS-in-JS library and can cause a slower Time To Interactive as well.
Interesting thanks! Wouldn’t this only be a benefit for the very first request when it has to download the css file? Seems like including online styles would increase the page size of every page, on every load, versus a one time delay downloading the css?
The problem is partly that page speed measurement tools care a lot about that first load. Even if everything after that is super snappy due to cached resources, if you are only using 5% of the total CSS file in the first page the user hits, that other 95% is dragging down the experience on first load, and especially dragging down lighthouse scores.
It doesn't mean though, that you can't have a combined approach where a small amount of genuinely global CSS is loaded from an external file that is cached, while component-specific CSS lives in the component and renders inline with it. But then it's like ... why do that extra request if the file is that small, and you end up with inline everything.
Definitely the trend from a business point of view is to optimize for good perf scores on lighthouse, even if that's a little illogical at times.
Another thing though is that often the JS for whole chunks of a page (which contains the CSS) can be code-split and cached as its own file, so whole components made up of HTML CSS and JS can be lazy loaded and if that same chunk of stuff is needed again, it could be a cached JS file.
Especially if these are "below the fold" and pulled in as the user scrolls or something, you get a small initial payload + small JS files being called in to run as needed.
I don't know how many implementations there are of this in the wild, but it's possible.
Do people actually generate a CSS file for every page?