A lot of my clients stress about Critical CSS. It’s very difficult and error-prone to retrofit to a site, yet a lot of tools make a huge deal of it. The thing is, it’s not always that effective…

Critical CSS only helps *if CSS is your biggest bottleneck*. Your HEAD is the single biggest render-blocking part of your page, so if your HEAD takes, for example, 1000ms, your Start Render will never be faster than that.

Put another way: getting your CSS time down from 250ms to 50ms will do nothing if you have a synchronous JS file that takes 250ms.

There’s every chance a browser has time to parse your inline CSS, download your async CSS, turn it into sync CSS, combine both, and build the CSSOM, before your HEAD is even finished. All that work, for nothing.

The other, compounding issue is that we turn our async CSS into sync CSS the moment it loads, so if that async CSS file does load before the HEAD is finished, we turn it back into a blocking file. Back at square one!

Easiest way to check if your Critical CSS is working as expected: stick * { color: red !important ;} at the end of the lazily-loaded CSS file. If your first render is red, it hasn’t worked.

tl;dr It’s not enough to just unblock your CSS; you need to unblock the HEAD as a whole. Unless you’re certain that CSS is your slowest HEAD resource, don’t worry too much about Critical CSS.

ttl;dr Critical CSS is unlikely to ever make a site slower, but it making a site faster depends on far more moving parts. Unless you can nail those, too, don’t waste time chasing Critical CSS.

If you’re reading this thread and worrying that your Critical CSS implementation may have been a misfire, my first mitigation would be to move the async » sync switcher part of the technique to the closing </body>.

That way, when we turn it back into a blocking resource, it’s not blocking the entire document. Use the color: red technique above to test.