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.
