Critical CSS? Not so fast
6 September, 2022 Written by Harry Roberts on CSS Wizardry. Table of Contents Overview Critical CSS Is Difficult to Implement Ensure CSS Is Your Biggest Bottleneck Ensure CSS Remains Your Biggest Bottleneck You’re Only Solving the Fetch It’s a Race Moving Away From media Problems With print A Better Option Pitfalls and Concerns Debugging Critical CSS So What Am I Saying? I have long held very strong opinions about the Critical CSS pattern. In theory, in a perfect world, with all things being equal, it’s demonstrably a Good Idea™. However, in practice, in the real world, it often falls short as a fragile and expensive technique to implement, which seldom provides the benefits that many developers expect. Let’s look at why. N.B. Critical CSS when defined as ‘the styles needed to render the initial viewport’. Overview Critical CSS is not as straightforward as we’d like, and there is a lot to consider before we get started with it. It is worth doing 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 it; it’s all to 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. Critical CSS Is Difficult to Implement …particularly when we talk about retrofitting it. Reliably extracting the relevant ‘critical’ styles is based, first and foremost, on some brittle assumptions: what viewport (or fold, remember that?) do we deem critical? How do we treat off-screen or un-interacted elements (think dropdown or flayout navs, etc.)? How do we automate it? Honestly, in this scenario, my advice is almost always: don’t bother trying to retrofit Critical CSS—just hash-n-cache1 2 the living daylights out of your existing CSS bundles until you replatform and do it differently next time. Implementing Critical CSS on a brand new project becomes markedly easier, especially with the correct3 CSS-in-JS solution that bundles and componentises CSS by default, but that still doesn’t guarantee it will be any faster. Let’s look at the performance implications of getting Critical CSS right. Ensure CSS Is Your Biggest Bottleneck Critical CSS only helps if CSS is your biggest render-blocking bottleneck, and quite often, it isn’t. In my opinion, there is often a large over-focus on CSS as the most important render-blocking resource, and people often forget that any synchronous work at all in the is render blocking. Heck, the itself is completely synchronous. To that end, you need to think of it as optimising your , and not just optimising your CSS, which is only one part of it. Let’s look at a demo in which CSS is not the biggest render-blocking resource. We actually have a synchronous JS file that takes longer than the CSS does4: When we view a waterfall of this simple page, » Read More
Like to keep reading?
This article first appeared on csswizardry.com. If you'd like to continue this story, follow the white rabbit.