[TD-Linux]

A progressive image format doesn't really fully solve the problem, it's only a potential bandwidth improvement. In both the case of a progressive and non-progressive image, you potentially prefetch the wrong asset - either a too low resolution image, or too few bytes of the progressive image, and you are stuck either waiting or displaying a too low resolution version of the image. The only advantage of the progressive format is that the prefetch bytes aren't wasted - as a rough estimate, if you grabbed the 1x image instead of 2x, you ended up using 125% as much bandwidth as intended. A nice improvement but also much smaller than just using a better image format in general. Likewise, it doesn't remove the need for container queries, you'd still at least want a byte offset for the complete base layer.

[pancrufty]

I think browsers could nowadays figure out when enough bytes result in enough quality. Progressive images should have been the solution since the very beginning and it’s disappointing (yet expected) that they aren’t.

I really wish I could just point to the canonical source of an image and have the browser decide how much of is needed like it does for video segments.

Thumbnail: load 1000 bytes

Drag to desktop: download the remaining megabyte of your full-quality image

The current picture/sizes setup is a verbose joke hacked together because they refused to use progressive JPEGs for this purpose, which we had for a very long time. This whole thing could have been a single `<img progressive>` attribute

[zamadatix]

Browsers seemed to resist having a ton of in flight connections for a long time but I don’t know if that’s a problem with newer versions of HTTP including stream multiplexing. Though maybe it’s still not great for the server side?