webp cdn support

Shoot, I thought I had accounted for all the caching stuff, but I never thought about the variable I used being cached as well. Yeah, we’ll need to do client-side detection then, bummer…

If you have ideas for optimizing load_webp.js, please contact me here: https://ewww.io/contact-us/

I’ll see what I can do with the inline minified script, and the temporary style too (might need an example if you have an idea of how to do that).

Hey @nosilver4u, I’ve been really busy for past few months and didn’t have time to test it so far. But soon I’m migrating to a nginx vps, where I do wanna test it and wanna look into your script if it can be more optimized. But I’m worried that whether it will work on the nginx platform, as the script you provide is for apache, not for nginx.

The script in v2.3 is server-agnostic, the rewrite rules are Apache-only. As noted above though, it works for CDNs, but not with caching plugins (yet).

well if the rewrite rules are for apache only then how am I gonna use it on nginx?

The rewrite rules are not used (nor can they be) if you have a CDN in use.

Great, then it wont be a problem. I’ll look forward for the caching plugin support.

@ascom, changes are here: https://downloads.www.ads-software.com/plugin/ewww-image-optimizer.zip

I’ve inlined it, minified it, and used client-side detection. I’ve also removed the document.ready condition (since it is already in the footer), so it should run even faster too.

The original un-minified script is still in the download so you can see what I did and if you have any other ideas for code optimization.

I’m not sure it is possible to avoid the flow issues. The problem is that an <img> element does not exist outside of the <noscript> tag until the script runs. From what I can figure, it would be necessary to create an <img> with the dimensions of the original image with an empty src tag. The problem with this, is noscript users will have a completely broken page layout, because they will now have the actual image displayed (from within the <noscript> tag), and then a dummy image right afterwards.

If you’ve got a way around that, I’m all ears (or eyes…).

The updated version of the plugin causes the page to drop the ending tags:

Without the rewriting: https://i.imgur.com/lazMbBA.png
With the rewriting: https://i.imgur.com/2jdZRwo.png

Ah good catch, try a fresh copy: https://downloads.www.ads-software.com/plugin/ewww-image-optimizer.zip

I don’t know that anyone on this thread is in this situation, but I wanted to mention it here just in case anyone reads this thread and is curious about this particular setup.

The one last remaining hurdle related to CDNs is for those that have “push mode” setups. Both current rewriting configurations make no assumptions about a .webp file existing, but rather they check to make sure there IS a .webp file before performing rewriting on a particular image.

With a push mode CDN, this can actually work if you keep the originals on your server, but if you don’t, then EWWW has no way to determine that a .webp file is available. There are two plugins I’m aware of for Azure Storage and Amazon S3 that allow removing the local files, and WPEngine also has an S3 backed storage scheme which removes local files.

To that end, the only way I can think of to resolve this dilemma is to have a sort of ‘Forced WebP’ option. What it would do is generate .webp alternatives for EVERY image that gets optimized, regardless of whether the .webp version is smaller (most of the time it is, but not 100%). Then on the front side, EWWW would rewrite EVERY image url that matches a certain domain, usually this would be the special hostname/cname that you’re using for your CDN resources.

This does NOT mean that every user on your site will see webp images. It means that every user with a webp-supporting browser will see webp images for every image on your site (except background images, unless you rewrite the css yourself).

If you are reading this, and would like to see such a feature, add a +1 to this thread.

+1