Last modified: 2014-05-16 01:26:44 UTC
Created attachment 12041 [details] Sample of savings on a couple logo pngs from http://www.wikimedia.org/ Many of the static PNGs located on the various wikimedia sites (for example the site's logos) don't seem to be optimized fully. Simply running them through ImageOptim a couple times cuts file sizes by 20% (losslessly) on average. Yes these files are small to begin with, but considering how frequently they must be served it seems wasteful not to have them fully optimized.
Any images that are served as is, can likely be replaced onwiki by uploading a smaller version. Any that are being served as thumbnails aren't so easily done. Looking at the specfic page: <img src="//upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png" width="135" height="155" alt="Wikipedia"> https://en.wikipedia.org/wiki/File:Wiki.png
For thumbnails, both MediaWiki core and Wikimedia's specific scalers have various configuration options and features that allow the generated files to be optimised (higher compression, optimising file size, applying gzip compression to the http request). The originals are left unchanged, it's not a lesser good optimisation, there is none. I'm not sure if that's by design, but I don't see that changing any time. We want it both for using checksums, as well as to avoid loss of data in case part of this process goes wrong. However what we could do is never serve the original as a thumbnail. The original is always available if a user visits the "File" description page and downloads it, but when an article embeds an image at a size that happens to not have a smaller thumbnail size available, we currently serve the original. We could probably change that to even serve a thumbnail for the nominal size (like we do with SVGs), which would presumably make our urls a lot more consistent and allows for better optimisation of smaller images. However all those things are separate things and I don't think the bug creator was asking for optimisation settings of thumbnails and/or for us to serve thumbnails but instead concerned with optimisation of the original files. And that specifically would be a "wont fix" because, as far as I know, we intentionally keep the originals untouched. Closing as works for me. There are various other bugs opened already for some of the ideas I mention above. And in addition I filed one just now for always serving thumbnails. * (bug 25611) Serve optimised WebP thumbnails for JPEG/PNG images * (bug 54291) Use gzip for requests of SVG files * (bug 65383) Serve thumbnails even for the original size of a jpeg or png
