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?

Also sending binary images and rendering them is very light-weight. They are also cache friendly (doesn't change often).