3 ms·

Polyfills for image and video formats are pretty much never going to be worth it: they’ll be a fairly hefty chunk of code (so you’ll need a lot of shrunk-by-usi

Polyfills for image and video formats are pretty much never going to be worth it: they’ll be a fairly hefty chunk of code (so you’ll need a lot of shrunk-by-using-the-polyfilled-format images to balance it out), and they’ll load much more slowly than the native (so that lot of images is now a liability), while not being able to smooth loading the way stuff native to the browser does. I don’t think a compelling reason to do it that way has ever or is ever likely to exist; it’s an all-round bad idea in practice. Just fall back to a different format, that’s what <picture> is designed for.

Dylan16807 5y ago
I'm not sure how big a jxl decoder has to be, but there's a wasm webp decoder that zips to about 50KB. That kind of cost pays for itself very quickly. And whether it loads faster or slower depends on your connection. But yes it hurts to not get the smoothness benefits.
- chrismorgan 5y ago
  Hmm… https://webmproject.github.io/libwebp-demo/webp_wasm/index.html https://webmproject.github.io/libwebp-demo/webp_wasm/index.h... ships 141KB/54KB (bytes/transferred) of WASM and 116KB/34KB of JavaScript, including lots of bogus SDL stuff. https://kenchris.github.io/wasm-webp/ https://kenchris.github.io/wasm-webp/ is 120KB/44KB of WASM and 30KB/9KB of JavaScript, much more reasonable. (Incidentally, I never like the JavaScript such tools produce; it’s always hideously unoptimised. Experience suggests to me that I could reduce that 30KB to under 10KB with a little effort, and possibly to under 5KB; and if I could touch the WASM as well, still further.) Definitely smaller than I thought I recalled, and WASM bytes are no dearer than image bytes, though JS bytes are much more expensive, so it’s closer to just the more expensive decoding of the actual images that’ll bite you. Plus the not-integrated loading experience, of course.

Dylan16807 5y ago

I'm not sure how big a jxl decoder has to be, but there's a wasm webp decoder that zips to about 50KB. That kind of cost pays for itself very quickly. And whether it loads faster or slower depends on your connection. But yes it hurts to not get the smoothness benefits.

chrismorgan 5y ago
Hmm… https://webmproject.github.io/libwebp-demo/webp_wasm/index.html https://webmproject.github.io/libwebp-demo/webp_wasm/index.h... ships 141KB/54KB (bytes/transferred) of WASM and 116KB/34KB of JavaScript, including lots of bogus SDL stuff. https://kenchris.github.io/wasm-webp/ https://kenchris.github.io/wasm-webp/ is 120KB/44KB of WASM and 30KB/9KB of JavaScript, much more reasonable. (Incidentally, I never like the JavaScript such tools produce; it’s always hideously unoptimised. Experience suggests to me that I could reduce that 30KB to under 10KB with a little effort, and possibly to under 5KB; and if I could touch the WASM as well, still further.) Definitely smaller than I thought I recalled, and WASM bytes are no dearer than image bytes, though JS bytes are much more expensive, so it’s closer to just the more expensive decoding of the actual images that’ll bite you. Plus the not-integrated loading experience, of course.