As much as I like WebP, the numbers given in this article are misleading. The original image is indeed 52 kb. If you like optimizing PNGs, you can recompress it (losslessly, obviously) to ~49 kb. Now the same image in WebP is 35 kb, not 11 kb. The only way for WebP to make it a 11 kb image is to compress it in lossy mode.
Granted, even at 11 kb the image looks really good and there are no visible artifacts but when you put the original image and the lossy version side-by-side, you can see that some tones are slightly off and gradients/shades are slightly different.
Still that's not a bad compression improvement given that 'pngcrush -brute' failed to improve compression and pngout managed only to bring it down to 50.1kb
We had lossy RGBA many years ago with JNG (a simple PNG/JPG mashup format), but Mozilla killed the format along with MNG. The reason was that the MNG lib added about 100kB to the installer. They suggested to use Flash instead. (Yes, seriously.)
With JNG those massive parallax websites could be ~1MB instead of ~5MB.
"Minority browser"? What's that supposed to mean? Anything other than Chrome? Or, if we go back a few years, anything other than IE?
In case you didn't know, there are 3 very important browsers: Chrome, Firefox, and IE. Right now, Firefox got around 20%, IE around 30%, and Chrome around 40%.
There are also a few countries where Firefox is the most popular one. For example, in Germany it currently got around 45%.
>a fringe image format
Was PNG any different? People usually don't randomly start to use some image format if it isn't supported by any browser.
Also, ripping two images out of one file and splicing them together requires very little code. In a high-level language it's maybe 50 lines of code. There are many games which do that. It's very simple and it saves typically around 80%.
I don't know why the GP said "minority browser", but to be fair to them, it appears that Mozilla removed MNG and JNG in 2003[1], when that certainly was a fair description of the Mozilla Suite and Phoenix/Firebird/Firefox marketshare.
Interesting to see Hixie in there advocating for MNG (or, rather, for a format with 8-bit alpha and animation that's not Flash).
> But with CDN Connect’s automatic image re-encoding, this 52kb PNG shrunk to a 11kb WebP image. That’s a 78% size reduction! Just imagine this image was referenced on every page of your site, and you had handfuls of similar images to download. The potential bandwidth savings and performance improvements are enormous.
What utter garbage. Does CDN Connect want us to believe browsers don't cache images? Sure, that's a savings.. of about 41kb total. Not 41kb per page, just 41kb overall, because my browser's only going to download the image once.
depends what your client is. on a desktop, yeah it's going to download once. on your phone, where it really matters, that's going to end up being a saving just about every time you visit the site.
Neat. Though for my own sanity, I'd probably use a file extension like .image for URLs that return different content type based on the Accept header. (And leave .png and .webp untouched so I have the option to use those explicitly)
In URLs, and especially user-visible URLs, file suffixes at all should be considered an only occasionally necessary evil. They’re ugly, redundant, brittle, and generally a headache.
Though probably do transmit a "Content-Disposition: inline; filename=foo.jpg" header. Otherwise, the OSes that infer media type from extension will get confused when the user goes to save the file and it appears extensionless.
(That might be called a browser bug, actually; it'd sure be nice if browsers on these OSes could take the observed media type and tack on an extension to extensionless files on Save As to ensure they'll be viewed by the OS to have that same media type. Or it might be called an OS bug: why the heck don't filesystems have a required media-type metadata field for files yet!? ;)
it is neither the OS' nor browsers responsibility to launch correct application for a file. There are launchers that examine file headers (no need to dup it on filesystem) and keep track of your application preferences for a given mime type. They may be called file manager, shell or something similar and responsibility lies there. 8.3 file naming is a historical baggage and nothing more.
Granted, even at 11 kb the image looks really good and there are no visible artifacts but when you put the original image and the lossy version side-by-side, you can see that some tones are slightly off and gradients/shades are slightly different.