Serve autogenerated WebP images instead of jpeg/png to browsers that supports WebP.
The plugin is available on the Wordpress codex (here). But well, it is developed (here on github).
News: I have added the vendor folder to the repo. To install the plugin here from github, you can simply download the zip and unzip it in your plugin folder
More than 9 out of 10 users are using a browser that is able to display webp images. Yet, on most websites, they are served jpeg images, which are typically double the size of webp images for a given quality. What a waste of bandwidth! This plugin was created to help remedy that situation. With little effort, Wordpress admins can have their site serving autogenerated webp images to browsers that supports it, while still serving jpeg and png files to browsers that does not support webp.
The plugin uses the WebP Convert library to convert images to webp. WebP Convert is able to convert images using multiple methods. There are the "local" conversion methods: imagick
, cwebp
, vips
, gd
. If none of these works on your host, there are the cloud alternatives: ewww
(paid) or connecting to a Wordpress site where you got WebP Express installed and you enabled the "web service" functionality.
The plugin supports different ways of delivering webps to browsers that supports it:
The plugin implements the "WebP On Demand" solution described here and builds on a bunch of open source libraries (all maintained by me):
/wp-content/plugins/webp-express
directory, or install the plugin through the WordPress plugins screen directly.You configure the plugin in Settings > WebP Express.
As sort of a main switch, you can choose between the following modes of operation:
Varied image responses: WebP Express creates redirection rules for images, such that a request for a jpeg will result in a webp – but only if the request comes from a webp-enabled browser. If a webp already exists, it is served immediately. Otherwise it is converted and then served. Note that not all CDN's handles varied responses well.
CDN friendly: In "CDN friendly" mode, a jpeg is always served as a jpeg. Instead of varying the image response, WebP Express alters the HTML for webp usage.
Just redirect: In "just redirect" mode, WebP Express is used just for redirecting jpeg and pngs to existing webp images in the same folder. So in this mode, WebP express will not do any converting. It may be that you use another plugin for that, or that you converted the images off-line and uploaded them manually.
Tweaked: Here you have all options available.
WebP Express has a bunch of methods available for converting images: Executing cwebp binary, Gd extension, Imagick extension, Vips extension, ewww cloud converter and remote WebP express etc. Each requires something. In many cases, one of the conversion methods will be available. You can quickly identify which converters are working - there is a green icon next to them. Hovering conversion methods that are not working will show you what is wrong.
In case no conversion methods are working out of the box, you have several options:
If your server has Imagick extension or is able to execute imagemagick binary, the plugin will be able to detect the quality of a jpeg, and use that quality for the converted webp. You can tell if the quality detection is available by hovering the help icon in Conversion > Jpeg options > Quality for lossy. The last line in that help text tells you.
This auto quality has benefits over fixed quality as it ensures that each conversion are converted with an appropriate quality. Encoding low quality jpegs to high quality webps does not magically increase the visual quality so that your webp looks better than the original. But it does result in a much larger filesize than if the jpeg where converting to a webp with the same quality setting as the original.
If you do not have quality detection working, you can try one of the following:
The live tests are quite thorough and I recommend them over a manual test. However, it doesn't hurt to do a manual inspection too.
Doing a manual inspection
Note that when WebP Express is serving varied image responses, the image URLs still points to the jpg/png. If the URL is visited using a browser that supports webp, however, the response will be a webp image. So there is a mismatch between the file extension (the filename ends with "jpg" or "png") and the file type. But luckily, the browser does not rely on the extension to determine the file type, it only looks at the Content-Type response header.
To verify that the plugin is working (without clicking the test button), do the following:
You can also look at the headers. When WebP Express has redirected to an existing webp, there will be a "X-WebP-Express" header with the following value: "Redirected directly to existing webp". If there isn't (and you have checked "Enable redirection to converter"), you should see a "WebP-Convert-Log" header (WebP-Express uses the WebP Convert for conversions).
Note: The redirect rules created in .htaccess are pointing to a PHP script. If you happen to change the url path of your plugins, the rules will have to be updated. The .htaccess also passes the path to wp-content (relative to document root) to the script, so the script knows where to find its configuration and where to store converted images. So again, if you move the wp-content folder, or perhaps moves Wordpress to a subfolder, the rules will have to be updated. As moving these things around is a rare situation, WebP Express are not using any resources monitoring this. However, it will do the check when you visit the settings page.
Note: Do not simply remove the plugin without deactivating it first. Deactivation takes care of removing the rules in the .htaccess file. With the rules there, but converter gone, your Google Chrome visitors will not see any jpeg images.
You can start a bulk conversion two ways:
I'm currently working on a file manager interface, which will become a third way.
There are several ways:
wp webp-express convert
regularilyWebP Express currently supports commands for converting and flushing webp images throug the CLI. You can use the --help option to learn about the options:
wp webp-express --help
. Displays the available commands
wp webp-express convert --help
. Displays the available options for the "convert" command.
A few examples:
wp webp-express convert
: Creates webp images for all unconverted images
wp webp-express convert --reconvert
: Also convert images that are already converted
wp webp-express convert themes
: Only images in the themes folder
wp webp-express convert uploads/2021
: Only images in the "2021" folder inside the uploads folder
wp webp-express convert --only-png
: Only the PNG images
wp webp-express convert --quality=50
: Use quality 50 (instead of what was entered in settings screen)
wp webp-express convert --converter=cwebp
: Specifically use cwebp converter.
wp webp-express flushwebp
: Remove all webp images
wp webp-express flushwebp --only-png
: Remove all webp images that are conversions of PNG images
Synopsises:
wp webp-express convert [<location>] [--reconvert] [--only-png] [--only-jpeg] [--quality=<number>] [--near-lossless=<number>] [--alpha-quality=<number>] [--encoding=<auto|lossy|lossless>] [--converter=<converter>]
wp webp-express flushwebp [--only-png]
I'm considering adding commands for viewing status, viewing conversion stats, generating the .htaccess files and modifying the settings. Please let me know if you need any of these or perhaps something else.
See the "Verifying that it works section"
Don't fret - you have options!
Of course, there is also the option of using another plugin altogether. I can recommend Optimole. If you want to try that out and want to support me in the process, follow this link. It is an affiliate link and will give me a reward in case you decide to sign up.
Actually, you might be mistaking, so first, make sure that you didn't make the very common mistake of thinking that something with the URL example.com/image.jpg must be a jpeg image. The plugin serves webp images on same URL as the original (unconverted) images, so do not let appearances fool you! Confused? See next FAQ item.
Assuming that you have inspected the content type header, and it doesn't show "image/webp", please make sure that: 1) You tested with a browser that supports webp (such as Chrome) 2) The image URL you are looking at are not pointing to another server (such as gravatar.com)
Assuming that all above is in place, please look at the response headers to see if there is a X-WebP-Convert-Status header. If there isn't, well, then it seems that the problem is that the image request isn't handed over to WebP Express. Reasons for that can be:
I shall write more on this FAQ item... Stay tuned.
Easy enough. Browsers looks at the content type header rather than the URL to determine what it is that it gets. So, although it can be confusing that the resource at example.com/image.jpg is a webp image, rest assured that the browsers are not confused. To determine if the plugin is working, you must therefore examine the content type response header rather than the URL. See the "How do I verify that the plugin is working?" Faq item.
I am btw considering making an option to have the plugin redirect to the webp instead of serving immediately. That would remove the apparent mismatch between file extension and content type header. However, the cost of doing that will be an extra request for each image, which means extra time and worse performance. I believe you'd be ill advised to use that option, so I guess I will not implement it. But perhaps you have good reasons to use it? If you do, please let me know!
WebP Express has three ways of distributing webp to webp-enabled browsers while still sending the originals to webp-disabled browsers. While method 1 can be combined with any of the other methods, you would usually just pick method 1 or one of the others if method 1 cannot be used for you.
Can some of these go wrong? Yes. All!
The "Varied image responses" method adds rules to the .htaccess
which redirects jpegs and pngs to the corresponding webps (if they exist). The rules have a condition that makes sure they only trigger for browsers supports webp images (this is established by examining the "accept" header).
I the method "varied image responses" because the response on a given image URL varies (the webp is served on the same URL as the jpeg/png).
In the cases where method 1 fails, it is due to systems that cache images by the URL alone. To prevent this from happening, the .htaccess
rules adds a Vary:Accept
response header. However, most CDNs does not respect that header unless they are configured to do so. Fortunately proxy servers respects it nicely (however often by throwing out the cached image if the accept header doesn't match)
Method 1 can go wrong if:
.htaccess
. On Apache, the "mod_headers" module needs to be enabled. Otherwise the all important Vary:Accept
response header will not be set on the response.Vary:Accept
header.I do not believe it can go wrong in other ways. To be certain, please check out this test page. When visiting the test-page with Safari, you should see two images with the “JPG” label over them. When visiting the test-page with a browser that supports webp, you should see two images with the “WEBP” label over them. If you do not see one of these things, please report! (no-one has yet experienced that).
Since WebP Express 0.15.0 you can use the "Live test" button to check that browsers not supporting webp gets the original files and that the Vary:Accept header is returned. Note however that it may not detect CDN caching problems if the CDN doesn't cache a new image immediately - and across all its nodes.
IMG tags are replaced with PICTURE tags which has two sources. One of them points to the webp and has the "content-type" set to "image/webp". The other points to the original. The browser will select the webp source if it supports webp and the other source if it doesn't.
Method 2 can go wrong on old browser that doesn't support the picture tag syntax. However, simply enable the "Dynamically load picturefill.js on older browsers" option, and it will take care of that issue.
In this solution, the URLs in the HTML are modified for browsers that supports webp. Again, this is determined by examining the "accept" header. So, actually the complete page HTML varies with this method.
Method 3 can go wrong if you are using a page caching plugin if that plugin does not create a separate webp cache for webp-enabled browsers. The Cache Enabler plugin handles this. I don't believe there are other page caching plugins that does. There is a FAQ section in this FAQ describing how to set Cache Enabler up to work in tandem with WebP Express.
Note that Firefox 66+ unfortunately stopped including "image/webp" in the "accept" header it sends when requesting the page. While Firefox 66+ fortunately still includes "image/webp" in its accept header for images. That will however not get it webp images when using method 3.
WebP Express works well on NGINX, however the UI is not streamlined NGINX yet. And of course, NGINX does not process the .htaccess files that WebP Express generates. WebP Express can be used without redirection, as it can alter HTML to use picture tags which links to the webp alternative. See "The simple way" below. Or, you can get your hands dirty and set up redirection in NGINX guided by the "The advanced way" section below.
The easy solution is simply to use the plugin in "CDN friendly" mode, do a bulk conversion (takes care of converting existing images), activate the "Convert on upload" option (takes care of converting new images in the media library) and enable Alter HTML (takes care of delivering webp to webp enabled browsers while still delivering the original jpeg/png to browsers not supporting webp).
PRO: Very easy to set up. CON: Images in external CSS and images being dynamically added with javascript will not be served as webp. CON: New new theme images will not be converted until you run a new Bulk conversion
Creating NGINX rules requires manually inserting redirection rules in the NGINX configuration file (nginx.conf or the configuration file for the site, found in /etc/nginx/sites-available
). If you do not have access to do that, you will have to settle with the "simple way" described above.
There are two different approaches to achieve the redirections. The one that I recommend is based on a try_files directive. If that doesn't work for you, you can try the alternative rules that are based on the rewrite directive. The rules are described in the next couple of sections.
For multisite on NGINX, read here
Preparational step: The rules looks for existing webp files by appending ".webp" to the URL. So for this to work, you must configure WebP Express to store the converted files like that by setting General > File extension to Append ".webp"
The rules:
Insert the following in the server
context of your configuration file (usually found in /etc/nginx/sites-available
). "The server
context" refers to the part of the configuration that starts with "server {" and ends with the matching "}".
# WebP Express rules
# --------------------
location ~* ^/?wp-content/.*\.(png|jpe?g)$ {
add_header Vary Accept;
expires 365d;
if ($http_accept !~* "webp"){
break;
}
try_files
/wp-content/webp-express/webp-images/doc-root/$uri.webp
$uri.webp
/wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content
;
}
# Route requests for non-existing webps to the converter
location ~* ^/?wp-content/.*\.(png|jpe?g)\.webp$ {
try_files
$uri
/wp-content/plugins/webp-express/wod/webp-realizer.php?xdestination=x$request_filename&wp-content=wp-content
;
}
# ------------------- (WebP Express rules ends here)
BEWARE:
Beware that when copy/pasting you might get html-encoded characters. Verify that the ampersand before "wp-content" isn't encoded (in the last line in the try_files block)
Beware that the rules looks for existing webp files by appending ".webp" to the URL. So for this to work, you must configure WebP Express to store the converted files like that.
Beware that if you haven't enabled png conversion, you should replace "(png|jpe?g)" with "jpe?g".
Beware that if you have moved wp-content to a non-standard place, you must change accordingly. Note that you must then also change the "wp-content" parameter to the script. It expects a relative path to wp-content (from document root) and is needed so the script can find the configuration file.
Beware that there is a hack out there for permalinks which is based on "rewrite" (rather than the usual solution which is based on try_files). If you are using that hack to redirect missing files to index.php, you need to modify it as specified here
I have put in an expires statement for caching. You might want to modify or disable that.
The rules contains all redirections (as if you enabled all three redirection options in settings). If you do not wish to redirect to converter, remove the last line in the try_files block. If you do not wish to create webp files upon request, remove the last location block.
If you have configured WebP Express to store images in separate folder, you do not need the "$uri.webp" line in the first "try_files" block. But it doesn't hurt to have it. And beware that the reverse is not true. If configured to store images in the same folder ("mingled"), you still need the line that looks for a webp in the separate folder. The reason for this is that the "mingled" only applies to the images in the upload folder - other images - such as theme images are always stored in a separate folder.
If you cannot get this to work then perhaps you need to add the following to your mime.types configuration file:
image/webp webp;
If you still cannot get it to work, you can instead try the alternative rules below.
Credits: These rules are builds upon Eugene Lazutkins solution.
In case the recommended rules does not work for you, you can try these alternative rules.
The reason I recommend the try_files approach above over these alternative rules is that it is a bit simpler and it is supposed to perform marginally better. These alternative rules are in no way inferior to the other. Choose whatever works!
Preparational step: The rules looks for existing webp files by appending ".webp" to the URL. So for this to work, you must configure WebP Express to store the converted files like that by setting General > File extension to Append ".webp". Also make sure that WebP Express is configured with "Destination" set to "Mingled".
The rules:
Insert the following in the server
context of your configuration file (usually found in /etc/nginx/sites-available
). "The server
context" refers to the part of the configuration that starts with "server {" and ends with the matching "}".
# WebP Express rules
# --------------------
location ~* ^/wp-content/.*\.(png|jpe?g)$ {
add_header Vary Accept;
expires 365d;
}
location ~* ^/wp-content/.*\.webp$ {
expires 365d;
if ($whattodo = AB) {
add_header Vary Accept;
}
}
if ($http_accept ~* "webp"){
set $whattodo A;
}
if (-f $request_filename.webp) {
set $whattodo "${whattodo}B";
}
if ($whattodo = AB) {
rewrite ^(.*) $1.webp last;
}
if ($whattodo = A) {
rewrite ^/wp-content/.*\.(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content break;
}
# ------------------- (WebP Express rules ends here)
BEWARE:
Beware that when copy/pasting you might get html-encoded characters. Verify that the ampersand before "wp-content" isn't encoded (in the last line in the try_files block)
Beware that the rules looks for existing webp files by appending ".webp" to the URL. So for this to work, you must configure WebP Express to store the converted files like that.
Beware that if you haven't enabled png conversion, you should replace "(png|jpe?g)" with "jpe?g".
Beware that if you have moved wp-content to a non-standard place, you must change accordingly. Note that you must then also change the "wp-content" parameter to the script. It expects a relative path to wp-content (from document root) and is needed so the script can find the configuration file.
Beware that there is a hack out there for permalinks which is based on "rewrite" (rather than the usual solution which is based on try_files). If you are using that hack to redirect missing files to index.php, you need to modify it as specified here
I have put in an expires statement for caching. You might want to modify or disable that.
I have not set any expire on the webp-on-demand.php request. This is not needed, as the script sets this according to what you set up in WebP Express settings. Also, trying to do it would require a new location block matching webp-on-demand.php, but that would override the location block handling php files, and thus break the functionality.
There is no longer any reason to add "&$args" to the line begining with "/wp-content". It was there to enable debugging a single image by appending "?debug" to the url. I however removed that functionality from webp-on-demand.php
.
It is possible to put this stuff inside a location
directive. However, having if
directives inside location
directives is considered evil. But it seems that in our case, it works. If you wish to do that, use the following rules instead:
# WebP Express rules
# --------------------
location ~* ^/wp-content/.*\.(png|jpe?g)$ {
add_header Vary Accept;
expires 365d;
if ($http_accept ~* "webp"){
set $whattodo A;
}
if (-f $request_filename.webp) {
set $whattodo "${whattodo}B";
}
if ($whattodo = AB) {
rewrite ^(.*) $1.webp last;
}
if ($whattodo = A) {
rewrite ^/wp-content/.*\.(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content last;
}
}
location ~* ^/wp-content/.*\.webp$ {
expires 365d;
if ($whattodo = AB) {
add_header Vary Accept;
}
}
# ------------------- (WebP Express rules ends here)
PS: In case you only want to redirect images to the script (and not to existing), the rules becomes much simpler:
# WebP Express rules
# --------------------
if ($http_accept ~* "webp"){
rewrite ^/(.*).(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content break;
}
# ------------------- (WebP Express rules ends here)
Discussion on this topic here And here: https://github.com/rosell-dk/webp-express/issues/166
Here are rules if you need to replace the file extension with ".webp" rather than appending ".webp" to it: https://www.keycdn.com/support/optimus/configuration-to-deliver-webp
Good news! It should work now, thanks to a guy that calls himself lwxbr. At least on XAMPP 7.3.1, Windows 10. https://github.com/rosell-dk/webp-express/pull/213.
You do not have to do anything special for it to work on a Litespeed server. You should be able to use WebP Express in any operation mode. For best performance, I however recommend that use the LiteSpeed Cache plugin for page caching.
LiteSpeed Cache can be set up to maintain separate page caches for browsers that supports webp and browsers that don't. Through this functionality it is possible to use "Alter HTML" with the option "Replace image URLs" and "Only do the replacements in webp enabled browsers" mode.
The setup was kindly shared and explained in detail by @ribeiroeder here
If you install Jetpack and enable the "Speed up image load times" then Jetpack will alter the HTML such that images are pointed to their CDN.
Ie:
<img src="https://example.com/wp-content/uploads/2018/09/architecture.jpg">
becomes:
<img src="https://i0.wp.com/example.com/wp-content/uploads/2018/09/architecture.jpg">
Jetpack automatically serves webp files to browsers that supports it using same mechanism as the standard WebP Express configuration: If the "Accept" header contains "image/webp", a webp is served (keeping original file extension, but setting the "content-type" header to "image/webp"), otherwise a jpg is served.
As images are no longer pointed to your original server, the .htaccess rules created by WebP Express will not have any effect.
So if you are using Jetpack you don't really need WebP Express? Well, there is no point in having the "Speed up image load times" enabled together with WebP Express.
But there is a case for using WebP Express rather than Jetpacks "Speed up image load times" feature:
Jetpack has the same drawback as the Varied image responses operation mode: If a user downloads the file, there will be a mismatch between the file extension and the image type (the file is ie called "logo.jpg", but it is really a webp image). I don't think that is a big issue, but for those who do, WebP Express might still be for you, even though you have Jetpack. And that is because WebP Express can be set up just to generate webp's, without doing the internal redirection to webp (will be possible from version 0.10.0). You can then for example use the Cache Enabler plugin, which is able to generate and cache two versions of each page. One for browsers that accepts webp and one for those that don't. In the HTML for webp-enabled browsers, the images points directly to the webp files.
Pro Jetpack:
Con Jetpack:
Pro WebP Express:
Con WebP Express:
The option will only display, if your system is able to detect jpeg qualities. To make your server capable to do that, install Imagick extension (PECL >= 2.2.2) or enable exec() calls and install either Imagick or Gmagick.
If you have the Imagick, the Imagick binary or the Remote WebP Express conversion method working, but don't have the global "auto" option, you will have the auto option available in options of the individual converter.
Note: If you experience that the general auto option doesn't show, even though the above-mentioned requirements should be in order, check out this support-thread.
In Varied image responses operation mode, the image responses varies depending on whether the browser supports webp or not (which browsers signals in the Accept header). Some CDN's support this out of the box, others requires some configuration and others doesn't support it at all.
For a CDN to cooperate, it needs to 1) forward the Accept header and 2) Honour the Vary:Accept response header.
You can also make it "work" on some CDN's by bypassing cache for images. But I rather suggest that you try out the CDN friendly mode (see next FAQ item)
I shall add more to the list. You are welcome to help out here.
In CDN friendly mode, there is no trickery with varied image responses, so no special attention is required on the CDN.
However, there are other pitfalls.
The thing is that, unless you have the whole site on a CDN, you are probably using a plugin that alters the HTML in order to point your static assets to the CDN. If you have enabled the "Alter HTML" in WebP Express, it means that you now have two alterations on the image URLs!
How will that play out?
Well, if WebP Express gets to alter the HTML after the image URLs have been altered to point to a CDN, we have trouble. WebP Express does not alter external images but the URLs are now external.
However, if WebP Express gets to alter the HTML before the other plugin, things will work fine.
So it is important that WebP Express gets there first.
The good news is that WebP Express does get there first on all the plugins I have tested.
But what can you do if it doesn't?
Firstly, you have an option in WebP Express to select between:
The content filtering hooks gets to process the content before output buffering does. So in case output buffering isn't early enough for you, choose the content filtering hooks.
There is a risk that you CDN plugin also uses content filtering hooks. I haven't encountered any though. But if there is any out there that does, chances are that they get to process the content before WebP Express, because I have set the priority of these hooks quite high (10000). The reasoning behind this is to that we want to replace images that might be inserted using the same hook (for example, a theme might use the_content filter to insert the featured image). If you do encounter a plugin for changing URLs for CDN which uses the content filtering hooks, you are currently out of luck. Let me know, so I can fix that (ie. by making the priority configurable)
Here are a list of some plugins for CDN and when they process the HTML:
Plugin | Method | Hook(s) | Priority |
---|---|---|---|
BunnyCDN | Output buffering | template_redirect | default (10) |
CDN enabler | Output buffering | template_redirect | default (10) |
Jetpack | content filtering | the_content, etc | the_content: 10 |
W3 Total Cache | Output buffering | no hooks. Buffering is started before hooks | |
WP Fastest Cache | Output buffering | no hooks. Buffering is started before hooks | |
WP Super Cache | Output buffering | init | default (10) |
With output buffering the plugin that starts the output buffering first gets to process the output last. So WebP Express starts as late as possible, which is on the template_redirect
hook, with priority 10000 (higher means later). This is later than the init
hook, which is again later than the no hooks
.
Without configuration, Cloudflare will not maintain separate caches for jpegs and webp; all browsers will get jpeg. To make Cloudflare cache not only by URL, but also by header, you need to use the Custom Cache Key page rule, and add Header content to make separate caches depending on the Accept request header.
However, the Custom Cache Key rule currently requires an Enterprise account. And if you already have that, you may as well go with the Polish feature, which starts at the “Pro” level plan. With the Polish feature, you will not need WebP Express.
To make WebP Express work on a free Cloudflare account, you have the following choices:
You can configure the CDN not to cache jpeg images by adding the following page rule: If rule matches: example.com/*.jpg
, set: Cache level to: Bypass
You can set up another CDN (on another provider), which you just use for handling the images. You need to configure that CDN to forward the Accept header. You also need to install a Wordpress plugin that points images to that CDN.
You can switch operation mode to "CDN friendly" and use HTML altering.
From version 0.17.1 on WebP Express works with WP engine and this combination will be tested before each release.
You can use the plugin both in "Varied image responses" mode and in "CDN friendly mode".
To make the redirection work, you must: 1) Grab the nginx configuration found in the "I am on Nginx/OpenResty" section in this FAQ. Use the "try_files" variant. 2) Contact help center and ask them to insert that configuration. 3) Make sure the settings match this configuration. Follow the "beware" statements in the "I am on Nginx/OpenResty" section.
WebP Express tweaks the workings of "Redirect to converter" a bit for WP engine. That PHP script usually serves the webp directly, along with a Vary:Accept header. This header is however overwritten by the caching machinery on WP engine. As a work-around, I modified the response of the script for WP engine. Instead of serving the image, it serves a redirect to itself. As there now IS a corresponding webp, this repeated request will not be redirected to the PHP script, but directly to the webp. And headers are OK for those redirects. You can hit the "Live test" button next to "Enable redirection to converter?" to verify that this works as just described.
If you (contrary to this headline!) are in fact not on WP Engine, but might want to be, I have an affiliate link for you. It will give you 3 months free and it will give me a reward too, if you should decide to stay there. Here you go: Get 3 months free when you sign up for WP Engine.
Here is a recipe for using WebP Express together with ShortPixel, such that WebP Express generates the webp's, and ShortPixel only is used to create <picture>
tags, when it detects a webp image in the same folder as an original.
There is really no need to do this anymore, because WebP Express is now capable of replacing img tags with picture tags (check out the Alter HTML option)
You need: 1 x WebP Express 1 x ShortPixel
1. Setup WebP Express If you do not want to use serve varied images:
If you want to ShortPixel to create
2. Setup ShortPixel
3. Visit a page
As there are presumably no webps generated yet, ShortPixel will not generate <picture>
tags on the first visit. However, the images that are referenced causes the WebP Express Auto convert feature to kick in and generate webp images for each image on that page.
4. Visit the page again
As WebP Express have generated webps in the same folder as the originals, ShortPixel detects these, and you should see <picture>
tags which references the webp's.
ShortPixel or Cache Enabler ?
Cache Enabler has the advantage over ShortPixel that the HTML structure remains the same. With ShortPixel, image tags are wrapped in a <picture>
tag structure, and by doing that, there is a risk of breaking styles.
Further, Cache Enabler caches the HTML. This is good for performance. However, this also locks you to using that plugin for caching. With ShortPixel, you can keep using your favourite caching plugin.
Cache Enabler will not work if you are caching HTML on a CDN, because the HTML varies depending on the Accept header and it doesn't signal this with a Vary:Accept header. You could however add that manually. ShortPixel does not have that issue, as the HTML is the same for all.
The WebP Express / Cache Enabler setup is quite potent and very CDN-friendly. Cache Enabler is used for generating and caching two versions of the HTML (one for webp-enabled browsers and one for webp-disabled browsers)
The reason for doing this could be:
You need: 1 x WebP Express 1 x Cache Enabler
1. Setup WebP Express If you do not want to use serve varied images:
If you want to Cache Enabler to create
2. Setup Cache Enabler
3. If you did not enable Alter HTML and Reference webps that hasn't been converted yet: Let rise in a warm place until doubled
WebP Express creates webp images on need basis. It needs page visits in order to do the conversions . Bulk conversion is on the roadmap, but until then, you need to visit all pages of relevance. You can either do it manually, let your visitors do it (that is: wait a bit), or, if you are on linux, you can use wget
to grab your website:
wget -e robots=off -r -np -w 2 http://www.example.com
flags:
-e robots=off
makes wget ignore rules in robots.txt
-np
(no-parent) makes wget stay within the boundaries (doesn't go into parent folders)
w 2
Waits two seconds between each request, in order not to stress the server
4. Clear the Cache Enabler cache. Click the "Clear Cache" button in the top right corner in order to clear the Cache Enabler cache.
5. Inspect the HTML When visiting a page with images on, different HTML will be served to browsers, depending on whether they support webp or not.
In a webp-enabled browser, the HTML may look like this: <img src="https://github.com/rosell-dk/webp-express/raw/master/image.webp">
, while in a non-webp enabled browser, it looks like this: <img src="https://github.com/rosell-dk/webp-express/raw/master/image.jpg">
6. Optionally add Cache Enabler rewrite rules in your .htaccess
Cache Enabler provides some rewrite rules that redirects to the cached file directly in the .htaccess
, bypassing PHP entirely. Their plugin doesn't do that for you, so you will have to do it manually in order to get the best performance. The rules are in the "Advanced configuration" section on this page.
No plugins/frameworks has yet been discovered, which does not work with WebP Express.
The most common way of lazy-loading is by setting a data-src attribute on the image and let javascript use that value for setting the src attribute. That method works, as the image request, seen from the server side, is indistinguishable from any other image request. It could however be that some obscure lazy load implementation would load the image with an XHR request. In that case, the Accept header will not contain 'image/webp', but '/', and a jpeg will be served, even though the browser supports webp.
The following lazy load plugins/frameworks has been tested and works with WebP Express:
I have only tested the above in Varied image responses mode, but it should also work in CDN friendly mode. Both Alter HTML options have been designed to work with standard lazy load attributes.
There can be instances where you actually need to serve a jpeg or png. For example if you are demonstrating how a jpeg looks using some compression settings.
If you want an image to be served in the original format (jpeg og png), do one of the following things:
Doing this will bypass redirection to webp and also prevent Alter HTML to use the webp instead of the original.
Bypassing for an entire folder
To bypass redirection for an entire folder, you can put something like this into your index .htaccess
:
RewriteRule ^wp-content/uploads/2021/06/ - [L]
PS: If WebP Express has placed rules in that .htaccess, you need to place the rule above the rules inserted by WebP Express
If you got any further questions, look at, or comment on this topic
If you are wondering why Alter HTML are missing some images, it can be due to one of the following reasons:
<picture>
tags syntax, only images inserted with <img>
-tags will be replaced (CSS images will not be replaced). Additionally, the <img>
-tag must have a "src" attribute or a commonly used data attribute for lazyloading (such as “data-src” or “data-lazy-src”)The 0.17.0 release contained binaries with dots in their filenames, which caused the unpacking during update to fail on a few systems. This failure could leave an incomplete installation. With important files missing - such as the main plugin file - Wordpress no longer registers that the plugin is there (it is missing from the list). However, the folder is there in the file system and trying to install WebP Express again fails because Wordpress complains about just that. The solution is to remove the "webp-express" folder in "plugins" manually (via ftp or a plugin, such as File Manager) and then install WebP Express anew. The setting will be intact. The filenames that caused the trouble where fixed in 0.17.2.
No schedule. I move forward as time allows. I currently spend a lot of time answering questions in the support forum. If someone would be nice and help out answering questions here, it would allow me to spend that time developing. Also, donations would allow me to turn down some of the more boring requests from my customers, and speed things up here.
Right now I am focusing on the File Manager. I would like to add possibility for converting, bulk converting, viewing conversion logs, viewing stats, etc.
Here are other things in pipeline:
The current milestones, their subtasks and their progress can be viewed here: https://github.com/rosell-dk/webp-express/milestones
If you wish to affect priorities, it is certainly possible. You can try to argue your case in the forum or you can simply let the money do the talking. By donating as little as a cup of coffee on ko-fi.com/rosell, you can leave a wish. I shall take these wishes into account when prioritizing between new features.
I generally create a pre-release before publishing. If you follow me on ko-fi, you will get notified when a pre-release is available. I generally create a pre-release on fridays and mark it as stable on mondays. In order to download a pre-release, go to the advanced page and scroll down to "Please select a specific version to download". I don't name the pre-releases different. You will just see the next version here before it is available the usual way.
(released: 27 Oct 2021)
For more info, see the closed issues on the webp-express 0.21.1 milestone
(released: 25 Oct 2021)
For more info, see the closed issues on the webp-express 0.21.0 milestone and the webp-convert 2.7.0 milestone
(released: 20 Jun 2021)
(released: 17 Jun 2021)
(released: 13 Nov 2020)
For more info, see the closed issues on the 0.19.0 milestone on the github repository
(released: 5 Nov 2020)
For more info, see the closed issues on the 0.18.3 milestone on the github repository: https://github.com/rosell-dk/webp-express/milestone/34?closed=1
Bread on the table don't come for free, even though this plugin does, and always will. I enjoy developing this, and supporting you guys, but I kind of need the bread too. Please make it possible for me to continue putting effort into this plugin:
Persons / Companies currently backing the project via patreon - Thanks!
Persons who contributed with coffee within the last 30 days:
Name | Date | Message |
---|---|---|
Anon | 2020-08-18 | - |
Eder Ribeiro | 2020-08-08 | Hello Bjørn I believe that it is a fantastic solution and that it deserves maximum support to keep getting better! If you can, check out my configuration tip, https://github.com/rosell-dk/webp-express/issues/433 |
Christian | 2020-08-05 | Merci pour votre plugin. Exceptionnel et gratuit. |
Persons who contributed with extra generously amounts of coffee / lifetime backing (>50$) - thanks!:
Name | Amount | Message |
---|---|---|
Justin - BigScoots | $105 | Such an amazing plugin for so many reasons, thank you! |
Sebastian | $99 | WebP for Wordpress – what a great plugin! Thank you! |
Tammy Lee | $90 | |
Max Kreminsky | $65 | |
Steven Sullivan | $51 | Thank you for such a wonderful plugin. |