Critical CSS? Not So Fast
csswizardry.com
Critical CSS? Not So Fast
1–10 of 90 posts
Re: Critical CSS? Not So Fast
#2Agree with the author. The gazillion marketing scripts in your webpage is the main performance bottleneck, rather than your css link tag.
Re: Critical CSS? Not So Fast
#3In my experience “critical styles” are necessary to load fonts efficiently if you load any, and it’s beneficial to load a few color styles at the same time. Other than that it’s better to load them as separate resources.
Re: Critical CSS? Not So Fast
#4I do this for CSS and most JavaScript, except for the OpenPGP.js module, which is one order of magnitude more LOC than all my other JS templates put together.
I have found that keeping my code short and getting it all out in 1-3 HTTP request is the optimal performance strategy.
Re: Critical CSS? Not So Fast
#5Agree with the author. The gazillion marketing scripts in your webpage is the main performance bottleneck, rather than your css link tag.
That’s not quite what the author says…
He says if you’ve got other blocking scripts / stylesheets in the head then there’s no point using critical CSS
Re: Critical CSS? Not So Fast
#6First up, agree with the author. Now if I may, a rant.
It boggles the mind that we style bikeshed over CSS. Is it honestly, truly, and pragmatically worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? Pre-load that, inline this, async-load that, and what have we got for it? A web full of wiggling content, slow CDNs, dozens of requests, and an experience of a mis-timed, slow loading web of bullshit.
Deliver less CSS in the first place, be pragmatic, load it as one file when the user hits the website, from the same server they got the HTML from. Bam, lightning fucking fast, like it was before we invented all these new problems.
The brief flash of your half-styled website is useless to me. Block rendering until the CSS is done. I don't enjoy looking at half an interlaced video frame, or 100px of a 200px image, just show me the finished product.
The content wiggles and asynchronous bullshit is what makes your website -feel- slow, even if you managed to trick Google into thinking it loaded quickly.
Re: Critical CSS? Not So Fast
#7Nowadays it's probably better to just prompt the browser to preload CSS early with a link preload header.
Any page complicated enough to need critical CSS extraction is probably also going to take 50-100ms to render and transfer to the user. Just send the headers before you render and the client will probably have finished downloading them by the time you're done.
If clients are on a crappy network, critical css is even worse of an idea because they'll scroll down and get a broken page for 5 seconds
Re: Critical CSS? Not So Fast
#8First up, agree with the author. Now if I may, a rant. It boggles the mind that we style bikeshed over CSS. Is it honestly, truly, and pragmatically worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? Pre-load that, inline this, async-load that, and what have we got for it? A web full of wiggling content, slow CDNs, dozens of requests, and an experience of a mis-…
This is the reason I love tailwind. There's no bloat, no headache of naming conflicts (in fact they completely did away with naming), no orphan css. CSS for a full blown website can be less than 5kb. It takes away the pain of thinking about CSS architecture, naming things, conflicts etc and you can just focus on styling.
Re: Critical CSS? Not So Fast
#9First up, agree with the author. Now if I may, a rant. It boggles the mind that we style bikeshed over CSS. Is it honestly, truly, and pragmatically worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? Pre-load that, inline this, async-load that, and what have we got for it? A web full of wiggling content, slow CDNs, dozens of requests, and an experience of a mis-…
> 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, and 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.
Re: Critical CSS? Not So Fast
#10First up, agree with the author. Now if I may, a rant. It boggles the mind that we style bikeshed over CSS. Is it honestly, truly, and pragmatically worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? Pre-load that, inline this, async-load that, and what have we got for it? A web full of wiggling content, slow CDNs, dozens of requests, and an experience of a mis-…
This is the reason I love tailwind. There's no bloat, no headache of naming conflicts (in fact they completely did away with naming), no orphan css. CSS for a full blown website can be less than 5kb. It takes away the pain of thinking about CSS architecture, naming things, conflicts etc and you can just focus on styling.
I did not expect to like tailwind, and it still irks my past-self's approach to CSS. But I can't argue that as a wholistic approach to CSS, it is very capable and once you learn the lexicon, very fast to develop with. I really did enjoy it.