seaQueue , 1 month ago (edited 1 month ago)

Optimized jpegxl decoding can be as fast as jpeg but only if the browser supports the format natively. If you’re trying to bolt jxl decoding onto a legacy browser your options become JavaScript and WASM decoding. WASM can be as fast but browsers released before like 2020 won’t support it and need to use JavaScript to do the job. Decoding jxl in JavaScript is, let’s just say it’s not fast and it’s not guaranteed to work on legacy browsers and older machines. Additionally any of these bolt on mechanisms require sending the decoder package on page load so unless you’re able to load that from the user’s cache you pay the bandwidth/time price of downloading and initializing the decoder code before images even start to render on the page. Ultimately bolting on support for the new format just isn’t worth the cost of the implementation in many cases so sites usually implement fallback to the older format as well.

Webp succeeded because Google rammed the format through and they did that because they controlled the standard. You’ll see the same thing happen with the jpegli format next, it lifts the majority of its featureset from jpegxl and Google controls the standard.