| Part of the problem is that images are used by everybody, including the non-technical people. It is usually the non-technical people that make the images, so we can't confuse them with file formats. Hence the workflow with least amount of man-splaining is to stick to what the non-technical people know. Let them create everything in PNG (or JPG) with absolutely no compression whatsoever. Then have the origin server for the CDN substitute every requested image for a webp variant, mashed down to acceptable compression levels for the product/customer. Since browsers don't care about file extensions for images, the images can be served with '.jpg' or '.png' extensions but contain webp. The browser will be fine with this because of the internal header in the image file. Note that if the customer/user right clicks to download one of these webp images pretending to be png/jpg they should get served the PNG or JPG original, rather than the compressed webp. Yes it requires the origin server to read the headers and the CDN to read the headers too, however, this can be setup to be transparent to the people that create the images and the people that see them. If the images are overly compressed or not compressed enough, the CDN cache can be cleared. Note that this approach could be used to support JPEG XL right now, serving JPEG XL to browsers that support it and webp to those with lesser browsers. What I find amusing about JPEG is that it was optimised for analogue CRTs and slow CPUs. We now have digital screens and fast(er) CPUs. The Mozilla encoder is easy to retrofit and this makes JPEG images better suited to what we have now rather than what we had in the 1980s. Things like banding goes away and the file sizes are smaller. Yet nobody adds the Mozilla libjpeg to their /bin/local. |