←back to thread

Critical CSS

(critical-css-extractor.kigo.studio)
234 points stevenpotts | 1 comments | 06 May 25 03:13 UTC | HN request time: 0s | source
Show context
todotask2 ◴[06 May 25 06:17 UTC] No.43902273[source]▶
When I tested mine, I got the following:

Built on Astro web framework

HTML: 27.52KB uncompressed (6.10KB compressed)

JS: <10KB (compressed)

Critical CSS: 57KB uncompressed (7KB compressed) — tested using this site for performance analysis.

In comparison, many similar sites range from 100KB (uncompressed) to as much as 1MB.

The thing is, I can build clean HTML with no inline CSS or JavaScript. I also added resource hints (not Early Hints, since my Nginx setup doesn't support that out of the box), which slightly improve load times when combined with HTTP/2 and short-interval caching via Nginx. This setup allows me to hit a 100/100 performance score without relying on Critical CSS or inline JavaScript.

If every page adds 7KB, isn’t it wasteful—especially when all you need is a lightweight SPA or, better yet, more edge caching to reduce the carbon footprint? We don’t need to keep transmitting unnecessary data around the world with bloated HTML like Elementor for WordPress.

Why serve users unnecessary bloat? Mobile devices have limited battery life. It's not impossible to achieve lighting fast experience once you move away from shared hosting territory.

replies(2): >>43902335 #>>43904057 #
robotfelix ◴[06 May 25 11:53 UTC] No.43904057[source]▶
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.

replies(1): >>43912716 #
1. todotask2 ◴[07 May 25 06:13 UTC] No.43912716[source]▶
> 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

I’ve thought about that before but couldn’t figure out the ideal approach. Using a unique session cookie for non-logged in users isn’t feasible, as it could lead to memory or storage issues if a malicious actor attempts a DDoS attack.

I believe this approach also doesn’t work well for static pages, which are likely already hosted close to users.

One useful trick to keep in mind is that CSS content-visibility only applies in certain scenarios. One agency I came across using <iframe> for every section is a bad idea.

So my conclusion is mobile-first CSS is generally more practical and use PWA which I'm building now for site that has lots of listings.