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.
- No JavaScript necessary
- All profile images turned into one massive sprite
- Minimal payload size
Here are what the tweets look like when rendered: https://umaar.com/dev-tips/feedback
Here's the code to achieve that: https://github.com/umaar/better-twitter-embed
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.
[0] https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
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 :)
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?
https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
(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.)
> For example, vanilla `<img>` will ship the same image to every device,
As it should be, for simplicity's sake.
Designers trying to assert pixel-perfect control of layout is part of why the web sucks so much today.
Let the browser handle layout, that is one of the things it is designed 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).
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.
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...