Here's a question I have for when e.g. Chrome supports JPEG XL: currently, if you have a <picture> with avif, webp, jpeg, it prioritises them in that order. But with JPEG XL added into the mix, which one is chosen by the browser? AVIF or JPEG XL? Will different browsers make different choices of priority?
And finally, how much longer will the HTTP "Accepts" header continue to get with these new formats?
No, seriously, there’s not generally much point in supporting more than the latest fairly widely-supported format, and a universal fallback format. The advantages of the intermediate format are typically too slight and too transient.
If, for example, you deal with photos and currently serve AVIF, WebP and JPEG, around 80% of viewers will take AVIF despite the implementations all being under three years old (less than one in Apple-land), and that number will continue to climb, so that the WebP in this chain will be helping practically no one within two years. Moreover, adding WebP is already imposing a tiny cost for every viewer and a likely-noticeable cost for storage and maintenance, while frankly only slightly reducing the cost over JPEG for WebP-but-not-AVIF viewers.
It is not that clear. AVIF (and WebP) seems to be performing worse than JPEG at qualities above 90. That is likely 30-40 % of all the images in the internet. Why would these users want to send more bytes of AVIF than they use for JPEG today to maintain their quality choice? They would also lose lightweight decoding and progressive viewing while doing that.
That’s completely irrelevant to what we were talking about. We were discussing whether, if providing JPEG XL and JPEG, there would be any value in also providing AVIF or WebP.
> … qualities above 90. That is likely 30-40 % of all the images in the internet.
I don’t know whether it is, but it shouldn’t be anything like that. For browsing, a JPEG of quality q=90 is ridiculous overkill: that’s the kind of quality you should only get if you’re deliberately downloading high-quality images. A more commonly used figure is q=75, which produces files around 40% of the size of q=90, and most of the time q=60 (around ¼ of the size of q=90) is entirely adequate (perceptually sufficiently indistinct).
I would also expect that such excessive-quality images would be found primarily in systems that don’t support multi-format serving.
I should clarify that when I say “a more commonly used figure”, I mean “among things that have put any consideration into optimisation”. Where not controlled deliberately, tools tend to use the quality of the source image (which is probably around q=90 to q=94), or choose an unnecessarily high value like q=90. But take tools that have put at least some effort into sanity, and you find things like: https://squoosh.app/, a human-friendly tool for manual image optimisation and conversions, defaults to q=75 on JPEG; and the Zola static site generator defaults to q=75 for JPEG <https://www.getzola.org/documentation/content/image-processi...>; and Sharp, a Node.js library used by eleventy-image, defaults to q=80 on JPEG <https://sharp.pixelplumbing.com/api-output#jpeg>.
The considerable majority of images on the web are way higher-quality than they need to be.
I like the images to be at or above quality 94, d1.0 or smaller in jpeg xl. Some other user cares less. Some user thinks that quality 75 is as they came from the camera and it cannot be helped.
And finally, how much longer will the HTTP "Accepts" header continue to get with these new formats?