I think supporting this part of JPEG XL is important for compatibility reasons. Safari already supports it, and there's no sign of Chrome removing support for this feature.
That said, I do share some of your concerns. But I'm not *as* worried about it, because, anyone who cares even a tiny bit about performance won't ship lossless imagery. I expect/hope lossless JPEG XL will be a very niche use on the web. That said, I can imagine that in those niche cases, people would use lossless JPEG XL instead of lossless WebP, because of a modest file size saving, without realising they are taking a heavy hit in decoding performance for every user. Personally, I'm more worried that most developers seem to assume that lossy JPEG XL will produce smaller files & decode faster than AVIF at web quality, when neither seems to be true. There's a developer education problem there that I hope to address. Jake. On Tue, Sep 1, 2026 at 12:27 PM Sergey Davidoff <[email protected]> wrote: > Turns out I wasn't measuring jxl-rs performance entirely correctly. > Decoding performance degradation is actually *15x to 20x*, depending on > the hardware. > > The correct measurement command is: target/release/jxl_cli --warmup-reps > 0 --num-reps 1 --speedtest 55_Cancri_e_Final_1_30.jxl > > It is still more than an order of magnitude difference. I find it > difficult to justify, especially considering that it is paid every time the > image is displayed, even from cache, while the 10% of network cost is only > saved once. > > Parallelizing decoding only helps latency marginally: when loading a web > page, most cores are already busy with other work than decoding images. And > parallelism does not meaningfully change power consumption. > > The reason I would much rather not see it supported at all is because CDNs > are financially incentivized to use the highest compression option for > delivering images. If given the option of lossless JPEG XL, they are > incentivized to externalize their network costs by degrading responsiveness > and battery life of end users' devices. > > вторник, 25 августа 2026 г. в 11:40:40 UTC+1, Sergey Davidoff: > >> I am concerned about lossless JPEG XL performance. In my measurements it >> is *30x* slower to decode than lossless WebP, in exchange for a 10% >> reduction in file size. This is a questionable trade-off, especially on >> laptops and phones where it could drain battery and degrade user experience. >> >> I suggest shipping only lossy JPEG XL in Firefox 157, and considering >> lossy JPEG XL format separately. >> >> *Measurement methodology* >> >> I've used https://github.com/sharkdp/hyperfine which measures execution >> time over multiple runs and collects statistics >> >> jxl-rs from git https://github.com/libjxl/jxl-rs on commit >> 775837f57dfe4294d89c1c6317dd91a1ed8d3cfa compiled with 'cargo build >> --release' >> >> Input image: >> https://commons.wikimedia.org/wiki/File:55_Cancri_e_Final_1_30.png >> converted to WebP with 'cwebp -lossless', to JPEG XL with 'cjxl -d 0' >> >> Both decoders running in single-threaded mode to measure total CPU time >> taken with 'taskset -c 0'. >> >> $ hyperfine --warmup 5 'taskset -c 0 target/release/jxl_cli --speedtest >> 55_Cancri_e_Final_1_30.jxl' 'taskset -c 0 dwebp >> 55_Cancri_e_Final_1_30.png.webp' >> Benchmark 1: taskset -c 0 target/release/jxl_cli --speedtest >> 55_Cancri_e_Final_1_30.jxl >> Time (mean ± σ): 20.632 s ± 0.061 s [User: 20.605 s, >> System: 0.027 s] >> Range (min … max): 20.549 s … 20.743 s 10 runs >> >> Benchmark 2: taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp >> Time (mean ± σ): 667.0 ms ± 2.2 ms [User: 449.5 ms, >> System: 217.5 ms] >> Range (min … max): 664.3 ms … 670.1 ms 10 runs >> >> Summary >> taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp ran >> 30.93 ± 0.14 times faster than taskset -c 0 target/release/jxl_cli >> --speedtest 55_Cancri_e_Final_1_30.jxl >> >> For reference, libjxl's djxl tool is 20x slower than WebP in the same >> measurement. So it doesn't look like further optimizations to the Rust code >> could help, but would not change the overall calculus. >> >> понедельник, 24 августа 2026 г. в 12:15:09 UTC+1, [email protected]: >> >>> As of Firefox 157 I intend to turn JPEG XL decoding on by default on all >>> platforms. It has been developed behind image.jxl.enabled, which today is >>> on by default on Nightly only, and has had a Firefox Labs checkbox on every >>> channel since 152. The decoder is jxl-rs, in Rust. >>> >>> Bug to turn on by default: >>> https://bugzilla.mozilla.org/show_bug.cgi?id=2065096 >>> >>> Standard: ISO/IEC 18181, https://www.iso.org/standard/85066.html >>> >>> Standards body: ISO/IEC >>> >>> Platform coverage: all >>> >>> Preference: image.jxl.enabled >>> >>> Standards position: >>> https://github.com/mozilla/standards-positions/issues/522 (neutral) >>> >>> TAG review: https://github.com/w3ctag/design-reviews/issues/633 >>> (satisfied with concerns) >>> >>> Intent to prototype: >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/53b4e3e0-5eee-4768-a1ba-b069e1e85244n%40mozilla.org >>> >>> Other browsers: Safari shipped in 17.0 in 2023. Chrome has it behind >>> #enable-jxl-image-format using the same Rust library, no intent to ship yet. >>> >>> Changes since the intent to prototype: >>> >>> Performance was a concern raised on the intent to prototype thread. >>> jxl-rs 0.6.0 was released with multithreaded decoding support, and our >>> patches to hook up and enable multithreaded decoding are expected to land >>> soon. Including those patches, I ran a five-format decode benchmark over >>> the same pictures at a range of sizes: we were slightly ahead of Safari >>> (using C++ libjxl) on my machine. Compared to our other image format >>> decoders, JXL is close on large images, but shows a bigger gap on small >>> ones. >>> >>> It has feature parity with our other image formats and with Blink's JXL >>> implementation, including animation and progressive display. The one >>> exception is HDR: HDR images display as SDR, the same as every other format >>> we support, but our tone mapping for JXL is much better than what we do for >>> other image formats. Safari has neither progressive rendering nor animation. >>> >>> The wpt jpegxl directory covers decode correctness across bit depths, >>> alpha, grayscale, CMYK, colour management, orientation and the coding >>> tools, plus the HTML and CSS ways an image gets used. Where wpt could not >>> express something I added gecko tests: about 30 gtests for chunked and >>> incremental decoding, animation frame counts, downscale during decode and >>> corrupt files, mochitests for progressive rendering and telemetry, >>> reftests, and decode benchmarks that report to Perfherder. The fuzzing team >>> already fuzzed jxl before it was enabled on nightly and they will fuzz the >>> decoder again before I flip the pref. >>> >>> >>> Timothy Nikkel >>> >>> -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/f2e32401-3683-4c4c-977a-8ceacce078a4n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/f2e32401-3683-4c4c-977a-8ceacce078a4n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAH3w5iDo3d7AumBqK2vvCfdvANfkGe5DeaBZK%2Bwa3cgA0%2BaEDg%40mail.gmail.com.
