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
Almost 4 out of 5 mobile users use 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.
Security notice Security issues has been found and fixed. I urge you to upgrade to the latest release (at least 0.14.11, but go with 0.14.15, as there are important bug fixes)
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: cwebp, gd, imagick. 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:
- By routing jpeg/png images to the corresponding webp - or to the image converter if the image hasn't been converted yet.
- By altering the HTML, replacing image tags with picture tags. Missing webps are auto generated upon visit.
- By altering the HTML, replacing image URLs so all points to webp. The replacements only being made for browsers that supports webp. Again, missing webps are auto generated upon visit.
- In combination with Cache Enabler, the same as above can be achieved, but with page caching.
- You can also deliver webp to all browsers and add the webpjs javascript, which provides webp support for browsers that doesn't support webp natively. You currently have to add the javascript yourself, but I expect to add an option for it in the next release.
The plugin builds on WebPConvert and its "WebP On Demand" solution described here
- Much faster load time for images in browsers that supports webp. The converted images are typically less than half the size (for jpeg), while maintaining the same quality. Bear in mind that for most web sites, images are responsible for the largest part of the waiting time.
- Better user experience (whether performance goes from terrible to bad, or from good to impressive, it is a benefit)
- Better ranking in Google searches (performance is taken into account by Google)
- Less bandwidth consumption - makes a huge difference in the parts of the world where the internet is slow and costly (you know, ~80% of the world population lives under these circumstances).
- Currently ~73% of all traffic, and ~79% of mobile browsing traffic are done with browsers supporting webp. With Mozilla and Microsoft finally on board, these numbers are bound to increase. Check current numbers on caniuse.com).
Feb 2019: Multisite is now supported (0.12.0) Jan 2019: Plugin can now alter HTML (0.11.0)
- Upload the plugin files to the
/wp-content/plugins/webp-expressdirectory, or install the plugin through the WordPress plugins screen directly. - Activate the plugin through the 'Plugins' screen in WordPress
- Configure it (the plugin doesn't do anything until configured)
- Verify that it works
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, ewww cloud converter and remote WebP express. 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:
- You can install this plugin on another website, which supports a local conversion method and connect to that using the "Remote WebP Express" conversion method
- You can purchase a key for the ewww cloud converter. They do not charge credits for webp conversions, so all you ever have to pay is the one dollar start-up fee :)
- You can set up webp-convert-cloud-service on another server and connect to that. Its open source.
- You can try to meet the server requirements of cwebp, gd, imagick or gmagick. Check out this wiki page on how to do that
If your server has imagick og gmagick installed, the plugin will be able to detect the quality of a jpeg, and use the same quality for the converted webp. You can tell if it does, by looking at the quality option. If it allows you to select "auto" quality, it is available, otherwise it is not, and you will only have the option to set a specific quality for all conversions. Auto should be chosen, if available, as this ensures that each conversion are converted with an appropriate quality. Say you have a jpeg with low quality (say 30). The best result, is achieved by converting it to the same quality. Converting it with high quality (say 80), will not get you better quality, only a larger file.
If you do not the "auto" option available:
- Install imagick or gmagick, if you can
- Use "Remote WebP Express" converter to connect to a site, that does have the auto option available
- If you have cwebp converter available, you can configure it to aim for a certain reduction, rather than using the quality parameter. Set this to for example 50%, or even 45%.
Once, you have a converter, that works, when you click the "test"-button, you are ready to test the whole stack, and the rewrite rules. To do this, first make sure to select something other than "Do not convert any images!" in Image types to convert. Next, click "Save settings". This will save settings, as well as update the .htaccess.
If you are working in a browser that supports webp (ie Google Chrome), you will see a link "Convert test image (show debug)" after a successful save. Click that to test if it works. The screen should show a textual report of the conversion process. If it shows an image, it means that the .htaccess redirection isn't working. It may be that your server just needs some time. Some servers has set up caching. It could also be that your images are handled by nginx.
Note that the plugin does not change any HTML (unless you enabled the Alter HTML option). In the HTML the image src is still set to ie "example.jpg". To verify that the plugin is working (without clicking the test button), do the following:
- Open the page in Google Chrome
- Right-click the page and choose "Inspect"
- Click the "Network" tab
- Reload the page
- Find a jpeg or png image in the list. In the "type" column, it should say "webp"
In order to test that the image is not being reconverted every time, look at the Response headers of the image. There should be a "X-WebP-Convert-Status" header. It should say "Serving existing converted image" the first time, but "Serving existing converted image" on subsequent requests (WebP-Express is based upon WebP Convert).
You can also append ?debug after any image url, in order to run a conversion, and see the conversion report. Also, if you append ?reconvert after an image url, you will force a reconversion of the image.
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.
- The plugin should now work on Microsoft IIS server, but it has not been tested thoroughly.
See the "Verifying that it works section"
Don't fret - you have options!
- If you a controlling another WordPress site (where the local conversion methods DO work), you can set up WebP Express there, and then connect to it by configuring the “Remote WebP Express” conversion method.
- You can also setup the ewww conversion method. To use it, you need to purchase an api key. They do not charge credits for webp conversions, so all you ever have to pay is the one dollar start-up fee 🙂 (unless they change their pricing – I have no control over that). You can buy an api key here: https://ewww.io/plans/
- If you are up to it, you can try to get one of the local converters working. Check out this page on the webp-convert wiki
- Finally, if you have access to a server and are comfortable with installing projects with composer, you can install webp-convert-cloud-service. It's open source.
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:
- You tested with a browser that supports webp (such as Chrome)
- 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:
- You are on NGINX (or an Apache/Nginx combination). NGINX requires special attention, please look at that FAQ item
- You are on WAMP. Please look at that FAQ item
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!
It is possible to make WebP Express work on NGINX, but it 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).
There are two different approaches to achieve the redirections. One based on rewrite and one based on try_files. As try_files performs best, I shall recommend that.
For multisite on NGINX, read here
Lets take this step by step. First step is to redirect images to the script. Second step is redirecting directly to existing webp images. Finally, as an optional third step, you can add extra rules for enabling the Convert non-existing webp-files upon request functionality
Step 1: Redirecting images to the script
The following will redirect all images under wp-content to the script, but only for webp-enabled browsers.
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 "}".
location ~* ^/?wp-content/.*\.(png|jpe?g)$ {
add_header Vary Accept;
if ($http_accept !~* "webp"){
break;
}
try_files
/nonexisting-because-try-files-needs-fallback
/wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content&$args
;
}Beware when copy/pasting: You might get html-encoded characters. Verify that the ampersand before "wp-content" isn't encoded
If you have moved wp-content to a non-standard place, you must change accordingly. Especially note that you must 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.
The xsource parameter helps the script finding the source file. It is only needed on some setups. You can try deleting it and see if it still works.
Beware that if you haven't enabled png conversion, you should replace "(png|jpe?g)" with "jpe?g", so the first line becomes:
location ~* ^/?wp-content/.*\.jpe?g$ {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 method 2
Step 2: Redirecting directly to existing webp images.
Once you got this working, lets improve performance by redirecting directly to existing webp images. This step isn't necessary, as the script also does that - but invoking the php script takes more resources that the direct redirect. Also, a direct redirect will produce ETag response header, which is increases caching performance.
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:
- Set Destination folder to mingled
- Set File extension to Append ".webp"
Now, place the following in the server context (replacing what you inserted in step 1):
# WebP Express rules
# --------------------
location ~* ^/?wp-content/.*\.(png|jpe?g)$ {
add_header Vary Accept;
# expires 365d;
if ($http_accept !~* "webp"){
break;
}
try_files
$uri.webp
/wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content&$args
;
}
# ------------------- (WebP Express rules ends here)Beware when copy/pasting: You might get html-encoded characters. Verify that the ampersand before "wp-content" isn't encoded
Again, beware that if you haven't enabled png conversion, you should replace "(png|jpe?g)" with "jpe?g".
Credits: This second step builds on Eugene Lazutkins solution.
Step 3:: Caching In most cases you can and should allow images to be cached for a long period. To do that, simply uncomment the "expires 365d;" line, by removing the "#" in front of it.
Step 4:: Routing requests for non-existing webps to the converter
Simply add the following rules below the ones you added in step 2:
location ~* ^/?wp-content/.*\.(png|jpe?g)\.webp$ {
try_files
$uri
/wp-content/plugins/webp-express/wod/webp-realizer.php?wp-content=wp-content&$args
;
}Again, beware that if you haven't enabled png conversion, you should replace "(png|jpe?g)" with "jpe?g".
Step 1: Redirecting images to the script
Insert the following in the server context:
# 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)Step 2: Redirecting directly to existing webp images.
Insert the following in the server context (replacing the rules you inserted in step 1)
# 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 when copy/pasting: You might get html-encoded characters. Verify that the ampersand before "wp-content" isn't encoded
Again, wp-content argument must point to the wp-content folder (relative to document root). In most installations, it is 'wp-content'.
And again, 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:
- Set Destination folder to mingled
- Set File extension to Append ".webp"
The "expires 365d;" lines set caching to one year. You can remove these lines if you wish.
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.
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)Beware when copy/pasting: You might get html-encoded characters. Verify that the ampersand before "wp-content" isn't encoded
Discussion on this topic here And here: rosell-dk#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. rosell-dk#213.
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:
- It is a free CDN which serves webp out of the box.
- It optimizes jpegs and pngs as well (but note that only about 1 out of 5 users gets these, as webp is widely supported now)
Con Jetpack:
- It is a big plugin to install if you are only after the CDN
- It requires that you create an account on Wordpress.com
Pro WebP Express:
- You have control over quality and metadata
- It is a small plugin and care has been taken to add only very little overhead
- Plays well together with Cache Enabler. By not redirecting jpg to webp, there is no need to do any special configuration on the CDN and no issue with misleading file extension, if user downloads a file.
Con WebP Express:
- If you are using a CDN and you are redirecting jpg to webp, you must configure the CDN to forward the Accept header. It is not possible on all CDNs.
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
- forward the Accept header and
- 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)
- KeyCDN: Does not support varied image responses. I have added a feature request here. You can give it a +1 if you like!
- Cloudflare: See the "I am on Cloudflare" item
- Cloudfront: Works, but needs to be configured to forward the accept header. Go to Distribution settings, find the Behavior tab, select the Behavior and click the Edit button. Choose Whitelist from Forward Headers and then add the "Accept" header to the whitelist.
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:
- Use content filtering hooks (the_content, the_excerpt, etc)
- The complete page (using output buffering)
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.
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:
- Open WebP Express options
- Switch to CDN friendly mode.
- Set File extension to "Set to .webp"
- Make sure the Convert non-existing webp-files upon request to original image option is enabled
If you want to ShortPixel to create
- Open WebP Express options
- Switch to Varied image responses mode.
- Set Destination folder to "Mingled"
- Set File extension to "Set to .webp"
2. Setup ShortPixel
- Install ShortPixel the usual way
- Get an API key and enter it on the options page.
- In Advanced, enable the following options:
- Also create WebP versions of the images, for free.
- Deliver the WebP versions of the images in the front-end
- Altering the page code, using the tag syntax
- As there is a limit to how many images you can convert freely with ShortPixel, you should disable the following options (also on the Advanced screen):
- Automatically optimize images added by users in front end.
- Automatically optimize Media Library items after they are uploaded (recommended).
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 are using a CDN which cannot be configured to work in the "Varied image responses" mode.
- You could tweak your CDN to work in the "Varied image responses" mode, but you would have to do it by using the entire Accept header as key. Doing that would increase the risk of cache MISS, and you therefore decided that do not want to do that.
- You think it is problematic that when a user saves an image, it has the jpg extension, even though it is a webp image.
You need: 1 x WebP Express 1 x Cache Enabler
1. Setup WebP Express If you do not want to use serve varied images:
- Open WebP Express options
- Switch to CDN friendly mode.
- Set File extension to "Set to .webp"
- Enable Alter HTML and select Replace image URLs. It is not absolutely neccessary, as Cache Enabler also alters HTML - but there are several reasons to do it. Firstly, Cache Enabler doesn't get as many URLs replaced as we do. WebP Express for example also replaces background urls in inline styles. Secondly, Cache enabler has problems in edge cases. Thirdly, WebP Express can be configured to alter HTML to point to corresponding webp images, before they even exists which can be used in conjunction with the the Convert non-existing webp-files upon request option. And this is smart, because then you don't have trouble with Cache Enabler caching HTML which references the original images due to that some images hasn't been converted yet.
- If you enabled Alter HTML, also enable Reference webps that hasn't been converted yet and Convert non-existing webp-files upon request
- If you did not enable Alter HTML, enable Convert non-existing webp-files upon request to original image
If you want to Cache Enabler to create
- Open WebP Express options
- Switch to Varied image responses mode.
- Set Destination folder to "Mingled"
- Set File extension to "Set to .webp"
- I suggest you enable Alter HTML and select Replace image URLs. And also enable Reference webps that hasn't been converted yet and Convert non-existing webp-files upon request.
2. Setup Cache Enabler
- Open the options
- Enable of the Create an additional cached version for WebP image support option
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="image.webp">, while in a non-webp enabled browser, it looks like this: <img src="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. It is possible to bypass both the redirection and the HTML altering for certain images. Here is how:
Alter HTML Alter HTML is programmed not to substitute image URLs with query strings (better safe than sorry). You can exploit that and simply add ie ?original to the image URLs in question.
Redirection
To bypass the redirection, you can add the following in the .htaccess where WebP Express has placed its rules (this is usually in the wp-content folder). The rules needs to be added above the rules inserted by WebP Express.
RewriteCond %{QUERY_STRING} original
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule . - [L]
With those rules in place, you can add "?original" to the URLs of those images that you want to keep serving as jpg / png.
Alternatively, you can specify the filenames individually in the .htaccess:
RewriteRule ^uploads/2019/02/example-of-jpg-compressed-to-80\.jpg - [L]
RewriteRule ^uploads/2019/02/image2\.jpg - [L]
RewriteRule . - [L]
If you got any further questions, look at, or comment on this topic
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.
Here are my current plans ahead: 0.15 will probably be a file manager-like interface for converting / bulk converting / viewing conversion logs / comparing original vs webp visually - kind of a merge of current "test converter" and "bulk conversion" interfaces, and with an addition of a file explorer. 0.16 might be various improvements such as option to choose which folders webp express should process (Just uploads / Just uploads and templates / Whole wp-content / Whole system) and options to exclude certain files and folders. 0.17 could be supporting Save-Data header in Varied Image Responses mode (send extra compressed images to clients who wants to use as little bandwidth as possible). 0.18 might be a diagnose tool – this should release some time spend in the forum. 0.18 might be displaying rules for NGINX. 0.19 might be an effort to allow webp for all browsers using this javascript library. Unfortunately, the javascript librare does not (currently) support srcset attributes, which is why I moved this item down the priority list. We need srcset to be supported for the feature to be useful. 0.20 might be WAMP support. 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.
- Fixed errors with "redirect to conversion script" on systems with symlinked folders
- Fixed errors with "redirect to conversion script" on systems where the filename cannot be passed through an environment variable
The following security fixes has been applied in 0.14.0 - 0.14.11: It is urged that you upgrade all of you WebP Express installations!
- Security fix: Closed a security hole that could be used to view the content of any file on the server (provided that the full path is known or guessed). This is a very serious flaw, which unfortunately has been around for quite a while.
- Security fix: Added capability checks to options page.
- Security fix: Sanitized user input.
- Security fix: Added checks for file paths and directories.
- Security fix: Nonces and capability checks for AJAX calls.
- Now bundles with multiple cwebp binaries for linux for systems where 1.0.2 fails.
- Fixed filename of supplied cwebp for linux (bug was introduced in 0.14.2)
- Fixed problem with older versions of cwebp
- Fixed that images was not deleted
- Fixed cache problem on options page on systems that disables cache busting (it resulted in "SyntaxError: JSON.parse")
- A little something
- Security fix: Closed a security hole that could be used to view the content of any file on the server (provided that the full path is known or guessed). This is a very serious flaw, which has been around for quite a while. I urge you to upgrade to 0.14.0.
- Added new "encoding" option, which can be set to auto. This can in some cases dramatically reduce the size of the webp. It is supported by all converters except ewww and gd.
- Added new "near-lossless" option (only for cwebp and vips). Using this is a good idea for reducing size of lossless webps with an acceptable loss of quality
- Added new "alpha-quality" option (all converters, except ewww and gd). Using this is a good idea when images with transparency are converted to lossy webp - it has the potential to reduce the size up to 50% (depending on the source material) while keeping an acceptable level of quality
- Added new conversion methods: Vips and GraphicsMagick
- Imagick conversion method now supports webp options (finally cracked it!)
- Using MimeType detection instead of relying on file extensions
- In "test" converter you now change options and also test PNG files
- Added conversion logs
- PNGs are now enabled by default (with the new conversion features especially PNGs are compressed much better)
For more info, see the closed issues on the 0.14.0 milestone on the github repository: https://github.com/rosell-dk/webp-express/milestone/9?closed=1
- Fixed Fatal error on image upload in combination with the Enable Media Replace plugin. Thanks to Alexander Graef from Germany for reporting.
- It seems we finally nailed the blank settings page bug. Thanks to all involved, especially Richard Spenceley from the UK
- Fixed several bugs.
- Bulk Conversion
- Fixed problems with Gd converter and PNG
- Optinally auto convert upon media upload
- Windows fix (thanks, lwxbr!)
- Multisite support (!)
- A new operation mode: "No conversion", if you do not want to use WebP Express for converting. Replaces the old "Just redirect" mode
- Added capability testing of .htaccess. The .htaccess rules are now tailored to the capabilities on the system. For example, on some platforms the filename of a requested image is passed to the converter script through the query string, but on platforms that supports passing it through an environment variable, that method is used instead
- Picturefill.js is now optional (alter html, picture tag)
- A great bunch more!
For more info, see the closed issues on the 0.12.0 milestone on the github repository: https://github.com/rosell-dk/webp-express/milestone/12?closed=1
- Alter HTML to point to webp files (choose between picture tags or simply altering all image urls)
- Convert non-existing webp-files upon request (means you can reference the converted webp files before they are actually converted!)
- Introduced "Operation modes" in order to keep setting screens simple but still allow tweaking
- WebP Express can now be used in conjunction with Cache Enabler and ShortPixel
- Cache-Control header is now added in .htaccess, when redirecting directly to existing webp
- Optionally make .htaccess redirect directly to existing webp (improves performance)
- Optionally do not send filename from .htaccess to the PHP in Querystring, but use other means (improves security and reduces risks of problems due to firewall rules)
- Fixed some bugs
For more info, see the closed issues on the 0.9.0 milestone on the github repository: https://github.com/rosell-dk/webp-express/issues?q=is%3Aclosed+milestone%3A0.9.0
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: