The article makes a good point: JPEG XL is amazing but not specifically for the typical Web use cases, compared to AVIF. But the conclusion doesn't follow. Having an excellent and versatile format supported by browsers is very useful!

Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% longer decode, and maybe the website doesn't need very high resolution images or more than 12 bits per channel. But my personal archives can definitely use that and it's great that such files can be viewed everywhere without specialized tooling, including served on the intranet and indeed the Web.

In summary JPEG XL easily beats AVIF on the not-so-long tail of use cases and having compatible viewers everywhere is quite useful. And with JPEG XL becoming part of PDF, it will soon be common use cases too.

As for the rest of the article: there are interesting points in the benchmark section but I think it's too early in the JPEG XL adoption cycle to draw conclusions. One thing bothers me though: There is a single picture comparison (with tag line "results speak for themselves") and I find it quite misleading: it's just picking one point on the "bytes received" line that looks best for AVIF compared to JPEG XL. Try it yourself and you'll see JPEG XL shows something already at 2KB while AVIF has nothing until 8KB, and JPEG XL looks better than AVIF after 100KB.

+1, this is super unfair to show the one point in time where AVIF progressive looks better - right after it receives its 'preview' (which as you say is 4x as big as JPEG XL's).

I value integrity, especially when communicating results. This is shameful.

(Disclosure: I worked on JPEG XL)

For progressive, I think it's better to show the user something that's obviously a preview, but still has enough detail to be able to know what the picture is of.

If you're showing the user something that they may mistake for complete but poor quality, that's a bad experience.

> Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% longer decode,

And pray tell how much of the waiting for page is used on decoding image (vs transferring) and how much faster the image gets on the machine when it's 20% smaller on average connection?

My guess is that time saving from bandwidth decrease more than compensates for that

> Maybe re-encoding my website JPEGs to gain 20% size is not worth the 33% longer decode

I changed all my .jpg files to .avif a few years ago. The benefit I get is much more than 20%. Now there is some loss when I use high compression with .avif, in particular via gimp - but other than that, I gained a lot of file size here, definitely much more than 20%. It also depends on the image at hand; I noticed that images with a ton of details, such as if you photograph a garden, takes more space. But for simpler images, I have easily gains of about 60% or 70% compared to jpeg, with no or almost no loss in quality. Whereas if I were to use jpeg compression, the quality loss would be insanely high. When I noticed this, I decided to abandon .jpg for my own use cases. I had to choose back then between avif and webp and while webp is fine, I found .avif was slightly better for the use cases I had.

I don't quite know how much jpeg xl performs, but you mentioned JPEG so I had to comment on that 20% statement as I found it way too low.

I also find the claim "longer decode" not correct. I have some photographs of gardens and the file size is huge, in JPG. When I compressed and changed these into .avif, the resulting page loads soooooooo much faster now when having used avif and a considerable but acceptable compression of it. It is just no comparison at all - avif beats jpg with its eyes closed.