- We evaluated WebP, and found that it compresses app icons to half the size of similar quality JPEG, while keeping the alpha channel (that JPEG lacks).
- WebP at 75% compression is equivalent in perceived quality to JPEG at 90% compression.
- We went ahead and made our Android app use WebP.
If you haven’t already tried Everything.me Home, let us tell you a bit about what it is:
Basically, we turn your phone to a dynamic phone, and by Dynamic we mean providing relevant apps in context to user queries on Android and Firefox OS phones. You tell us what you want — we show you a mix of apps — installed, native and HTML5.
(although really, just go download the app, it’s free and rather nice, in our opinion)
It looks like this:
This means that for every key stroke from our users, we respond with lots of icons.
We employ some clever caching on the client side, and optimize as much as we can (more on that in future posts) — but that still results in lots of icons sent from our servers.
And we want to send those icons fast, and strive to be faster still.
When examining our search API payload, it’s easily noticeable that icons take the better part of it, plus we wanted to send icons with transparency back to our clients and PNG was a no-go because that would make our API response size too big.
We started musing with the option of using WebP, a relatively new image format that Google introduced a couple of years ago, to serve all those icons and save us from the dreaded bloated API response. The specs are awesome: better lossy compression than JPEG at the same file size (or same quality with much smaller files), and real alpha channels, so we could display nifty transparent icons on top of cool looking ever-changing backgrounds.
And it is open source, patent free, and already supported on recent versions of Android, Chrome and Opera.
But before going full steam ahead, we had to find out for ourselves if WebP is really all it says it is.
Before we’ll show you the full results, let’s try a guessing game: can you spot the differences (aside from 50% reduction in file size) between the twins below?
One was encoded in WebP, the other in JPEG. See if you can you tell which is which.
(We converted both back to PNG so you can’t cheat)
Now for the results of our little case study in compressing icons with WebP, which as you can guess, shows it delivers on its promise.
What we did
We started with a set of 1000 app icons from the Google Play Store and compressed each to a WebP file, using the default quality setting of 75 (out of 100).
We then used a method called structural similarity (SSIM, for short), to find out how similar the compressed image is to the original image. That gave us an empirical estimate of how lossy the compression was.
We then took each icon, and again compressed it as JPEG.
We iterated over the JPEG quality setting, until we found one that provided a similar similarity index to that we got from WebP.
To be fair towards JPEGs, as they can not encode an alpha channel, we didn’t take the alpha values into account when calculating similarity for JPEGs. And we gave JPEG another handicap: we tried to err towards having our JPEGs more lossy than our WebPs.
The results were better than we hoped for:
|Average ratio to original PNG size||Average DSSIM|
|JPEG||40.4% (with alpha channel removed)||0.09961 (compared to source without alpha channel)|
Just look at the chart — no matter the size of the source images, WebP always won, beating JPEG by half (and having full alpha as well)
If you care for the gritty details, you can find the full report on our GitHub repo that includes the
code used for testing as well.
Well, we went ahead and implemented support for WebP on our both our backend and relevant client platforms that can use it.
Until then, you can try it yourself: try and test your own images, and tell us how much you saved.
Oh, and the twins? The one on the right is JPEG.