EWWW IO and WebP Images

Unlike the other conversion options in the EWWW IO plugin for WordPress, WebP conversion is possible for every PNG or JPG image on your entire WordPress site. It is not limited to the Media Library. So theoretically, you could put the root path to your WordPress site in folders to optimize, run a Bulk Optimize, and EWWW would create WebP copies of all images where WebP is the smaller of the two formats.


Converting JPGs to WebP involves a slight quality loss because we use the lossy WebP encoding for JPG images. On the other hand, converting a PNG to WebP is completely lossless, so you don’t have to worry about losing quality there. The WebP conversion does NOT replace your images, it only makes a copy of the original with the exact same name, but in the WebP format and with a webp extension added onto the end.

It is important to note that only the Chrome and Opera browsers, and Adroid devices currently support WebP. so determining how to serve those images is somewhat up to you, but there are a couple options available in the plugin. Also, by default, the plugin will only create the WebP images if they are smaller than the original format (JPG or PNG), so any rewriting solution has to check to see if a webp image exists, and that just isn't possible if the only copy of an image is on a remote server. 

Rewriting with Apache & Litespeed

The first solution is for folks using Apache (or Litespeed) with mod_headers and mod_rewrite. The EWWW IO plugin can attempt to modify the rewrite rules in your .htaccess file to send WebP images to supported browsers (if such a file exists). When you enable WebP conversion, you’ll see a new section at the bottom of the settings page. It includes the rewrite rules for Apache, a button to insert those rules for you, and a red PNG image showing you that either the server is not sending WebP images, or your browser does not support them. When you insert the rules, you will get a success message if it worked, and it will attempt to reload the test image as well. It may sometimes be necessary to reload the page to get the right test image to load. When you're using a native Apache or Nginx rewrite solution like this, you won't see the image urls in your page change. The rewriting happens when the visitor's browser actually requests the image.

This video demonstrates the two methods of serving WebP images, and how to verify that they are working: 

If you're running a multisite WordPress install, you may have to put the rewrite rules above your Wordpress rules for them to take effect. And if the rewrite rules aren't working, you can try the Alternative WebP Rewriting instead. 

Rewriting (via map) with Nginx

EWWW IO can't directly modify your Nginx configuration, so the solution is a bit different for Nginx. You need to potentially modify three different files here:

First, we need to add a map directive to your global config, usually /etc/nginx/nginx.conf:

map $http_accept $webp_suffix {
 default ""; "~*webp" ".webp"; }

That tells Nginx to set $webp_suffix to ".webp" if the browser's Accept header contains "webp". The second change is to be sure that Nginx knows what a .webp file is. While newer versions of Nginx should already recognize the WebP format, we need to modify the mime.types file (also in /etc/nginx/) to tell Nginx about this new file type. Look for this line, and add it if you can't find it:

image/webp	webp;

The last change is to setup a location block within your server block to handle PNG and JPG images that might have WebP versions. If you only have one server block, it is usually located in /etc/nginx/sites-enabled/default. Add this within the server {} section:

location ~* ^.+\.(png|jpe?g)$ {
  add_header Vary Accept;
  try_files $uri$webp_suffix $uri =404;

This tells Nginx to apply the enclosed rules to any files that end with png, jpg, or jpeg. If you have .jpe files, add a second question mark after the g, so it looks like "jpe?g?". The first rule adds the "Vary Accept" header to the return response, which is what allows supported CDNs to cache different files for the same url. The second rule tells Nginx to look for a file that matches the original url/uri with our $webp_suffix appended (.webp), and if that fails, to just serve the original uri or fallback to a 404 if the file doesn't exist at all.

Alternative WebP Rewriting

If you serve your images through a CDN or content distribution network, you may not be able to use the rewrite rules. First, you need to check if your CDN supports the storing two images at the same url based on the Accept header. A simple test for this is to load the test.png file using your CDN url in Chrome and Firefox (or Internet Explorer). If you get the correct images, then your CDN should work fine.

If your CDN does not honor the Accept header, you should use the alternative webp rewriting. The same applies if you have any sort of proxy/caching server that is in front of your actual web server. The alternative method is a javascript solution that will attempt to parse your page looking for images that have WebP alternatives. There is also a WebP option in the Cache Enabler plugin from KeyCDN that works nicely with page caching and proxy servers, but it still requires local copies of the images. Which leads us to the other two options...

Force WebP & WebP URLs

So, what are these other two options for? Normally, none of the solutions we’ve talked about will work if you do not have local copies of your images. To get around that requirement, you first need to use the Force WebP option to make EWWW IO create WebP versions of every image you optimize. Then, you need to create a whitelist of domains or urls that EWWW is allowed to rewrite, and enter these URLs in the WebP URLs box. They can be partial urls, but should contain at least the domain name where the images are being served from.

Once those two options are setup, you can enable Alt WebP Rewriting, and then the plugin will look for any images that match the url patterns you’ve listed, and it will rewrite those images for WebP. It still provides a fall-back for browsers like Firefox and Internet Explorer, but you need to make sure that every image matching these urls already has a webp version, or you’ll end up with broken images in chrome and opera.

AMP (Accelerated Mobile Pages)

AMP has this fabulous 'fallback' attribute that allows you to wrap one image element inside another. Then if the first image cannot be displayed, the second one loads instead. The AMP Project Docs even show an example of this, but it doesn't really work properly. The problem is that unsupported browsers will still load the webp image, and only then, after you've wasted precious mobile data, does it load the original (fallback) image. I wish it were not so, but until all AMP browsers support WebP, we'll just have to leave them untouched.

Still need help? Contact Us Contact Us