Turns out, one of our favorite plugins for compressing images, EWWW Image Optimizer, has support for generating WebP files and works with WP Offload Media. In this post, I’ll walk you through using EWWW and WP Offload Media together to serve your speedy WebP image files.
WebP is currently developed by Google and purports to be…
a modern image format that provides superior lossless and lossy compression for images on the web
The file size savings are expected to be between 25-34% with lossy compression when compared to JPEGs, and approx 25% with lossless compression when compared to PNGs. So assuming the claims hold up, you could save a good chunk of bandwidth on an image heavy site by serving WebP rather than JPEG or PNG images. Smaller files also means faster delivery to site visitors and that leads to better engagement and search engine rankings.
All the major desktop and mobile browsers, except Safari, now support WebP. Seeing as Safari is still kind of important, you still need to fallback to a PNG or JPEG image if WebP isn’t supported.
Does WordPress Support WebP?
In a word, nope.
WordPress currently has no idea what to do with a file with the
.webp extension and will not allow you upload them to the Media Library.
With any luck WordPress will gain support for the “image/webp” mime type in version 5.3, but at present a third-party plugin is required for handling WebP files.
For WordPress to be able to serve WebP files you currently need to use a third-party plugin that not only creates the WebP files, but also handles adding them to the generated content in place of PNG or JPEG files when the browser supports WebP.
However, in WP Offload Media support we’ve seen a couple of problems with how some image compression plugins create and add support for WebP files.
- The image compression plugin does not let the Media Library know the new alternate WebP file exists, probably because WordPress has no concept of an alternate file for any given registered image size. For this reason the new WebP files don’t get picked up and offloaded by WP Offload Media because WordPress doesn’t know they exist, and therefore WP Offload Media won’t either.
- The WebP files do not get assigned a valid Mime Type as WordPress does not know what they are and for some reason the image compression plugin does not use the “mime_types” filter to add it. This potentially causes issues for WP Offload Media as if (1) is somehow fixed and it tries to offload the new
.webpfile, WordPress will not supply a mime type that can be set on the new object, and Amazon S3 and other services will therefore reject the file.
Let’s see if EWWW Image Optimizer also suffers from these problems.
The Test Site
To test serving WebP files via WP Offload Media I spun up a clean install of WordPress on a DigitalOcean droplet that I use for testing, cleaned out the example posts and pages etc, switched the theme to the stock TwentySixteen theme (I’ve never liked the look of TwentyNineteen), and applied a couple customizations.
I then added 10 relatively lightweight images originally downloaded from Unsplash and created a super simple post with a single image block and a gallery block.
I opened up the devtools console in Firefox and refreshed the site a few times while keeping the “Disable cache” checkbox enabled. This gave me a rough idea of the total bytes transferred and how long the page might take to load for a new visitor to the site.
In the screenshot below you can see that the total bytes transferred on this occasion was “1.2 MB” out of “1.44 MB”, and a load time of 770ms, so that’s our baseline set.
Setting Up EWWW Image Optimizer
I decided to install EWWW Image Optimizer first to ensure that image optimization and WebP file generation was working well before adding offloading to the mix. It was dead easy.
From the usual “Add Plugins” page in the WordPress admin area I searched for “ewww” and simply hit the “Install Now” button for “EWWW Image Optimizer”, then activated it as normal.
I then went to its settings page and clicked on the “WebP” tab.
I checked the “JPG/PNG to WebP” option and hit the “Save Changes” button.
Alas, this resulted in the following warning about needing Apache rewrite rules for WebP to work.
Well, seeing as I was using Nginx that clearly wasn’t going to fly! In the docs there are instructions for setting up Nginx too, but regardless, I knew that wasn’t going to be of much use once I offloaded to S3 and started serving the files via CloudFront.
Turns out, all I needed to do was check the “JS WebP Rewriting” option and save changes to get the all clear for EWWW + WebP + Nginx.
I didn’t change anything else in EWWW Image Optimizer’s settings and headed straight over to the “Media” => “Bulk Optimize” page.
I hit the “Scan for unoptimized images” button and let it do its stuff.
It took just a few seconds to process the 62 image files.
You can see in the next two screenshots of the Media Library that even with these relatively small images (originals are approx 1024×768 pixels) there’s a reasonable saving in file size for the WebP version. For example, the second item shown drops from 139 KB to 55.8 KB, that’s a saving of 60%!
“That’s all very good Ian, but what about the displayed site, is it using WebP files now?” I hear you say … of course it is!
Each image is now using a version that has
.webp appended to its name.
The load time has dropped a little, from the original 770ms to 639ms, but the real saving is in bandwidth used, 580.77 KB compared to the original 1.2 MB (near 50%). Nice!
Setting Up WP Offload Media
Now it was time to install WP Offload Media and offload the media to S3 to help save more resources on the server, and ultimately deliver the files via CloudFront so that site visitors get them as fast as possible.
After installing WP Offload Media I configured it to use my AWS access keys using the recommended “AS3CF_SETTINGS” define in the wp-config.php file, and then created a new bucket via the UI.
And as explained in our Quick Start Guide, I then offloaded the existing Media Library items to the new bucket using all the default settings.
You’ll notice I didn’t set up CloudFront at first, that’s because I like to keep things simple and make sure all is working well with offloading to the bucket using default URLs before configuring a CDN. I like to KISS. 😉
When I checked the front page of the site, images were being served from the bucket just fine, but unfortunately the WebP versions were not.
This means the transferred bytes had now gone back up to approx 1.17 MB, with a load time of 843ms. Using raw S3 URLs for images is never a good idea as S3 is not optimized for speed, but I did want to be using the WebP files here before switching to a CDN.
Fixing Things Up
So the first question I asked myself was, “did the WebP files make it to the bucket?”
They sure did!
That was a relief because as discussed above we’ve seen other plugins that create WebP files cause two issues with offloading.
Turns out EWWW Image Optimizer’s support for WP Offload Media is the real deal, it implements the “as3cf_attachment_file_paths” filter to ensure the WebP files are added to the list of files that should be offloaded, and the “as3cf_object_meta” filter to set a correct “ContentType” so that S3 does not reject them. Thanks Shane, you’re a star!
So, why no WebP files? Simple, because EWWW Image Optimizer doesn’t know that the new URLs for the images have alternate WebP files available, by default it only rewrites URLs for the home domain.
I updated the WebP settings to use the “Force WebP” option and entered the two URL patterns I expect to use.
With the S3 URLs now recognized by EWWW Image Optimizer’s JS WebP Rewriting, we had WebP files served from S3. 🎉
Our transferred bytes was back down to a very nice 582 KB, and load time back down to 713ms, just a fraction less than the baseline.
Time to test out using a CDN, in this case CloudFront.
I created a CloudFront distribution as per our CloudFront Setup for Media Offloaded to Amazon S3 guide, and then enabled a custom domain as shown in our Configure a Custom Domain for CloudFront with HTTPS guide.
So in the WP Offload Media settings I had the “Custom Domain (CNAME)” setting now turned on with “ewww-cdn.breakonexception.com” entered as the domain to use.
A couple of refreshes of the site’s front page, and I started to see a nice improvement in delivery speed.
As expected, the total bytes transferred had remained roughly the same as other times WebP was used at 583 KB, but the load time has dropped considerably to 579ms, 20% faster!
After the above experiment I played around with WP Offload Media’s “Remove Files From Server” option and offloading a variety of larger Media Library items to see if I could break EWWW Image Optimizer, because that’s the kind of person I am! But no dice, EWWW Image Optimizer was able to compress the original files and generate WebP versions without problem!
Because EWWW Image Optimizer is a good egg and integrates well with WP Offload Media, setting up offloading media and serving WebP images is relatively easy.
- Turn on all the options in EWWW Image Optimizer’s WebP tab and enter the base URL for the offloaded media.
- Bulk optimize your media.
- Offload your media with WP Offload Media.
- Job done!
However, the test server and site I used was created before SpinupWP implemented disabling some PHP functions by default. One of those functions is
exec(), which EWWW Image Optimizer relies on. When I upgrade this server to take advantage of the improved security that disabling these functions provides, I’ll probably switch to using the newer EWWW Image Optimizer Cloud plugin that does not rely on
exec() and also has built-in support for WP Offload Media. If your server also disables the
exec() PHP function, you’ll probably want to use EWWW Image Optimizer Cloud too.
EWWW’s combined image optimizing service and CDN, ExactDN, is also something I need to look at in the future. It can automatically create and substitute in WebP files for images it is serving, among many other features.
There seems to be some real gains with using WebP, so it’s probably worth investigating if you have an image heavy site.
Have you tried out using WebP images yet? If so, how did it go? If not, why not? Let us know in the comments below.