_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI The Unreasonable Effectiveness of Inlining CSS
XCSme wrote 39 min ago:
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...
MrJohz wrote 2 hours 15 min ago:
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.
SquareWheel wrote 3 hours 12 min ago:
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 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.
strikingloo wrote 1 hour 27 min ago:
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!
jeffrallen wrote 3 hours 18 min ago:
You know what loads fast? Plain HTML.
Also: Get off my lawn!
mock-possum wrote 4 hours 13 min ago:
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.
RetroTechie wrote 4 hours 15 min ago:
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 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.
DIR <- back to front page