I am concerned about lossless JPEG XL decoding 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 am *especially* concerned about CDNs adopting lossless JPEG XL to save <10% on bandwidth costs, and externalizing those costs by degrading my phone's battery life. I suggest shipping only lossy JPEG XL initially, where the benefit is clearly demonstrated, and considering lossless 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:08:20 UTC+1, Chromestatus: > *Contact emails* > [email protected], [email protected] > > *Explainer* > *No information provided* > > *Specification* > https://www.iso.org/standard/85066.html > > *Summary* > Adds support for decoding JPEG XL (image/jxl) images in Blink using > jxl-rs, a memory-safe pure Rust decoder (https://github.com/libjxl/jxl-rs). > JPEG XL is a modern image format standardized as ISO/IEC 18181 that offers > progressive decoding for improved perceived loading performance, support > for wide color gamut, HDR, and high bit depth, and support for animation. > > *Blink component* > Internals>Images>Codecs>JPEG XL > <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3EImages%3ECodecs%3EJPEG%20XL%22> > > *Web Feature ID* > jpegxl <https://webstatus.dev/features/jpegxl> > > *Motivation* > (see Summary) > > *Initial public proposal* > *No information provided* > > *TAG review* > https://github.com/w3ctag/design-reviews/issues/633 > > *TAG review status* > Issues addressed > > *Goals for experimentation* > > > *Risks* > > > *Interoperability and Compatibility* > No special risks. Note that the C++ and the Rust version are both tested > against the same conformance test corpus. > > *Gecko*: Shipped/Shipping also migrating to rust version > > *WebKit*: Shipped/Shipping WebKit currently uses the C++ decoder. > > *Web developers*: Strongly positive > > *Other signals*: > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > New feature, no special risk > > > *Debuggability* > *No information provided* > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > https://wpt.fyi/results/jpegxl?label=experimental&label=master&aligned > There is extensive conformance testing outside of WPT too. WPTs show > failures because the flag is disabled in wpt runs. > https://wpt.fyi/results/jpegxl?sha=3d06a34791fc33532baffe64e5c48c450cb1a1b9 > shows a run with the flag enabled, which has two failures. The > icc-uncommon-profile-reftest.html failure is a small difference visually, > currently investigating. The cmyk-basic-conversion-reftest.html failure is > being fixed in > https://chromium-review.git.corp.google.com/c/chromium/src/+/8275513 > > *Flag name on about://flags* > enable-jxl-image-format > > *Finch feature name* > JXLImageFormat > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Availability expectation* > Feature is available on Web Platform Baseline within 12 months of launch > in Chrome. > > *Adoption expectation* > Feature is considered a best practice for some use case within 12 months > of reaching Web Platform baseline. > > *Adoption plan* > Multiple players on the web have expressed interest in deploying JPEG XL > images, including at least Cloudinary and Shopify, as well as multiple web > developers during the Interop process. > > *Non-OSS dependencies* > > Does the feature depend on any code or APIs outside the Chromium open > source repository and its open-source dependencies to function? > No. > > *Estimated milestones* > > No milestones specified > > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > N/A > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5114042131808256?gate=6594362739916800 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > -- You received this message because you are subscribed to the Google Groups "blink-dev" 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/chromium.org/d/msgid/blink-dev/8d985ba0-b954-411b-8ca6-2491fb030459n%40chromium.org.
