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

WebP is an emerging image format that is designed to create images that are visually indistinguishable from JPGs (or PNGs) but with much smaller file sizes. That in turn makes for a faster website.

Webp Photoshop Plugin
Webp Photoshop Plugin
Last Updated:

This post may include affiliate links. Read more.

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.

 JPG Original@ WebP 100 Quality% Reduction
800px384.4 KB344.9 KB10.28%
151.6 KB149.7 KB1.25%
360.5 KB342.8 KB4.91%
132 KB114.2 KB13.48%
162 KB154.5 KB4.63%
81 KB69.2 KB14.57%
131.6 KB116.2 KB11.70%
2048px1200 KB1300 KB-8.33%
1900 KB1900 KB0.00%
701.7 KB699 KB0.38%
1200 KB1200 KB0.00%

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.

 JPG Original@ WebP 80 Quality% Reduction
800px384.4 KB123.2 KB67.95%
151.6 KB21.2 KB86.02%
360.5 KB132.5 KB63.25%
132 KB19 KB85.61%
162 KB36.4 KB77.53%
81 KB10.8 KB86.67%
131.6 KB19.7 KB85.03%
2048px1200 KB308 KB74.33%
1900 KB599 KB68.47%
701.7 KB130 KB81.47%
1200 KB242 KB79.83%

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

 JPG Original@ WebP 90 Quality% Reduction
800px384.4 KB185.8 KB51.66%
151.6 KB39.9 KB73.68%
360.5 KB198.4 KB44.97%
132 KB32.9 KB75.08%
162 KB63.1 KB61.05%
81 KB18.7 KB76.91%
131.6 KB37.4 KB71.58%
2048px1200 KB532.6 KB55.62%
1900 KB932.4 KB50.93%
701.7 KB213.9 KB69.52%
1200 KB430.4 KB64.13%

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 Original@ WebP 100 Quality% Reduction@ WebP 90 Quality% Reduction@ WebP 80 Quality% Reduction
800px384.4 KB344.9 KB10.28%185.8 KB51.66%123.2 KB67.95%
151.6 KB149.7 KB1.25%39.9 KB73.68%21.2 KB86.02%
360.5 KB342.8 KB4.91%198.4 KB44.97%132.5 KB63.25%
132 KB114.2 KB13.48%32.9 KB75.08%19 KB85.61%
162 KB154.5 KB4.63%63.1 KB61.05%36.4 KB77.53%
81 KB69.2 KB14.57%18.7 KB76.91%10.8 KB86.67%
131.6 KB116.2 KB11.70%37.4 KB71.58%19.7 KB85.03%
2048px1200 KB1300 KB-8.33%532.6 KB55.62%308 KB74.33%
1900 KB1900 KB0.00%932.4 KB50.93%599 KB68.47%
701.7 KB699 KB0.38%213.9 KB69.52%130 KB81.47%
1200 KB1200 KB0.00%430.4 KB64.13%242 KB79.83%

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.

The Wordpress Cache Enabler plugin now supports serving Webp images. You can find more about it here.

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.

