Is there any benefit to using WebP images on my website?

WebP is an emerging image format put out by Google. It’s designed to use a more aggressive and better optimized compression algorithm than JPG and PNG with the objective of reducing file sizes with minimal quality loss. And that means faster websites consuming less bandwidth. That makes your site’s visitors happy, and it also makes Google happy–they now explicitly favor fast websites over slow ones in their search rankings.

But photographers also care a lot that their images look their best. Heavy compression can look very ugly. So it’s always a trade-off between file size and image quality. And it’s precisely at the intersection of those two things that the WebP format is targeted.

Google didn’t set out to reinvent the JPG. They acquired a video encoding company and then found that part of the technology happened to work really well on still images. They’ve since open-sourced the codecs.

There are two main attractions of the WebP. One is reduced file size without perceptible drop in quality. How much smaller WebP files are than their JPG equivalents varies by a number of factors, but Google touts the figures of between 25 and 35 percent smaller. Google claims that when they switched Youtube thumbnails to WebP it resulted in a 10% increase in page speed.

The other main attraction is that the format combines features that haven’t been combined in a single format before: combining together the distinctive benefits of JPG, PNG, and GIF formats.

Chances are that you’ve seen WebP images without realizing it. Facebook has been using it on its Android apps for a while. Youtube thumbnails are available in WebP if you view them in Chrome, Opera, or on an Android device. And while there’s only a relatively small percentage of websites using it at the moment, they are nevertheless out there.

Reading the numbers is all well and good, but I was curious to see whether these claims were real and, more importantly, whether it was worth converting my images to WebP and making them available on my website. Could I really get a 10% reduction in the size of my images while preserving image quality? The results surprised me.

Compatibility

But before we get started, WebP comes with a big asterisk. And that is that despite being announced in 2010, it’s still very much an emerging format. That means that that it is not universally compatible. Crucially, not all browsers support it. At the moment, it’s only Chrome and Opera. After initial opposition, the Firefox developers are rumored to have had a change of heart and are expected to incorporate it into a future version. Internet Explorer and Safari do not support WebP.

The upshot is that even in a best-case scenario, only some of the visitors to your website will get the WebP versions (the others will get the regular JPG versions). On my site, about 51% of the visitors use Chrome or Opera, so only half of my site’s visitors are using a WebP-compatible browser.

There are apps to create and convert to WebP format, several of which are free. Here’s a partial list. And if command line scripts are more your thing, you’re in luck.

Photoshop doesn’t natively support WebP, but you can add a plugin to add WebP support. Lightroom doesn’t support it. It’s not supported by native operating systems, but there’s a codec you can add for Windows.

Real-World Tests

To test out the effectiveness of WebP, I ran some tests to convert some typical web images I’d use on my site.

There are some things to note about these tests.

Firstly, I’m focused more on practical, real-world results rather than pushing theoretical envelopes. The mathematics that goes into the compression algorithms is way over my head, but I want to see what the practical results are for me as someone who publishes photos on the web and who is fussy about image quality.

Secondly, WebP is designed to sped up the display of web pages, not as an archival format. So I’m focusing here on the kinds of sizes that are typical on websites. One batch of images that I used in my tests is 800px along the long edge, which is a size that might typically be used in a blog post. For a second batch, I also tried higher-resolution photos at 2048px along the long edge. For all of them, I’ve started with JPGs encoded at pretty high quality settings, as photographers often do. I’m also in the habit of using high quality settings because when you add images to Wordpress it automatically generates derivative lossy versions at different sizes that are then used on the site. So by the time you get to seeing it on the page you’re looking at a second- or even third-generation version of the image.

Thirdly, to eliminate the standard optimization techniques that can distort the results, I ran the original JPGs through optimization before converting them. I used ImageOptim, which uses many of the same underlying tools as server-side optimization tools like EWWW Image Optimizer and Optimus. That meant I wasn’t getting distorted results from comparing an unoptimized JPG with an optimized WebP.

Fourthly, like most image compression algorithms, the effectiveness of WebP compression varies according to the detail and tones in each photo. It also varies according to what the quality setting at which the original image was encoded at. So every photo is going to get different results. I’ve included a mix of different kinds of photos with different amounts of detail and tones. Here are the ones I used at 800px:

And here are the ones I used at 2048px:

