Critical CSS? Not So Fast

First up, agree with the author. Now if I may, a rant.<p>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.<p>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.<p>The brief flash of your half-styled website is useless to me. Block rendering until the CSS is done. I don&#x27;t enjoy looking at half an interlaced video frame, or 100px of a 200px image, just show me the finished product.<p>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.

I am a fan of CSSWizardry and yet I find this post misleading. The examples shown are ways NOT to do frontend performance engineering.<p>The current best performant way to load JS is asynchronously as documented at <a href="https:&#x2F;&#x2F;web.dev&#x2F;efficiently-load-third-party-javascript&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.dev&#x2F;efficiently-load-third-party-javascript&#x2F;</a>.<p>And the best way to load CSS is with Critical Path CSS + Async CSS as documented at <a href="https:&#x2F;&#x2F;web.dev&#x2F;defer-non-critical-css&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.dev&#x2F;defer-non-critical-css&#x2F;</a>.<p>The easiest way to generate Critical CSS is <a href="https:&#x2F;&#x2F;github.com&#x2F;addyosmani&#x2F;critical" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;addyosmani&#x2F;critical</a> where you may suggest multiple resolutions.<p>I have found <a href="https:&#x2F;&#x2F;github.com&#x2F;addyosmani&#x2F;critical-path-css-tools" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;addyosmani&#x2F;critical-path-css-tools</a> to be a great resource to master critical path CSS which improves page render speeds. It helps build fast rendering sites, sometimes even sub-second renders given you have a low latency backend.

Agree with the author. The gazillion marketing scripts in your webpage is the main performance bottleneck, rather than your css link tag.

I&#x27;m astounded that we still don&#x27;t have proper lazy loading of stylesheets in 2022. We have async and defer for scripts but nothing for css. There are a bunch of hacks that exist, but none of them work if you want to use a strict CSP. Even if you use it then you have to worry about a FOUT instead of automatically loading the stylesheet from the browser&#x27;s cache.<p>Inlining critical CSS is madness for any project that is above a certain scale. Maybe you can do it for a single page, but in my experience the results are not worth the effort. You can make your site exceptionally fast without it.

Nowadays it&#x27;s probably better to just prompt the browser to preload CSS early with a link preload header.<p>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&#x27;re done.<p>If clients are on a crappy network, critical css is even worse of an idea because they&#x27;ll scroll down and get a broken page for 5 seconds

So many over optimize their sites for Google PageSpeed.<p>Most annoying is fancy &quot;loading&quot; screen before page load.<p>Skip that fancy loading screen&#x2F;spinner page and your site is already faster.

In 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.

Inline styles make CSP go from trivial to pain if you gotta create nonces without adding much value—to the point where I have the Lighthouse test ignored. I&#x27;ve never seen this sort of optimization being worthwhile and I&#x27;m happy the article starts off with how to show it&#x27;s not a bottleneck.

I find critters[0] quite easy to work with and well worth implementing on my nextjs or Astro projects.<p>I build a lot of landing pages so there are very few multi page visits.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;GoogleChromeLabs&#x2F;critters" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;GoogleChromeLabs&#x2F;critters</a>

I recently converted several of my projects into critical CSS and now I’m outranking my competitors who still use old CSS. Say what you want but Google loves fast loading sites and gives a good rankings boost. You can whine about critical CSS or get it done and win.

I 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.<p>I have found that keeping my code short and getting it all out in 1-3 HTTP request is the optimal performance strategy.

Wait, what&#x27;s wrong with just using &quot;ModPagespeedEnableFilters prioritize_critical_css&quot;?