4 ms·
how about a serverside implementation? Try loading native webp, if that fails, send the webp data to a webp-to-png service and render in png on the client. Perf
by user24 16y ago
how about a serverside implementation? Try loading native webp, if that fails, send the webp data to a webp-to-png service and render in png on the client. Performance would probably be fine, and imagemagick or something similar will probably support webp soon so the server won't require us to write a whole webp implementation.
- antimatter15 16y agoThat negates the purpose of a bandwidth-efficient lossy image format.
- user24 16y agoeven my original idea would require a double-hit to the server, because I don't think you can extract data loaded into an image element through JS, so you'd have to read the src attribute and re-request it via XHR as raw data, and then parse that into a replacement canvas element. The main benefit is being able to default to webp, and save all your resources in that format alone, and provide a fallback for browsers which don't support it, instead of having to provide 2 sets of images and serve different ones depending on the browser.