> Obviously, jpeg has this. I know it is supposed to be a 20% reduction in size, but that is a relatively small incremental improvement.
Let's not forget that a 20% reduction across the entire internet is very significant.
> jpeg also has this, and it’s a niche feature these days.
Because we can't rely on it, I'd suspect?
> png covers this
Without covering the rest.
> Not really a reason to include jpeg xl in the browser unless it actually is being widely used across workflows.
This line of thinking will inevitably lead to a chicken-and-egg problem. Just like with EdDSA certificates and for example H/2 PUSH (support of which got deprecated basically the same time some frameworks just added support).
I think the web doesn't move as fast as Google thinks or hopes it does, and it has and will make people reluctant on adopting next new features.
I think progressive jpeg works just fine, I recall it being quite popular in the early days of the internet when loading a large image could take a long time on landlines. You'd get a blurry preview that would incrementally become more detailed.
I agree that it's niche these days because typically modern connection speeds mean that it's a waste of resources to iterate on the picture instead of loading it at once. Even on mobile networks the issues are connection reliability and latency, once the image starts pouring in it'll likely come in its entirety quite quickly.
If you load images large enough that it becomes a real issue you would generally (in my experience) just have a smaller independent thumbnail/preview image you'll display while the large version is loading. That usually gives you more control on how things will look and avoid having a blurry mess on the user's screen.
I don't think that's accurate. Progressive JPEG has been the biggest winner in the image formats during the last 10 years. It grew from pretty much nothing to about 25 % of all JPEGs today.
Much of this is powered by mozjpeg creating progressive jpegs by default. Chrome and other render them progressive, with recent (2019–21) improvements in quality. While first round or two of updates can be noticeable, the last 40–55% of loading is usually impossible to notice as a change.
I can assure you that for anyone dealing with large volumes of storage and/or bandwidth of still images (i.e. pretty much any high-traffic website), where costs directly related to storage/bandwidth are measured in millions of dollars, will not consider a 20% saving to be a "pretty minor" thing.
I agree that in video, the savings can be even more substantial. But keep in mind that the median web page still has zero videos, while the median web page has about 1 MB in images. In practice most of the transferred bytes in web browsing are html (which is very small after compression) and images. Javascript, css and fonts also contribute to the page weight but those tend to often be locally cached since they're mostly static compared to the html and images.
Let's not forget that a 20% reduction across the entire internet is very significant.
> jpeg also has this, and it’s a niche feature these days.
Because we can't rely on it, I'd suspect?
> png covers this
Without covering the rest.
> Not really a reason to include jpeg xl in the browser unless it actually is being widely used across workflows.
This line of thinking will inevitably lead to a chicken-and-egg problem. Just like with EdDSA certificates and for example H/2 PUSH (support of which got deprecated basically the same time some frameworks just added support).
I think the web doesn't move as fast as Google thinks or hopes it does, and it has and will make people reluctant on adopting next new features.