I went in the same direction for the return of my own blog that I'm doing at the moment. My logic was much the same as in the article: most users to a blog have probably found it via Google or a link aggregator, and probably won't have the site in cache. They will probably visit one, possibly two pages, so they're unlikely to get much of a benefit from caching resources once they arrive. Therefore the (amortised) connection cost for fetching the CSS resource is still going to be further for most users than the extra few kB of inline CSS.
It was also very easy to do - the static site generator I was using could still read the source CSS file and insert it into the template, just instead of inserting it as a link, I told it to insert the (minified and CSS-escaped) source into a style tag instead. I even had it set up so that it could create the link in dev-mode, and the style tag in production, although I think that was overkill!
The impact on site traffic is really interesting to see here, though. That surprised me a lot, that it would have such a measurable effect. I'm always surprised that other sites just don't seem to care about these sorts of things, and then produce painfully slow sites, usually full of ads.
I’m used to “inline css” referring to using the style attribute - not the style tag. Interesting that it makes such a difference, this is the sort of optimization that modern build steps enable pretty easily.
I like reading performance-related articles, or just thinking about performance. It feels so rewarding when you can make something use fewer resources, run faster or more efficiently.
It might be my competitive programming background, but I would rather spend 5 hours improving performance by 10% than doing sales that would actually bring in money...
Inlining critical CSS seems to work best in SPA models that provide hydration, since they can choose to not request inline CSS on subsequent loads. But there can definitely be advantages to MPAs as well. Honestly I just find CSS a pain to untangle into the critical parts, so I don't usually bother.
Looking at your network graph real quick, you might be able to get away with simplifying GTM. I'm only seeing it load analytics, at least on the client side.
Normally this page is 824KB/15 requests. With an adblocker preventing GTM though, it's 655KB/8 requests. A pretty big reduction.
Also, I see it bootstrapping google-analytics.com/analytics.js, which if I'm not mistaken is the now-defunct GA3's analytics. Could that be nixed?
If you're using GA4, there might be lighter alternatives as well. Though it sucks to lose data continuity, most of their competitor are a _lot_ smaller in JS payload (Matomo, Plausible, umami).
Previously you could also just send the signals directly to GA using the Measurement Protocol, but it seems like they've made that a lot more difficult in GA4. Searching online, it looks like maybe GA4MP can do it, but I've not tested that tool.
You could also just load gtag.js rather than all of GTM if you're not using other tags, but that's still pretty heavy.
Outside of analytics, you might want to look at thumbnail generation. To take the worst offender, speed3.png is being rendered at 512px, but it's actually 2430px wide. Now sure this image is mostly white so it compresses well, but on most images that would make a big difference.
Lossy compression (via TinyPng.com) also brings this image down from 167KB to just 46KB. And if we first shrink it to the displayed resolution of 512px, then it shrinks to just 8KB. That's a 95% reduction from the original!
Image weight is less offensive than JS because it doesn't need to be processed. And if you're using size attributes (you're not), it also avoids CLS problems. But it's still often an easy win when it comes to reducing total page size.
If you wanted to be really fancy, you could generate multiple resolutions (for mobile, etc) and provide all of them in the <picture> tag. Or generate some more optimized format alternatives (webp, avif).
Realistically you probably have some limits due to using GitHub Pages. I do too, so integrating build steps to perform these kinds of optimizations is difficult. Maybe it's possible using GitHub Actions - that's something I'd like to look into for my own site.
Anyway, hope some of this information is helpful to you.
I like GA4, but never got around to removing google-analytics.com/analytics.js. You mean GA4 doesn't need that now to function and I've been loading it for nothing all this time? I'll look into removing that one.
And normally I set all images to loading='lazy', I just realized from your comment that for this post I hadn't. Great catch, and fixed it already.
If a # of pages share style, loading a shared stylesheet once is probably better than each page duplicating it. Also from maintenance pov.
Shared style in separate stylesheet(s), per-page style in each page itself. But I understand author's reasoning for doing otherwise. Btw: great tip about avoiding downloaded fonts! Default fonts are fine with rare exceptions.
Kudoz for trying to make pages load quick. But few users will be bothered by HTML+CSS and (moderate!) use of JS. Network latency is a thing no matter how lightweight a page is. And users are used to that.
What makes websites slow:
Tons & tons of (3rd party) tracking scripts. Tons of <insert web tech here> based "frameworks" without thinking twice how that affects page weight (both network transfer, and client side RAM & cpu load). Pictures of several MB each when lossy encoding at 1/10th file size would do. Video-playing ads (especially bad: those that popup again minutes after you clicked [x] on previous one). "Subscribe to newsletter" or similar popups. Cookie dialogs.
In short: what annoys people on other sites, will annoy users of your site. And what those annoyances are, is well known by now.
I went in the same direction for the return of my own blog that I'm doing at the moment. My logic was much the same as in the article: most users to a blog have probably found it via Google or a link aggregator, and probably won't have the site in cache. They will probably visit one, possibly two pages, so they're unlikely to get much of a benefit from caching resources once they arrive. Therefore the (amortised) connection cost for fetching the CSS resource is still going to be further for most users than the extra few kB of inline CSS.
It was also very easy to do - the static site generator I was using could still read the source CSS file and insert it into the template, just instead of inserting it as a link, I told it to insert the (minified and CSS-escaped) source into a style tag instead. I even had it set up so that it could create the link in dev-mode, and the style tag in production, although I think that was overkill!
The impact on site traffic is really interesting to see here, though. That surprised me a lot, that it would have such a measurable effect. I'm always surprised that other sites just don't seem to care about these sorts of things, and then produce painfully slow sites, usually full of ads.
I’m used to “inline css” referring to using the style attribute - not the style tag. Interesting that it makes such a difference, this is the sort of optimization that modern build steps enable pretty easily.
I like reading performance-related articles, or just thinking about performance. It feels so rewarding when you can make something use fewer resources, run faster or more efficiently.
It might be my competitive programming background, but I would rather spend 5 hours improving performance by 10% than doing sales that would actually bring in money...
> rather spend 5 hours improving performance by 10% than doing sales that would actually bring in money...
And often that's a false dichotomy.
This website collects many such examples, where more performance was linked to more sales/etc: https://wpostats.com
Is it faster than embedding the styles? Or only faster compared to the framework?
I'm sure the syntax for it wouldn't have been pretty but inline styles not being able support pseudo-classes was a real miss.
Inlining critical CSS seems to work best in SPA models that provide hydration, since they can choose to not request inline CSS on subsequent loads. But there can definitely be advantages to MPAs as well. Honestly I just find CSS a pain to untangle into the critical parts, so I don't usually bother.
Looking at your network graph real quick, you might be able to get away with simplifying GTM. I'm only seeing it load analytics, at least on the client side.
Normally this page is 824KB/15 requests. With an adblocker preventing GTM though, it's 655KB/8 requests. A pretty big reduction.
Also, I see it bootstrapping google-analytics.com/analytics.js, which if I'm not mistaken is the now-defunct GA3's analytics. Could that be nixed?
If you're using GA4, there might be lighter alternatives as well. Though it sucks to lose data continuity, most of their competitor are a _lot_ smaller in JS payload (Matomo, Plausible, umami).
Previously you could also just send the signals directly to GA using the Measurement Protocol, but it seems like they've made that a lot more difficult in GA4. Searching online, it looks like maybe GA4MP can do it, but I've not tested that tool.
You could also just load gtag.js rather than all of GTM if you're not using other tags, but that's still pretty heavy.
Outside of analytics, you might want to look at thumbnail generation. To take the worst offender, speed3.png is being rendered at 512px, but it's actually 2430px wide. Now sure this image is mostly white so it compresses well, but on most images that would make a big difference.
Lossy compression (via TinyPng.com) also brings this image down from 167KB to just 46KB. And if we first shrink it to the displayed resolution of 512px, then it shrinks to just 8KB. That's a 95% reduction from the original!
Image weight is less offensive than JS because it doesn't need to be processed. And if you're using size attributes (you're not), it also avoids CLS problems. But it's still often an easy win when it comes to reducing total page size.
If you wanted to be really fancy, you could generate multiple resolutions (for mobile, etc) and provide all of them in the <picture> tag. Or generate some more optimized format alternatives (webp, avif).
Realistically you probably have some limits due to using GitHub Pages. I do too, so integrating build steps to perform these kinds of optimizations is difficult. Maybe it's possible using GitHub Actions - that's something I'd like to look into for my own site.
Anyway, hope some of this information is helpful to you.
I like GA4, but never got around to removing google-analytics.com/analytics.js. You mean GA4 doesn't need that now to function and I've been loading it for nothing all this time? I'll look into removing that one.
And normally I set all images to loading='lazy', I just realized from your comment that for this post I hadn't. Great catch, and fixed it already.
Thanks for all the feedback!
Can’t do media queries inside inline styles. That’s why tailwind’s responsive utility classes are so effective.
You know what loads fast? Plain HTML.
Also: Get off my lawn!
If a # of pages share style, loading a shared stylesheet once is probably better than each page duplicating it. Also from maintenance pov.
Shared style in separate stylesheet(s), per-page style in each page itself. But I understand author's reasoning for doing otherwise. Btw: great tip about avoiding downloaded fonts! Default fonts are fine with rare exceptions.
Kudoz for trying to make pages load quick. But few users will be bothered by HTML+CSS and (moderate!) use of JS. Network latency is a thing no matter how lightweight a page is. And users are used to that.
What makes websites slow:
Tons & tons of (3rd party) tracking scripts. Tons of <insert web tech here> based "frameworks" without thinking twice how that affects page weight (both network transfer, and client side RAM & cpu load). Pictures of several MB each when lossy encoding at 1/10th file size would do. Video-playing ads (especially bad: those that popup again minutes after you clicked [x] on previous one). "Subscribe to newsletter" or similar popups. Cookie dialogs.
In short: what annoys people on other sites, will annoy users of your site. And what those annoyances are, is well known by now.