23 thoughts on “Is there any benefit to using WebP images on my website?”

  1. I was a bit confused by Safari not having support. In theory, all mainstream servers support WebP and, with IE support being dropped, IE and other niche browsers shouldn’t be much of a consideration; big picture. https://caniuse.com/webp

    Reply
  2. Thanks for your most useful article. I think your comparison is unfair to JPG, because you seem to be comparing a 90% WEBP to a 90% “original” JPG and not to a JPG reduced to a sensible size for web use. (Indeed, this is the actual problem with large pictures on the web: many webmasters use 90% JPGs on their websites and not much smaller ones at 25-50%, which is enough depending on the type of photo and use.) I used your 800px-01.jpg (151kiB), which reduces to 67 kiB in JPG with 36% and still looks OK, or 62 kiB in WEBP with 36%, not strictly the same, of course. The WEBP is smaller, but the main reduction from the original comes from the chosen quality factor, and not the format.
    I used GIMP for these. An advantage of sticking to JPG here: GIMP has a lossy-JPG-preview which shows visually what you get when using the compression slider. I usually reduce quality until severe artifacts appear, then increase while jiggling back and forth until none are discernible at screen resolution, usually somewhere between 25 and 50%. The WEBP export in GIMP lacks this preview feature, so you have to guess and compare afterwards.

    Reply
    • Thanks for your thoughtful response. A couple of thoughts. The post isn’t really about comparing how the JPG format compares to WebP as an apples-to-apples comparison. It’s about whether to enable the WebP overlay option on an existing website–the kind of overlay or intermediate service that Cloudflare or CDNs or optimization services offer. Those services rarely give much control to finetune levels of WebP compression. And for a photographer, as I am, image quality at 25-50% is a non-starter, especially for the largest and heaviest images (i.e., precisely the ones I want to look their best). This is something I’ve spent a lot of time testing, and while not every image needs a quality setting in the 80-90% range, some look horrible at lower, and I’d rather avoid horrible-looking images due to compression (The photos I take might not always be up to snuff artistically, but that’s a separate issue.) But as I say in the very title of the post, it’s about implementing on my website, and there are going to be different answers with different setups, workflows, and preferences. And this article was also written when WebP was first being rolled out, when options were even more limited.

      Reply
  3. My developer just added automatic WebP conversion to my website, but I’m having trouble finding recommended export settings for Lightroom CC. I’m assuming PNG would be best, but I’m not sure If there are additional file settings or resolution settings that are ideal. Thanks for any suggestions!

    Reply
    • In general, it’s probably better to continue doing as you’re doing. PNGs are great for graphics but not for photos. It doesn’t make sense to use PNGs for photos just to work with WebP, for example. But things like logos, etc, are good as PNGs. For exporting photos from Lightroom, I’d continue with a moderate amount of compression, as you normally would for web images. Somewhere around 65-75% is a good place to start, but it really depends on the images themselves and your own preferences with how much the compression is affecting the image quality. It’s true that creating the 2nd-generation WebP versions is going to add another generation of compression, but in my experience, most implementations don’t degrade the image quality much at all. You also want the JPG versions to look good, because not every user is going to get a WebP version–it’s not yet supported by all browsers, so some users are still going to get the JPG version. So my approach would be to not change your workflow just to accommodate WebP and to aim for a site that looks great with its JPEG versions.

      Reply
  4. I’ve been working with the web from the beginning. Google introduces a new image standard that makes pages open faster. Okay, that’s great for users.

    Google as the gorilla expects others, incl. all websites (they will lower the search ranking for sites if the site is slow, incl. due to large images.), social media, news, etc. to switch to webp. This also includes all image tools, incl. Photoshop, Paintshop, etc. All image workers, incl. photographers, graphics people, etc. Everyone switches…

    Until Google drops the idea. And this has happened many times. Corps get big, decide their standard is The Standard, push it through… and then abandon it.

    Reply
    • Even worse, Google decides to charge licensing for WebP once it’s widespread, kind of like what happened with GIF.

      Stay away from this false “standard”.

      Reply
  5. Do not use it. Webp is impossible for an average user to convert back from, if you have a webp animated you are done and most likely will never recover the data.
    Do not use this shoddy scammy format guys, keep the web clean from it.

    Reply
    • Most implementations I’ve seen so far–and the one I use–have them side by side, not replacing the original. It creates duplicates, which clutters up the web server space so it’s not ideal, but there’s never ever need to convert back because the originals are still there.

      Reply
  6. It would be interesting to perform the same test starting from a set of PNG images and then compare both JPGs and WEBPs derived from them.
    Comparing a WEBPp generated from an already lossy format makes little sense.

    Reply
    • Thanks for the suggestion. I agree that it would be a more logical way to do it for a normal image format, but the way that WebP is often used (not always, of course) is as a second-wave conversion of master JPGs. It’s how services like Cloudflare, CDNs, and server-side converters work when you enable their WebP support, for example. But I wrote this article originally a few years ago, and I plan on revisiting and updating it soon. Will look to do more comprehensive comparisons then from different master files (and different same-generation formats).

      Reply
  7. I really liked this article, very interesting reading, as it’s coming from someone that appreciates image quality.
    But it’s well worth updating as all the main browsers now support WebP and there is another very compelling reason to move to webp in that speed of loads is part of the Google algorithm, you ignore this at your peril. And if you are selling a product or make money from your website, you are quite literally limiting the number of people that come to your website through organic searches. So in effect you are costing yourself money.

    There is a WordPress Plugin called short pixel that will convert to webp and if you are a low volume site you could get it for free but at $4.99 for 5,000 images you would be crazy not to take that offer up.

    Reply
  8. You can automatically serve WebP images to browsers which support WebP if you use Sirv https://sirv.com/. Any website can use Sirv but its particularly straightforward for WordPress sites. The WordPress plugin for Sirv https://wordpress.org/plugins/sirv/ automatically synchronizes your WordPress media library, so you don’t need to upload images or change any code. It’s free for small sites, with paid options for high traffic sites. I’m one of the developers behind the Sirv plugin and we’d be very happy to receive your feedback and suggestions. Thanks!

    Reply
    • It can be, but it depends on the amount of compression. And only some browsers support it, so you’ll need JPEG as well as a fallback.

      Reply
  9. Hi,
    Thanks for your helpful article.
    Are you aware if when using EWWW’s WebP, the images will automatically be served, either Jpeg or WebP based on browser type? Or is a thing that has to be done manually?

    Thank you.

    Reply
    • It’s not automatic. The WebP versions generated by EWWW are standard, so you can serve them with the usual Apache rewrite rules or something like the Cache Enabler plugin. But it also offers its own “Alternative WebP Rewriting” as an option, which draws on PHP functions.

      Reply
  10. Do you know if it is possible to use EWWW Image optimizer to generate the webp images and use Cache Enabler to serve them up? Or do you need to use Optimus with Cache Enabler to serve up the webp images?

    Reply
    • Actually, I was experimenting with that very thing myself just recently. Yes, it’s absolutely possible. They all create standard WebP images, and once they’re there they’re there–it makes no difference how they were created (you could create them offline and upload them, too). But it’s worth being aware that the way EWWW serves WebP is quite different to how Cache Enabler does. EWWW does the serving on an image basis and doesn’t touch the rest of the page. Cache Enabler caches the entire page as static HTML, including a version with regular formats and a version with WebP images. If your browser is compatible with WebP you should get the version of the cached page with WebP. If not, you’ll get the version of the page with the regular formats. And one other thing I learned along the way in testing whether Cache Enabler was indeed working… your server will have to have the WebP MIME type enabled. It’s simple for a server admin to do, but not all servers have it enabled by default.

      Reply

Leave a Comment