September 28, 2022
I appreciate all the research and appropriate nuance Harry brings in Critical CSS? Not So Fast!
Not a fan of any performance testing tool that dings the score of a site for not having it implemented. It’s just not a cut-and-dry thing like, say, optimizing an image.
Here’s the rub from Harry. Only bother if:
CSS is your biggest blocker, or…
… you plan to tackle everything around it at the same time (i.e. other render-blocking resources)
… it can be done trivially or from the outset (retrofitting Critical CSS is difficult and error prone)
… you maintain it and everything around i (it’s all too easy to (re)introduce render-blocking regressions)
… you load the non-Critical CSS sensibly (current methods can be no better than just leaving your CSS as-is)
Read Harry’s conclusion to re-iterate those things and clearly remind you it’s not worth jacking into a pre-existing site that isn’t yet doing it.
I’ve long considered critical CSS just too much trouble to bother with, despite the clear fact that CSS is a render-blocking resource and, if done perfectly, does offer perf gains. It’s just so damn hard to get right and stay right. Bigger fish to fry.
The last time I was tempted to try it was when it became a feature in Jetpack Boost. It’s ONE CLICK! You just turn it on and it figures out what CSS should be critical and does the whole song and dance for you. It’s kind of amazing in that it basically works. Except… when it doesn’t. My sub-pages that had some different styles would then have some loading jank (the opposite of the intended effect). And every time I shipped any half-significant CSS change, I’d scratch my head why I was getting loading jank until I remembered to go back into the plugin and re-generate the critical CSS with a button click (there is no (web)hook). Geoff had the same problem.
Related
🤘
ncG1vNJzZmibmKe2tK%2FOsqCeql6jsrV7kWlpa2dgbnxzhI6cqaKsmZiurXnCrKpmpp%2BperS7jJ%2BYrKxf