> This made sense in the days of dialup speeds, but not much anymore.[a]

I have Javascript disabled by default, and I notice a lot of websites (especially newspapers) initially have a blurry <img/>, and later replace it with the sharp image using JS. So there is clearly still a need for this feature, even if web developers don't know about it.

The HTML IMG tag also has a "lowsrc" attribute, that is sadly deprecated now.

There's also a proposal for a loading="lazyload" attribute value to allow images to load when scrolled into view https://css-tricks.com/a-native-lazy-load-for-the-web-platfo... https://caniuse.com/loading-lazy-attr

A bit late of a reply, but <picture> allows specifying multiple sizes of images. Which one will be downloaded depends on the criteria the developer set (generally based on the page or rendered image dimensions).

That might have more to do with the variety of screen resolutions than progressive loading per se

I've just been trying to understand this. I believe the trick is in how with Adam7 there are progressively more pixels displayed with each pass. This allows you to make big changes from one pass to the next, even from almost completely white to almost completely black.

If you then interrupt the connection at the right point - directly after one pass - you can get these animations. But unlike a gif, once loaded they are no longer animated since they are done loading.

Edit: Also important here is the cache policy ('Cache-Control: no-store').

Part of the problem with Adam7 interlacing is that it interacts poorly with compression. The compressor operates on the image data after filtering and interlacing; enabling interlacing means that there is a much weaker relationship between each pixel and the neighboring pixels in the image stream.