jaffathecake

6 ms·

1.
by jaffathecake 9d ago
As someone who speaks at tech conferences, even someone just saying 'nice talk' as I walk past makes my day.
2.
by jaffathecake 11d ago
Hi, I'm the author of the article you're quoting. AVIF was limited at the time of writing, but has since seen massive improvements, including progressive support.
3.
by jaffathecake 11d ago
I also called AV1 short-sighted for not including an alpha channel, and corrected someone who claimed jxl-rs was single-threaded. No agenda here - I'm just correcting misinformation and stating my opinions. I'm not against progres
4.
by jaffathecake 12d ago
jxl-rs is not single threaded.
5.
by jaffathecake 12d ago
I dismissed the bandwidth savings in another comment because the increased decode time undid the benefit. I am not the author of the submission. I have experience in web performance, and my comments come from that experience.
6.
by jaffathecake 12d ago
That's fair, at really high resolution, the JXL decoders in browsers do better than JPEG decoders. I'm pretty sure this is a weakness in the JPEG decoder rather than the format, but it's still a meaningful result. At smaller
7.
by jaffathecake 12d ago
I'm not sure where you're getting those numbers from. But, in the cached case, the download time is very fast, yes.
8.
by jaffathecake 12d ago
Cool. You're getting different results to everyone else. Do you see the same on https://random-stuff.jakearchibald.com/apps/img-decode-bench... (make sure you use a browser that supports JPEG XL)?
9.
by jaffathecake 12d ago
I disagree with this. If I'm in a poor connectivity situation, a preview can help me quickly decide if an image is worth waiting for. I'm not talking about blurhash here - those are 'cute' at best. I'm talking about
10.
by jaffathecake 12d ago
If you're on a train, or a congested area, even 100 kB is a problem.
11.
by jaffathecake 12d ago
This is a thread and article about JPEG XL on the web.
12.
by jaffathecake 12d ago
https://random-stuff.jakearchibald.com/apps/img-decode-bench... Taking bike.jpg and bike-repackaged.jxl in that demo, on my Pixel 10 Pro in Firefox Nightly, the size and decoding times are: bike.jpg - 147 kB - 10ms bik
13.
by jaffathecake 12d ago
The DoS thing would certainly make me worry about handling these images on my server.
14.
by jaffathecake 12d ago
It was only ever supported behind a flag. Stuff behind a flag isn't 'supported', it's experimental. The experiment ended.
15.
by jaffathecake 12d ago
If the bandwidth saving gets you the image 10ms sooner, but due to the decoding time it takes 70ms longer to display, you're losing. And in the cached cache, the bandwidth saving is gone, and you're still paying the decoding penal
16.
by jaffathecake 12d ago
The author covers it: > JPEG recompression is the ability to losslessly re-encode JPEGs as JXL images while saving bits; the oft-cited number is 20% savings. However, the user pays for this in decode time, as recompressed JPEGs take ~33%
17.
by jaffathecake 12d ago
"Web optimised" really means "internet transfer optimised". Eg, the benefits would also be there for native apps that are downloading images from the internet, and they're not the web.
18.
by jaffathecake 12d ago
Well it obviously depends on the connection, but at 3g speeds and higher, the decoding time outweighs the fairly minor bandwidth saving. And if you're displaying a cached image, the bandwidth use is zero, but the decoding still happens
19.
by jaffathecake 12d ago
Just to put some numbers to this, I looked at an image I recently took with my phone: Original image (JPEG): 3072×4080, 2.6 MB. Transcoded to JPEG XL: 2.1 MB. To display at 2x density on my web page, it would be 1598×2122. Lossless JPEG XL:
20.
by jaffathecake 12d ago
I don't think the truncation thing is beneficial to the web. By the time the browser would terminate the connection, it has likely downloaded way more than it needs https://jakearchibald.com/2025/present-and-future
21.
by jaffathecake 12d ago
In terms of AVIF, only Chrome supports progressive decoding. In terms of JPEG XL, Firefox and Chrome support progressive decoding, Safari does not. In all cases, the browsers are able to render the final image, they just don't show the
22.
by jaffathecake 12d ago
This is outdated thinking. AVIF is really good at sharp lines & gradients. https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/#:~...
23.
by jaffathecake 12d ago
One advantage to animated AVIF is that it supports an alpha channel, which AV1 doesn't. But I guess that just points to how short-sighted it was for AV1 to omit alpha channel support.
24.
by jaffathecake 12d ago
You are correct. However, AVIF does not require this conversion. For lossless it supports an "identity" matrix coefficient, which means no conversion. It isn't particularly efficient in terms of file size, but as others have
25.
by jaffathecake 12d ago
I think the need for lossless images within a web page is extremely niche. I've used them before when comparing image codecs, but that's about it. In cases where you need lossless, WebP is there. It's close to JPEG XL's
26.
by jaffathecake 12d ago
The time would be less, but you still need to power those cores. Single thread performance can be a good indicator of what it'll do the battery on your phone.
27.
by jaffathecake 12d ago
Yes but the decode time is orders of magnitude more.
28.
by jaffathecake 12d ago
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
29.
by jaffathecake 12d ago
Professional web developers want to create a great experience for their users, so they go beyond simply serving whatever comes off a digital camera. As the article identifies, JPEG XL is kinda bad at certain types of images, whereas AVIF do
30.
by jaffathecake 12d ago
Have you tried the latest AVIF encoder? It's quality setting seems much more stable.

More ›