Fifthly, I’m starting with JPG images as the masters. So I’m going from a lossy format to another lossy format. In normal circumstances, that’s precisely the wrong way to do it–you should start with a master and then convert to lossy formats in parallel, not in sequence. And it also means that my results here are not true side-by-side comparisons of the efficiency of the JPG algorithm and the efficiency of the WebP algorithm.

But I’m doing it this way very deliberately, because this is likely what’s going to happen real-world uses if you decide to convert your images to WebP and implement it on your website. When you upload to Facebook, it takes your JPG and converts it to WebP. If you run the conversion on your Wordpress site to convert all your existing photos, you’ll be taking the JPGs you’ve uploaded and converting them. And, after all, you can’t export to WebP from a RAW file in something like Lightroom or Photoshop even if you wanted to. So I’m getting a double-whammy of lossy compression, but that’s an unfortunate aspect of what’s going to happen in real-world use.

And finally, the app I’m using to convert is XNConvert. It’s a reliable and flexible image conversion app that works on Windows, Mac, and Linux platforms. It’s also free. There are other apps that convert to WebP. I can’t guarantee that you won’t get different results in different apps, but they should all be using the same underlying WebP codec.

JPG to WEBP Quality Setting 100

The program I was using, XNConvert, allows for various quality settings for the compression of WebP images, just like we’re used to for JPG. Not every conversion app allows that. EWWW Image Optimizer and Optimus, for instance, have settings to enable the creation of WebP files automatically, but you don’t have any control over the quality settings.

With XNConvert, there’s a slider just like the one you have with JPGs, from 0 to 100. Even at the maximum quality setting of 100 (compression method 6, filter strength 60)–and therefore lowest compression–there were small but still useful file size reductions averaging just under 5%. With one of the large images, the size actually went up, and on a couple it didn’t change at all.

Putting the results side-by-side, I really wasn’t able to tell any difference visually. But at this setting the file size savings aren’t really enough to justify the effort. The takeaway is that the 100 quality setting isn’t useful for JPG photographs.

JPG to WEBP Quality Setting 80

Next I tried the quality setting at 80 (compression method 6, filter strength 60). This resulted in dramatic savings in file sizes. It was a rather incredible average of 78%. The highest was 86%, with the lowest at 63%. That’s a pretty extraordinary saving, meaning that the WebP will load in about a quarter of the time of the original JPGs.

Looking at the images in isolation, I really couldn’t notice any difference. When I flicked them side by side there was a very slight but nevertheless perceptible softening in the detail with the WebP version. It was mostly clearly visible in areas where there was a combination of gradual tones and some detail. There’s also some artefacting in smooth tonal graduations such as in the blue skies. In images with much busier and sharper detail any differences were much less noticeable, although the WebP versions did introduce some Moire issues in very isolated places. There was ever-so-slightly more saturation in some areas of some of WebP versions–generally in the reds, oranges, and pinks, that is likely a symptom of a reduced color palette. But it’s also worth emphasizing that any differences here might have less to do with the compression algorithm than what, under normal circumstances, is a faulty workflow of taking one lossy image and applying further lossy compression.

And to make sure that the results were the result of the format and not solely from applying a second round of compression, I ran the same original images through a conversion to another JPG (setting 80). The resulting filesizes were a tad larger than the WebP versions but still dramatically smaller than the original JPGs. But comparing the second-generation JPGs visually with the WebP versions, the WebP versions were significantly better and had much less artefacting than the second-generation JPGs.

So for most uses, the WebP images compressed at a setting of 80 were very acceptable. It would only be if you were very particular about your images–as photographers tend to be, of course–that you might object to it.

JPG to WebP Quality Setting 90

Being pretty fussy about image quality, I next tried finding the happy medium between file size savings and negligible or even imperceptible image quality loss. So I tried a setting of 90 (compression method 6, filter strength 60).

The file size savings are still dramatic–averaging about 63%.

Putting the images side-by-side, if you’re being picky about it and are used to looking for such things, you can see differences. There is a very slight softening in some areas of detail, particularly in smoother tonal areas, and in very smooth tonal gradations there is some very slight artefacting. But in practical terms for everyday web use, the images are basically indistinguishable.

Giving you visual examples is a bit tricky, because if I post them inline here they’ll go through another round of conversion on my web server. So here are direct links to the images that you can open or download directly to compare.

