2 ms·

I didn't realize progressive AVIF was a thing recently either; the comparison between that and jxl was pretty surprising.

by adzm 12d ago

nneonneo 12d ago
Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.
- est 12d ago
  Perhaps it's just a bad example. I suppose avif can support multiple "scans" of progressive encoding as well.
- computerbuster 12d ago
  I believe wholeheartedly that AVIF's approach is significantly better UX.
  - oofdere 12d ago
    What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
    - juliobbv 12d ago
      The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
  - zeratax 12d ago
    why? in jpeg xl i get an image quicker and i can see it getting better, so i know it's still loading while the avif one looks stuck for the majority of the time, which makes it look already done loading and just low quality to me.
- juliobbv 12d ago
  Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic. That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
  - janwas 12d ago
    I find it misleading to call AVIF's "up to four passes" "very flexible". It seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions first [1]. [1]: https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html https://opensource.googleblog.com/2021/09/using-saliency-in-...
    - 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-of-progressive-image-rendering/#what-about-progressive-rendering-instead-of-responsive-images https://jakearchibald.com/2025/present-and-future-of-progres...
      - janwas 12d ago
        Sounds like some strong assumptions here, particularly a stable and non-metered connection. Imagine fast scroll across an image gallery on a slow connection (including cell handovers). Or range requests, where a service worker only downloads the header+preview portion, and when clicking on the image, no need to re-download that. Or even a browser that truncates all images, to protect users who might visit a page with huge background images that blows through their prepaid data plan. JPEG XL anticipated, and accommodates, these use cases.
    - juliobbv 12d ago

I didn't realize progressive AVIF was a thing recently either; the comparison between that and jxl was pretty surprising.

by adzm 12d ago

I didn't realize progressive AVIF was a thing recently either; the comparison between that and jxl was pretty surprising.

nneonneo 12d ago

Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.

est 12d ago
Perhaps it's just a bad example. I suppose avif can support multiple "scans" of progressive encoding as well.
computerbuster 12d ago
I believe wholeheartedly that AVIF's approach is significantly better UX.
- oofdere 12d ago
  What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
  - juliobbv 12d ago
    The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
- zeratax 12d ago
  why? in jpeg xl i get an image quicker and i can see it getting better, so i know it's still loading while the avif one looks stuck for the majority of the time, which makes it look already done loading and just low quality to me.
juliobbv 12d ago
Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic. That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
- janwas 12d ago
  I find it misleading to call AVIF's "up to four passes" "very flexible". It seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions first [1]. [1]: https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html https://opensource.googleblog.com/2021/09/using-saliency-in-...
  - 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-of-progressive-image-rendering/#what-about-progressive-rendering-instead-of-responsive-images https://jakearchibald.com/2025/present-and-future-of-progres...
    - janwas 12d ago
      Sounds like some strong assumptions here, particularly a stable and non-metered connection. Imagine fast scroll across an image gallery on a slow connection (including cell handovers). Or range requests, where a service worker only downloads the header+preview portion, and when clicking on the image, no need to re-download that. Or even a browser that truncates all images, to protect users who might visit a page with huge background images that blows through their prepaid data plan. JPEG XL anticipated, and accommodates, these use cases.
  - juliobbv 12d ago