This is an inaccurate over-simplification. If you just use HTML and CSS, you can also have really bad Lighthouse scores. For example, vanilla `<img>` will ship the same image to every device, regardless of viewport size. Vanilla `<img>` doesn't enforce setting `width` and `height`, which makes your layouts shift. Slow-loading images and layout shifts are the very things that will downgrade the "100" score he's currently proud of.
Frontend performance is basically an iceberg[1]. We tend to look at the top and that's where the fashionable "silver bullet" currently is (whether Rust+wasm or HTML+CSS or a JS framework). Then we find deeper in the iceberg that even a `box-shadow` property[2] can ruin our day, and let alone images, YouTube and Twitter embeds, and all the things that make the web more interesting and powerful than a black page with white text.
Oh and it gets even more fun! A Lighthouse score in itself is an over-simplification. There's more to a great experience than the initial impression the site makes, like what happens to FPS when you scroll or click around[2]
Oh boy, YouTube embeds! I went through checking the Lighthouse score on a few of my pages a while back, and the ones that had videos were performing pretty badly.
It turned out that embedded YouTube videos were pulling down something like 1mb of JS, just to show the thumbnail, before the user even clicked Play.
I ended up making a static thumbnail with a hover-over "play" icon that would replace itself with the real embed when it was clicked. Got the Lighthouse score up and saved all those unnecessary downloads. But it was pretty amazing to me that while one arm of Google is pushing for web performance, another is building this YouTube player that auto-downloads a megabyte of JS just to show a thumbnail.
> Vanilla `<img>` will ship the same image to every device, regardless of viewport size.
You can have responsive images with vanilla <img>[0]. You can even lazy load images with just `loading="lazy"` attribute[1]. I'm pretty sure I can optimize more things.
I'm mostly agree with this blog post. Plain HTML+CSS is really good for simple webpages, like landing page or portfolio that requires less update. But for a blog with pagination? I don't think so. Imagine updating each page in plain HTML. SSG can help my life easier.
The point is that "just HTML+CSS" is not the recipe for performance. You get into the same nuance as any other technology: how you use HTML+CSS is the recipe for performance. In fact, his image in this blog post doesn't have `width` and `height` set, so had it been higher up on the page and part of the "Largest Contentful Paint", not sure we'd have a 100 here.
This is where frameworks can be really helpful, and I wouldn't dismiss them. It gets quite tedious to keep up with the new attributes, cross-browser and cross-platform differences, image optimization CDNs and so on :)
At the same time though, in my experience, performance optimizations follow paretto's law: try to get 80% of the way with 20% effort. There are pitfalls both with and without frameworks (e.g. it's equally easy to accidentally plop a hi-res image into a Next.js app), but generally speaking, limiting the tech stack means there's less potential stack-specific pitfalls.
If "I'm gonna restrict myself to HTML and CSS only" gets them 80% of the way to their performance goals then IMHO, that's a perfectly valid approach.
As far as images go, the reality is that most mainstream sites with image/video content are heavy sites with multi-second page load times, despite literal millions of dollars being spent on engineer salaries. In that context, does it really matter if a random blog decides to just use pngcrush and a dumb img tag for the occasional eye candy imagery, instead of whatever is the state of art multi-resolution technology?
Definitely. But notice he's not using the <picture> tag in this post for his image. "Just HTML+CSS" cannot possibly be connected to the 100 score conclusion (same for dismissing WordPress, which could have yielded that element as well.)
I fail to understand why you wouldn't set dimensions for an `<img>`tag or use a `<picture>`tag with `<source>` elements for appropriate variants using just HTML and CSS.
(I'm doing this all the time, also with perfect Lighthouse scores. That is, there's often also a bit of PHP involved for includes and setting some meta tags, and a bit of non-essential JS sprinkled in.)
Removing the dimensions from the image tags is absolutely the wrong thing to do.
If you do this, then a browser/user/client that wants that information simply doesn't have it - you can't create bits from thin air.
If you leave the metadata in, then any browser that wants it can use it, and any brower that doesn't want it can ignore it.
I can code up a Greasemonkey script in a few minutes that will strip the width and height attributes from img tags, but nobody on earth can write a script that will magically detect what size the author wants them to be if they don't send that data to you.
The width and height attributes we have been discussing set the size that the image will be displayed at, which are not necessarily the size of the image transferred.
Those are two very different things. My statement holds - if an image has size (a, b), but the author wants it to render at size (c, d) but does not send that data, the client has no way of magically determining c and d.
Furthermore, even when the actual image size is the same as the width and height attributes, there's the obvious problem of you needing to completely transfer the image itself before determining the size, which blocks rendering (or forces you to re-compute layout a second time, which both increases latency and decreases throughput).
Designers trying to assert pixel-perfect control of layout is part of why the web sucks so much today.
Sending a high resolution image to a user with a low pixel density display is wasting their bandwidth and battery. Sending a low resolution image to a user with a high pixel density display isn't giving them the good experience they paid for when they bought a high end device.
Optimization is about giving all the users the best experience you can on a website. It doesn't necessarily change the design at all.
Well on my low latency nordic cellphone connection, it's always nice to receive a lower resolution image. Especially if I don't have the resolution to display it
It would be good if more browsers and websites implemented the prefer- reduced-data setting that Chrome and Edge have right now, but you do have that option in Chrome for Android right now. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Just meant to be humorous, does your brain not provide any illumination, while at it, do you have time and energy left to address other then software in itself, for adding to the cycle of aggregate rentier-ism?
Frontend performance is basically an iceberg[1]. We tend to look at the top and that's where the fashionable "silver bullet" currently is (whether Rust+wasm or HTML+CSS or a JS framework). Then we find deeper in the iceberg that even a `box-shadow` property[2] can ruin our day, and let alone images, YouTube and Twitter embeds, and all the things that make the web more interesting and powerful than a black page with white text.
Oh and it gets even more fun! A Lighthouse score in itself is an over-simplification. There's more to a great experience than the initial impression the site makes, like what happens to FPS when you scroll or click around[2]
[1] https://rauchg.com/2020/next-for-vercel#realistic
[2] https://ishadeed.com/article/new-facebook-css#using-an-image...