I just wrote about a workaround for the fact that there is no @supports(webp) in CSS and thought this might be useful to people here who want to improve loading times of their webpages and webapps. I used this to reduce the size of the game board of Royal Ur (check my profile!) by 60% (from 314kb to 127kb).
https://dev.to/janhohner/webp-support-detection-with-supports-and-media-1fm
That’s an interesting approach. I also added WebP-support to my site recently, but did so on the server: https://islovely.co/newsletter/archive/serving-webp-images
This way, only browsers that support it get the WebP-version. Works like a charm, but wouldn’t work on hosting where you don’t get that level of control.
Very cool approach, maybe I'll switch to that. Sounds a lot safer than the CSS construct I've built. Thank you for sharing!
Is the
[at]supportsbrowser support so much better thanwebp? I think most users who have outdated browsers and don't support webp, won't support[at]supportseither. I think the only exception is Safari, which supports the CSS query, but not webp.Yeah, and thats exactly the problem. I can't rely on just [at]supports because then Safari users would get WebP images.
But isn't that what the article solution suggest, right? To use [at]supports.
There is no browser who supports WebP but not [at]supports ?
No, it suggests a combination of [at]media and [at]supports. The first [at]supports is inside an [at]media that keeps Safari out but works on Chrome 66+, Edge 79+, Opera 53+, Android Brower 80+ and the second [at]supports is so specific that it only works on Firefox 66+.