Critical CSS

    <link rel="preload" href="styles.css" as="style" onload="this.rel='stylesheet'">

I wouldn’t use the JS hack to load CSS…

When the stylesheet loads and is applied to the CSSOM it’s going to trigger layout and style calculations for the elements it’s applied to maybe even the whole page

Browsers are pretty eager at fetching stylesheets even those at the bottom of the page

the prefetch attribute and other HTTP header hints, combined with proper CDN setups does almost the same. and would not require critical CSS to be nonstop rebuilt as the page develops. a properly configured CF is insanely fast.

you are right, I will add this option, probably replace the 'before body' option, the 'DOMCONTENTLOADED' option has worked wonders for me, even tested it on old phones and slower connections, it's good enough for UX and Lighthousr

+1 on responsiveness

Oh my god, yes, this is useful. I do some freelance dev work for a small marketing agency, and I inherit a lot of Wordpress sites that show all the hallmarks of passing through multiple developers/agencies over the years, and the CSS and Javascript are *always* crufty with years of accumulated bad practices. I'm eager to try this.

> Are there really cases where the CSS is so complex or the page loads so many resources that this effort is worthwhile?

On the contrary, the more complex the css is or the more resources loaded, the less this would be worthwhile.

The thing i think they are trying to optimize is latency due to RTT. When you first request the html file, the browser needs to read it before knowing the next thing to request. This requires a round trip to the server, which has latency (pesky speed of light). The larger your (critical) css, the more expensive this optimisation is so the less likely it is a net benefit.

I would pay good money for this tool ~12 years ago. We had a site with enormous amounts of CSS that accumulated over the years and it was really unclear which rules are and which aren't critical

For many sites, this probably is a premature optimization. But for sites that live off of click-through, like news/media, getting the text on screen is critical. Bounce rate starts to go up and ad revenue drops as soon as page loads are less than "immediate", which is about 1 second. The full page can actually be quite heavy once all the ads, scripts, and media load.

We were doing this optimization more than a decade ago when I worked at HuffPost.

Seriously. When I look at the modern state of front-end development, it's actually fucking bonkers to me. Stuff like Lighthouse has caused people to reach for optimizations that are completely absurd.

This might make an arbitrary number go up in test suites, at the cost of massively increasing build complexity and reducing ease of working on the project all for very minimal if any improvement for the hypothetical end user (who will be subject to much greater forces out of the developer's control like their network speed)

I see so much stuff like this, then regularly see websites that are riddled with what I would consider to be very basic user interface and state management errors. It's absolutely infuriating.

Oh, writing clean css, html and js is THE WAY TO GO but you might inherit a messy project, download a template or even work on a project you coded poorly

>Feels like premature optimisation to me.

To me thinking about how CSS loads is task #1, but I probably have some unique needs.

We were losing clients due to our web offering scoring poorly on page speed tests. Page speed being part of how a page is ranked can affect SEO (depending on who you ask), so it is very important to our clients. It's not my job to explain how I think SEO works, it's my job to make our clients happy.

I had to design a whole new system to get page speed scores to 100% on Google Lighthouse, which many of our clients were using to test their site's performance. When creating a site optimized for performance, how the CSS and JS and everything loads needs to be thought about before implementing the pages. It can be pretty difficult to optimize these things after-the-fact. We made pretty much everything on the page load in-line including JS and CSS, and the CSS for what displays "above the fold" loads above the HTML it styles. Everything "below the fold" gets loaded below the fold. No FOUC, nothing blocking the rendering of the page. No extra HTTP requests are made to load any of the content. A lot of the JS "below the fold" does not even get evaluated until it is scrolled into view, because that can also slow down page load speed. I took all the advice Google Lighthouse was giving me, and implemented our pages in a way that satisfies it completely. It wasn't really that difficult but it required me changing my thinking about how to approach building websites.

We were coming from a system that we didn't control, where they decided to load all of the CSS for the entire website on every page, which was amounting to about 3 to 4 MB of CSS alone, and the Javascript was even worse. There was never an attempt to optimize that system from the start, and now many years later they can't seem to optimize it at all. I won't name that system because we still build on it, but it's a real problem for us when a client compares their SEO and page speed scores to their competitors and then they leave us for our competitors, which score only a bit better for page speed.

If performance is the goal, there is no such thing as premature optimization, it has to be thought about from the start. So far our clients have been very happy about their 100% page speed scores (100% even on mobile), and our competition can't come anywhere close, unless they put in the work and start thinking differently about the problem.

I actually tried the tool that is the subject of this post on my sites, and it wouldn't work - likely because there is nothing to optimize. We simply don't do any HTTP requests for CSS, and the CSS we need "above the fold" is already "above the fold". I tried it on one of the old pages and it did give a result, but I don't need it because we don't build pages like we used to anymore.

Yeah, it's a neat trick but kinda pointless. In a world with CDNs and HTTP/2, all this does is waste bandwidth in order to look slightly better in artificial benchmarks.

It might improve time to first paint by 10-20ms, but this is a webpage, not a first-person shooter. Besides, subsequent page loads will be slower.

It's worth noting that including Critical CSS in every page load isn't the only way to use it.

A lot of unnecessary bloat can be avoided by only including it when it looks like a user is visiting for the first time (and likely hasn't got the CSS files cached already) or only using the Critical CSS technique for pages that commonly come at the start of a session.

What was the problem with something like https://www.npmjs.com/package/penthouse ?

FYI: While a bit of an edge case, as I don’t know why anyone would do this realistically… If a site without CSS is passed, it throws an error.

Is the code somewhere? This seems like it'd be really useful as a Vite/Astro plugin

Is it the UI for penthouse lib? Settings look very similar :)

Yeap, I had to change some styles after applying this but managed to get CLS to 0 for the websites, I know this isn't useful for everyone but it was really useful for me as I have been using templates for clients with limited budgets that have tons of libraries, I'm sure there are other use cases where this is useful

isn't the whole point avoiding FOUC, while also avoiding to block the rendering for CSS network requests?

Yes, for first view page and it is a trade off, best approach is writing all the styles and code yourself, not use libraries, etc.

Obviously trying to do an optimization designed to reduce the impact of latency between client <-> server is going to have no impact if you are testing on localhost where latency is already effectively zero.

That's not to say i think this optimization is neccesarily worth it, just that testing on localhost is not a good test of this.

This doesn't really work for sites where reading text left to right, top to bottom is not the primary focus.

Will check this case, thanks!

> serving zipped styles across CDN

CDNs haven't been cached across domains for years. I.e. using a CDN is no faster than a server serving it itself (usually slower because of DNS lookups, but sometimes slightly faster if the geolocation is closer if the DNS was already looked up).

Yes, this is for specific use cases, I don't have a use for this for sites where I coded everything myself, this has been useful for static sites where I downloaded a template that uses libraries, probably useful for people with similar cases