> worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS?
You don't have to ever think about this stuff if you use a component-driven frontend framework like Vue w/ Vite (or Webpack).
The general design: you use one global .css file for your shared styles (app.css) and then each component has their own inline CSS.
Vite will automatically extract each component JS and CSS in tiny files and only load them when you visit a page with the specific component.
This all happens automatically and you can cleanly organize your project by keeping the styles close to the view template and logic (often the same file has the template, <style> and <script> which each get extract automatically into bundles). The .css/.js filenames match the component name which makes debugging easier too in dev console.
HTTP2 handles loading 20-100 small files like nothing and with large SaaS apps usually only have tons of components that rarely get used, so no need to load them all for every page.
If you had to think about this stuff, manage the tooling, and customize then it would be overhead, but otherwise with frameworks it's pure benefit.
How is it a micro-optimization to only load content that you need?
Like I said for large SaaS products you might never see 50% of the components on random settings and other less used pages. Some users only load a few index pages the first few times they visit so making it load faster is always a win.
Frameworks handle way more complex stuff that this. It's not overhead.
The way SPAs work is very performant but are also poor for indexing. Critical Path CSS is mostly used in user facing sites which one wants to get indexed by Google. As page speed is one of the factors considered in SEO, and rightly, one tries to optimize that. Vue, React, etc. are poor at SEO as they do not even try to do solve the problem as they are used to build apps and not sites.
I see you haven't used these libraries in at least a few years, because they all have frameworks that work with SEO by server side rendering content. React has NextJS while Vue has NuxtJS.
What speed differentials are you seeing? Since they are server side I don't see any speed differences at all since they just transmit raw HTML and CSS, same as if you would write it by hand.
You don't have to ever think about this stuff if you use a component-driven frontend framework like Vue w/ Vite (or Webpack).
The general design: you use one global .css file for your shared styles (app.css) and then each component has their own inline CSS.
Vite will automatically extract each component JS and CSS in tiny files and only load them when you visit a page with the specific component.
This all happens automatically and you can cleanly organize your project by keeping the styles close to the view template and logic (often the same file has the template, <style> and <script> which each get extract automatically into bundles). The .css/.js filenames match the component name which makes debugging easier too in dev console.
HTTP2 handles loading 20-100 small files like nothing and with large SaaS apps usually only have tons of components that rarely get used, so no need to load them all for every page.
If you had to think about this stuff, manage the tooling, and customize then it would be overhead, but otherwise with frameworks it's pure benefit.