How To Reduce Image Size With WebP Automagically | Hacker News Reader

How To Reduce Image Size With WebP Automagically

blog.netdna.com

77 pointsjdorfman22 comments

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.

I too like webp, both for lossy and lossless images (particularly lossless), and you're right, the best I got (lossless) was 34.5kb using:

cwebp -lossless -pass 10 -m 6 MaxCDN-WebP.png -o image.webp

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

Exactly. The 11kb WebP version shows visible degradation: http://f.cl.ly/items/140L0J3d203g410d0m3T/webp-colors.png

The same image can be made into a 13kb PNG (8-bit + imageoptim), without any complex trickery and 99.5% browser support: http://f.cl.ly/items/303H1k2c412s1o0m1b2m/webp-8.png

Lossy plus alpha isn't cheating, its a legitimate gap in the market. It's also the feature that prompted Mozilla to look at the format again.

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.

A minority browser giving up on a fringe image format is hardly first degree murder. More like giving up on CPR after it clearly wasn't helping.

But lossy + alpha was a good idea then and it still is now.

"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).

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=195280

http://css-ig.net/articles/test-webp-021

That's the old 0.21 version being tested, 0.30 was just released.

> 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.

At the time, 40-60% of Yahoo page views were done with an empty cache: http://www.yuiblog.com/blog/2007/01/04/performance-research-...

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)

@bajsejohannes that is actually a great idea.

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.

TBL wrote about this in 1998: http://www.w3.org/Provider/Style/URI.html#remove

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.

FWIW, pngquant compresses the png to 18kb without any visible (to me) artifact.

If you are not using pngq/pngquant and the likes to compress alpha png I advise you to try them out.

I just tested pngquant vs webp on a corpora of 1000 png images.

WebP beat pngquant by a factor of 2.36 (I hope to release the full report and data set soon.)

I was one month ahead of HN :-) https://twitter.com/michrome/status/312133258450182144

Huge pain point!!!! Waste to much time resizing images.

Reply on news.ycombinator.com