Note from 20 January 2022

It looks like when I preload an image on #Cloudinary, the automatic best format selection (f_auto) doesn't work! 😱

These two requests have the exact same URL:

The same URL doesn't get the same result

13 reactions

1 like

12 replies

Eric Portis
Is the URL that's loading these public?
- 20 January 2022, 19:34
- Source
Nicolas Hoizey
The page is there, if you want to try:
nicolas-hoizey.photo/map/

I was using Firefox on macOS.

+ @etportis
- 20 January 2022, 19:35
- Source
Eric Portis
Looks like the non-preloaded version is loaded in the canvas JS? I wonder if FF sends a different Accept or something in those circumstances.
- 20 January 2022, 19:46
- Source
Eric Portis
Lots of fun differences between the two requests. Not suprised FF isn't able to re-use the preloaded image, given them; also need to figure out why removing AVIF from the accept header changes CLD's decision from PNG → WebP 🤔
- 20 January 2022, 19:51
- Source
Nicolas Hoizey
It is loaded by Mapbox GL JS, indeed. It’s the one that gets transferred as WebP.

I didn’t check the Accept headers.
- 20 January 2022, 19:55
- Source
Nicolas Hoizey
It is strange, maybe Mapbox injects an Accept header different from the default one of the browser… 🤔
- 20 January 2022, 19:58
- Source
Eric Portis
Browsers also use different headers in <img> vs JS contexts.

Looks like Chrome is somehow only loading this once, which is suprising. Safari loads it twice, with very different Accept headers than FF, and we give it a PNG both times 🙃
- 20 January 2022, 20:01
- Source
Yoav Weiss
Are you using `as=image`?
- 20 January 2022, 20:03
- Source
Eric Portis
@yoavweiss Is there a recommended pattern to preload image assets for use in a canvas? I don't think the as=image is doing @nhoizey any favors here, but don't understand the mechanisms well enough to reccomend anything different.
- 20 January 2022, 20:04
- Source
Nicolas Hoizey
This is wild! 🤣

I didn’t know about different headers for JS context. Is there a documented reasoning?
- 20 January 2022, 20:09
- Source
Eric Portis
A Cloudinary person who understands our internals better than I do walked me through why we respond to the two Accepts FF is sending like we do... TL;DR this is expected behavior given the current system; system may be changing soon so both would get WebPs, as I would expect.
- 20 January 2022, 20:10
- Source
Nicolas Hoizey
Yes, I am:
github.com/nhoizey/nicola…
- 20 January 2022, 20:12
- Source

Jake Archibald

JPEG XL vs AVIF for web use-cases
- Nicolas Hoizey
- 22 October 2026
- WebPerf, image, JPEG XL, AVIF
- 5 reactions
I'll go into full detail, with examples and benchmarks, but for those of you who don't have the time, here are [2 of] the headlines: For lossy photos…
Gianni Rosato

The case against JPEG XL
- Nicolas Hoizey
- 14 September 2026
- WebPerf, image, JPEG XL, AVIF
- 7 reactions
JPEG XL isn't useless; it is genuinely compelling technology for use cases beyond the Web. I'm just not personally convinced we need it in browsers…
Jake Archibald

The present and potential future of progressive image rendering
- Nicolas Hoizey
- 16 October 2025
- image, WebPerf
- 4 reactions
So if the browser manages to download 6 kB then stalls, then AVIF can produce a better result. But since the AVIF rendering is only two-pass, if the…
kliksphilip

JPEG VS AVIF - The Battle of Compression
- Nicolas Hoizey
- 25 September 2024
- image, WebPerf, AVIF, JPEG XL
- 2 reactions
In this super thorough study I test one single HD image and come to vast sweeping conclusions about JPEG XL and AVIF. But that's still one image comparison…
Note from 24 April 2024
- Nicolas Hoizey
- 24 April 2024
- image, JPEG XL, Lighthouse, photography, WebPerf
- 3 reactions
Should I please Lighthouse with modern image formats, or my visitors with progressive rendering of large images in my photography site? 🤔

Of course, this would be much easier with genaralized JPEG XL support, both modern and allowing progressive… 🤷‍♂️

Note from 20 January 2022

Related contents with similar topics