800px
Photo 1: original jpg | converted to webp
Photo 2: original jpg | converted to webp
Photo 3: original jpg | converted to webp
Photo 4: original jpg | converted to webp
Photo 5: original jpg | converted to webp
Photo 6: original jpg | converted to webp
Photo 7: original jpg | converted to webp

2048px
Photo 1: original jpg | converted to webp
Photo 2: original jpg | converted to webp
Photo 3: original jpg | converted to webp
Photo 4: original jpg | converted to webp

In Optimus Image Optimizer and EWWW Image Optimizer Cloud you have the ability to create WebP versions, but you don’t have any control over the level of compression being applied. Based on some file size tests I did to compare the results from XNConvert and Optimus, Optimus appears to use a quality setting equivalent to about 90.

So a setting of 90 seems to be about the sweet spot for me. The very slight differences are worth the file size savings north of 60%.

Here’s the full set of results:

JPG to Lossless WebP

It’s technically possible, but I don’t recommend it. In all my tests the files ended up substantially larger, and you’re not getting any improvement in quality because you’re limited by what you start with.

The lossless setting in WebP is designed for images that would otherwise be PNG-24 (usually graphics), so by all means use it in those cases. But just don’t use it with JPGs.

PNG to Lossless WebP

And while we’re on the topic, I’ve been focusing on JPG so far because most of my site’s images are photos and are therefore in JPG format, but I did run tests on PNG files.

The WebP lossless setting is specifically designed as a replacement for PNG files, but in my tests in taking existing optimized PNGs and converting them to lossless WebP I ended up with files that were significantly larger than the originals. I suspect the issue is one of second-generation compression again and I’d get better results with first-generation WebP. But based on the results of those tests I’ve decided not to convert my existing PNGs to WebP and focus only on the JPGs. But PNGs make up only a relatively small percentage of the images on my sites.

Implementing WebP Support on Your Website

Creating WebP versions of your images is pretty straightforward. Implementing WebP on your website can be quite a bit more complicated.

There’s more than one way to skin this cat, although not all of them are going to work on every site and server setup. The underlying principle of all of them is that if the user’s browser supports WebP they’ll get that. If the browser doesn’t support WebP it’ll fall back seamlessly to the JPG version.

The simplest method, but also the most tedious, is that you can manually encode the HTML of each image. If you want to do it that way, here’s a template for the code. It’s not especially practical for large or existing sites.

A much more convenient way to do it is to automate it. These options fall into two main categories: setting rules on your server or running javascript on the page.

Apache / .htaccess. If you’re using an Apache server, you can add some code to the .htaccess file to enable the WebP functionality. You can find generalized code snippets here and here.

NGINX / ngix.conf. If your server is running NGINX, there’s an equivalent here or here.

Javascript. The .htaccess version doesn’t work on all server setups. In that case, another option is to use javascript which runs as the page loads. There are several of options for how to do that, from rolling your own to using a plugin like this one for Wordpress.

Another option is that EWWW Image Optimizer has its own customized solution baked into the plugin that is designed to work well with CDNs.

To test whether it’s working, load the page in a WebP-compatible browser like Chrome or Opera and then look at the page’s source code in the developer tools. If you’re being given the WebP versions you should see that in the img src tags. If you’re only getting JPG, it’s probably not working properly (assuming you’ve generated the WebP versions to start with, of course). If you want to be more precisely about it, check the MIME types that are being served.

WebP’s Security Through Obscurity

There aren’t any built-in encryption or security measures with WebP–it’s specifically designed for sharing images, after all, not restricting access–but there’s an odd side-effect of the current limited compatibility.

And that is that if users download a WebP image from your website, many of them are going to be stumped in reusing it. They can’t open it Photoshop (at least, not without installing a plugin), and they can’t view it or edit it without using software that is specifically compatible with WebP. And they’ll run into trouble if they try to share it again by email or social media. If they email it someone else, the receiver probably isn’t going to be open it and will just see a suspicious attachment they’re not familiar with. If you upload a WebP file to Facebook you’ll get an error message. Uploading a WebP image to Wordpress also fails with a security warning. So if users download WebP images from your website, even with the best of intentions, they’ll have a hard time doing anything with it. Facebook got a lot of complaints precisely for this reason when they rolled out WebP.

