5 ms·
So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's
by hug 7y ago
So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's not the only usecase in the world, and there are circumstances where saving ~30% on every image load turns out to be significantly more efficient than not loading a 77KB JS library.
In other news, I also chose to forgo adding a 15 lb. fuel pump to my go-kart, despite the fact that every NASCAR team in the world uses one, and my go-kart drives just fine. I should go tell the NASCAR teams that fuel pumps are a terrible idea. I clearly know something they don't.
- pier25 7y agoYou are missing the point. It's not only about the transferred bytes. You have to actually execute 77kB to display an image. Every image.
- hug 7y agoI am most assuredly not missing the point. Your use-case is not my use-case. I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else. Also, my go-kart also gets more miles to the gallon than NASCAR team cars.
- pier25 7y ago> I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else. Fair point but you have to admit that is a very niche use case. Have you compared the execution to native performance? Even decoding a 50MB JPEG in Chrome with turbojpeg is going to be a hard pill to swallow.
- hug 7y agoI do know it's a niche use case. And I for sure wouldn't recommend that every man and his dog use the polyfill. I'm not even sure it's right for the scenario I'm thinking of. But I can definitely contrive a case where it is. I haven't benchmarked this specific thing, because I've never used it. But I might, because it sounds like a fun thing to do.