Yes but you have to pay a LOT in bandwidth for a <10% savings to be worth the cost of supporting an entire extra toolchain and dealing with the support issues (better now but it took a decade not to have “I right-clicked and now I can’t open it” reports from users). Google and Facebook serve that much but most people do not.
For some datacenters, that 10% saving would be worth the effort and could push back costly maintenance to increase egress bandwidth.
And I would argue that beside Facebook, the end user right clicking and saving the image for them to use in an inappropriate manner ( downloading the image is not the issue, using it without permission would cause copyright infringement ) would be an issue for some of the website that are hosting the image.
We use webp internally for storing very small images that are cropped out of larger images (think individual bugs on a big strip). Webp lets us get them small enough we can store the binary image data directly in postgres which was a lovely simplification.
(We evaluated it for storing a bunch of other stuff but didn't find it worth the compatibility and need to transcode problems)
From experience, in many cases it's 50% savings when done correctly and considerably makes the app\website faster on large images when you have 20-50 images to load on one page.