That, of course, is not a true security strategy and will change as more and more browsers and apps start supporting WebP. It also only applies if your users downloaded the image from a WebP-compatible browser like Opera or Chrome. So it’s only going to apply to a subset of your site’s visitors. But it is nevertheless an interesting side-effect.

What I don’t know yet but am interested to investigate more is how Google’s search bots treat WebP versions. Are they indexed as images? Are they treated as duplicates of the JPGs? If I get any answers I’ll update here.

Wrap Up

WebP offers some pretty dramatic savings in file size with relatively little reduction in image quality. Color me impressed.

But I’ll emphasize again that the dramatic file size reductions I’ve laid out above aren’t true side-by-side JPG-to-WebP comparisons because the WebP versions are second-generation lossy versions–I’ve taken a JPG, compressed it again as part of converting to WebP, and then compared the resulting WebP to the original JPG. But my objective has been to see whether implementing WebP on my site is worth the trouble, not to pit one algorithm against another. And the reality is that implementing WebP on a website is going to involve a lot of second-generation, or even third-generation, conversions from JPG to WebP.

You can get similar small file sizes other ways by doing a second round of compression to JPG or applying much heavier compression in the first place. The attraction of WebP is not that it’s the only way to get very small file sizes but that, byte-for-byte, the resulting image quality of the small WebP files is better than similarly-sized JPG files (and, in most circumstances, PNG files).

Overall, WebP is still a bit of a mixed bag, and the negatives are significant. It still hasn’t gained full traction and it isn’t supported by all or even a solid majority of imaging and web apps. In the best case, only half of my visitors will be sent the WebP versions because only half my visitors use browsers that support WebP. I’ve read reports of color shifts when converting to WebP, although I haven’t run into that in any significant way in my own tests, possibly because I’m using newer versions of the underlying codec. And while creating WebP files is pretty easy, serving them properly on your website is much harder than it should be (and this is an area I’ve had a lot of difficulty because the usual solutions don’t work with the way site is configured). Less important, but nonetheless factors, are that the encoding algorithms can strain servers, and all those extra .webp versions of every image take up server space.

Most importantly for photographers and other visual creatives, WebP is still a lossy compression format. That means that information is being discarded and there is in fact a reduction in image quality. The trick is in making sure that the difference isn’t perceptible visually. So the decision is one of trading off perceived image quality loss and the gains resulting from reduced file sizes. It comes down to a cost-benefit analysis, and everyone’s going to come to a different answer for their own preferences, needs, and circumstances.

Your mileage is certain to vary, but in my case, I’ve decided to adopt WebP cautiously by implementing it on parts of this site where image quality isn’t mission critical. Because of the way my site is configured, it doesn’t affect my main photo galleries of large images, which are the ones where I care most about image quality. But it does apply to the thousands of other images, thumbnails, product shots for reviews, screenshots for how-tos, and thumbnails used throughout high-traffic areas of the site. And the file size savings are dramatic, which in turn offers the potential of a faster website and fewer bandwidth issues. It’s also entirely reversible. The JPGs remain in place, and if I decide later to disable WebP it’s simply a configuration setting. Implementing WebP by itself isn’t going to perform magic, and it’s just one of many techniques I use as I continue to tweak the site’s speed, including optimizing all images, using a CDN, having layers of caching, and having the site with a top notch web host.

Alternatives to WebP

While I’ve found distinct benefits to rolling out WebP on my site, it’s not necessarily the first thing I’d recommend if you’re looking to speed up your site. There are other options for slimming down your images.

Image optimization is an obvious first step, and if you haven’t done that already I recommend starting with that. The general principle is that it takes out all of the unnecessary information that’s included in image files. Here are some good places to start.

Lazy loading images can also increase the perceived speed at which the page loads, and you can also use fewer images as well as using the correct image size for the display can also reduce the amount of data that that the user has to download to see the page.

Going further, there are some excellent lossy compression tools that can perform similar things to converting to WebP. JPEGMini, a commercial service, is one of the better known and one I’ve used before. It uses their proprietary algorithms to add another round of lossy compression that is hardly noticeable visually, if at all, but can result in much smaller files. TinyJPG is another commercial offering, and the same folks also have a version for PNG files. The advantages of these systems is that they spit out standard JPG and PNG files, so there’s no need to change your site’s configuration to display them.