When I found this out about jpeg, I was quite amazed. Things could look okay pretty much right away, then get sharper if you give it a second. Shorter loading times and a reasonable image pretty much no matter the size.

In practice, I never really used it. I toyed with it once or twice, I turn it on every time because with jpg it often yields marginally lower file sizes anyway (in gimp you can preview file size and looks), but never heard anyone say "what was that magic" and whenever I see it on websites I think to myself "yeah okay that 20x20 pixel image, it could have saved a render cycle, this is useless and looks terrible" before it downloads to 100% before the next render cycle.

So I'm not sure it will really be missed, even if you saddened my inner nerd. I really do like the feature, it's really neat to just load as much as you wish and get however much 'quality' fits within that data size.

It was really nice in the nineties when we had dial-up and large jpeg images (>100 Kbyte) were loading a bit slower so you didn't have to wait before getting an impression. Now it's important in mobile networks, but you can also opt to turn off images. Who needs images anyway while reading, toddlers?

Progressive use is up since mozjpeg and some other tools (CDNs perhaps?) started defaulting to it. My guesswork is that during the last eight years of format development the biggest winner is progressive JPEG (from 8 % to 25 % of JPEG use). The 'green men' problem and interpolation of progressive JPEG have been fixed recently.

It seems that progressive/interlacing techniques increase the final size. https://blog.codinghorror.com/progressive-image-rendering/

It seems likely that that blog post is wrong in that detail, given that pretty much everyone else says that making JPGs progressive reduces the file size.

All I know (if I remember correctly, I'm fairly certain but won't rule out that I'm mixing things up) is that GIMP has a toggle for it and when it's enabled, it sometimes saves a tiny amount but never seems to get larger. Perhaps the toggle doesn't do what it says on the tin?

The video itself is funny, because it looks like JPG is the first to finish by far, but in reality it still is getting more detail, but more most people that detail is not visible, and by the time they look more closely, it may have already finished loading.

> most people that detail is not visible, and by the time they look more closely, it may have already finished loading

I guess it depends at what point it does the first render. I rarely see images load progressively in the first place, but when I do it's usually with an initial render that looks like 1967 needs their image back. My guess is that it's busy downloading the many/largeish js/css files that prevent it from getting very far on images before the DOM is ready for initial render.

Or maybe, you only notice that one because it's obvious, but most of the time when you see a JPG which you think has finished loading, it's actually still not done but it looks like it's done, as in the example above.

I honestly could not tell it was still going after the 2nd progressive layer.

I kind of dislike progressive loading; certainly the type that's used as an (hypothetical) example in the article. The squashed blurry bad-quality image isn't all that useful, and you're never actually sure if it is or isn't loading a better version in the background. I'm not so sure if it's really better UX, because either 1) you care about the image quality in your use case and a blurry version just won't do, or 2) the image quality isn't all that important and you should be serving smallish images anyway (like the Guardian), possibly clickable to load a high-res version for those who desire it.