Courting WEBP

Now that WEBP is supported across popular modern browsers—looking at you Safari for being late to the party—I’ve been considering serving images in WEBP format across my icon gallery sites.

Today I’m serving PNGs which I optimize via the ImageOptim API. It does a pretty damn good job of doing lossless minification for the original icon designs.

I’m also using lot of bandwidth. The past few months, according to Netlify, I’ve been burning through 150GB or more of traffic per month for these sites—the majority of that being serving images.

So I’ve been thinking: if I could cut image sizes, say, in half, that would cut my bandwidth usage in half! However, given that the primary focus of these sites is the icons themselves, I need to continue providing high quality icons. People come to these sites to admire the design of the icons and it would be difficult to admire and appreciate the quality of something that’s been altered and degraded from its original form. That is why I serve lossless PNGs today.

But maybe WEBP could meet the same standard of quality I have from today’s PNGs and still save me some bytes? That’s my hope.

Given the above, I devised a few ways to test whether WEBP would be sufficient to my needs. I’m documenting what I find here.

tldr; I picked a random sample of sixty iOS icons and converted them to WEBP to see where the biggest changes (both visually but also in file size) would show up between PNG and WEBP formats. Takeaways:

More Details

I took 260 sample PNG images at their largest size of 1024Ă—1024 pixels. In terms of resolution, these are the largest PNGs used on my sites. Today they are optimized using imageoptim at a lossless compression.

I then ran them through the imagemin tool three different times, each with a different setting, from lossless compression to lossy compressions at a quality of 100 and 80. These were the resulting folder sizes of those 260 images:

I found it interesting that going from lossless PNG files optimized with imageoptim to lossless WEBP files optimized with imagemin resulted in an increase of overall file size. However, once I turned on lossy compression, the file sizes started to drop drastically.

However, file size isn’t the only important consideration. How do WEBP images differ from PNG images in terms of visual fidelity and detail when similar compression is used?

I found that, for “flat” icons, WEBP trumps PNG easily. But when you start to get into icons with lots of visual detail and texture, WEBP struggles to maintain fidelity to the source PNG artwork.

Here’s a sample of what I found in terms of file size:

Icon PNG WEBP lossless WEBP lossy@100 WEBP lossy@80
1Password 353kb 328kb 292kb 48kb
3d scanner 1.1MB 1.9MB 587kb 140kb
Watch 70kb 63kb 68kb 29kb
Hippo 997kb 805kb 253kb 57kb
Alarm 353kb 545kb 171kb 47kb

An Example: 1Password

1Password has a number of icon variations through the years, following the general aesthetic trend in iOS, from skeuomorphic to flat in appearance.

iOS icons for 1Password from 2020, 2018, 2014, and 2012 which show how the icon’s aesthetic has changed over time.

The more recent flat icons compress really well under the WEBP lossy compression, losing hardly any noticeable visual fidelity while shrinking drastically in size.

3 versions of the 1Password icon, each with a PNG and WEBP version, illustrating how well the compression worked for icons design with a “flat” aesthetic.

Here’s how the 1Password icons changed in file size:

App PNG WEBP@80
1Password (2020) 138kb 23kb
1Password (2018) 64kb 25kb
1Password (2014) 68kb 31kb
1Password (2012) 353kb 48kb

However, the older skeuomorphic icon was different.

The 1Password iOS icon from 2012.

While its size changed drastically, it wasn’t without a noticeable loss in visual fidelity. This illustrates the broader trend I saw across many app icons: anything skeuomorphic in nature or containing a lot of visual texture lost detail.

It’s worth noting that when it went from the original PNG to WEBP with lossy compression at a quality of 100, there was little to no quality lost in visual fidelity (yet there remained a file size savings).

App PNG WEBP@100 WEBP@80
1Password (2012) 353kb 292kb 48kb

But going down to a lossy quality of 80, you can see the differences between PNG and WEBP. Here’s a screenshot of the texture of the original PNG.

Close up on a cross section of the 1Password icon as a PNG showing the background texture in the image.

And now the WEBP version (compressed at a quality of 80).

Close up on a cross section of the 1Password icon as a lossy WEBP showing the loss of background texture in the image.

Note how a lot of that minuscule texturing gets lost. The effect looks similar to that JPEG block effect you see as a compression artifact resulting from a lossy conversion.

Other Examples

These are a few examples going from lossless PNG to lossy WEBP at a quality of 80 (going to 100 didn't make much of a difference and going lossless made the WEBP icon sizes bigger).

The 3d Scanner app, which has much more photo-realistic design with lots of textures, is exactly the kind of image where I see WEBP conversion struggle the most. Here’s a close up on the texturing in the original lossless PNG:

Screenshot of the Activity app icon with lossless PNG compression.

And here it is after lossy conversion to WEBP:

Screenshot of the Activity app icon with lossy WEBP compression.

In Apple’s Activity app icon, you can see banding in the original PNG.

Screenshot of the Activity app icon with lossless PNG compression.

And that gets lost during the conversion to WEBP (almost more of a JPEG compression effect).

Screenshot of the Activity app icon with lossy WEBP compression.

The Air Hippo app icon

Screenshot of the Air Hippo app icon with lossless PNG compression.

Note the detail being lost

Screenshot of the Activity app icon with lossy WEBP compression.

And then the Alarm Clock app icon

Screenshot of the Alarm Clock app icon with lossless PNG compression.

Note the detail lost here, things becoming just a bit more blurry, especially the squares in the background.

Screenshot of the Activity app icon with lossy WEBP compression.

Conclusion

It looks as though, to get really impressive file size savings, I’ll have to go to lossy WEBP compression. This means some icons in my galleries will suffer a loss of visual fidelity.

I might be ok with that, but I’m not sure. These galleries are all about admiring the original icon designs, so I’d like to be as faithful as possible to the source artwork. That might mean more bandwidth is required.

Given how I’m currently storing and serving my icons, switching to WEBP wouldn’t be a light lift. If I could get Netlify’s imagine transformation service to support the delivery of WEBP as a format, I’d definitely give this a shot. That would be an easy way to get my feet wet and try it out without too much upfront cost.

As it stands, I’m leaning towards leaving things as they are today. Long live the PNG.