I think this is a real risk, but we should expect adoption to ramp up quite slowly, and that there will be time to optimize. The usage can be seen at https://webstatus.dev/features/jpegxl or https://chromestatus.com/metrics/webfeature/timeline/popularity/418 (same underlying data) and should start rizing from ~0 only after this reaches stable.
On Tue, Aug 25, 2026 at 10:04 PM Sergey Davidoff <[email protected]> wrote: > What I am concerned about is CDNs using lossless JPEG XL to cut their > network costs, and externalize those costs by degrading battery life for > all users with recent enough browsers. They are financially incentivized to > do so, and that is why I am so concerned about giving them the opportunity. > > вт, 25 авг. 2026 г. в 20:16, Birk Hirdman <[email protected]>: > >> Moreover, the encoder can be configured to prioritize decoding speed over >> maximum compression -- for example, setting --faster_decoding 1 does not >> change the compressed size significantly, but doubles decoding speed. >> >> >> Then perhaps only fast-decoding lossless mode should be supported in web >> browsers. A 7.5x slowdown instead of 15x might be excusable, depending on >> the use case. >> >> >> Surely websites can select compression options that fit their use cases? >> Perhaps all that is needed is to change the default in libjxl's CLI tool to >> use faster_decoding=1. >> > -- 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/CAARdPYf%2BxbWzjyXpiGqLbqs1WCeQYLjMDD0LZJKq7A5TeQPnvg%40mail.gmail.com.
