Title: WebP + WP Offload (S3 + Cloudfront) Last modified: August 20, 2019 --- # WebP + WP Offload (S3 + Cloudfront) * Resolved [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/) * Hello! * I have just setup and bulk converted all of my images to .webp’s (I can see them all in my S3 bucket). I am using WP Offload to upload media to S3 and I’m using Cloudfront as the CDN to serve the images. I also use lazysizes `data-srcset` + LQIP. * However, all of my images are still being served as .jpeg/.jpg/.png – none of them are being served as .webp. * I followed the instructions on this page: [https://docs.ewww.io/article/16-ewww-io-and-webp-images](https://docs.ewww.io/article/16-ewww-io-and-webp-images) * My settings for WebP are as follows: webp conversion: on forced webp: on webp paths: cdn.willstocks.com alt webp rewriting: on * Is there any way I can handle the appending of the .webp extension in PHP as opposed to relying on client-side JS? I appreciate this has some incompatibility issues with older browsers/Safari, but I’m OK with that at the moment. * I have noticed that _only_ my sidebar ads are being converted… but they are already. webp so are currently breaking (I can fix that myself) * The page I need help with: _[[log in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fwebp-wp-offload-s3-cloudfront%2F%3Foutput_format%3Dmd&locale=en_US) to see the link]_ Viewing 15 replies - 1 through 15 (of 16 total) 1 [2](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/page/2/?output_format=md) [→](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/page/2/?output_format=md) * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11848682) * I have also just noticed that it is handling my logo… so my sidebar, footer and logo are the only three images being affected. All three of these images sit outside of the_content? No images within the_content/post content is being affected for some reason? * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11849677) * With that setup, all images in the entire page should be replaced by JS WebP so long as the URLs match either your “home url” or cdn.willstocks.com At this point, it doesn’t look like JS WebP is active on your page, so not much further that I can speculate on why it isn’t working correctly. * As for appending .webp with PHP, that’s never something we’re going to advocate, since 20% of users would be missing your images. But you’re free to do it yourself, it’s not terribly complicated, especially if you’ve already managed to implement lazysizes yourself. * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11849907) * Thanks [@nosilver4u](https://wordpress.org/support/users/nosilver4u/) – And apologies, I have just re-enabled JS WebP now. It is running on my site so you can see the current status. Please also note I tweaked my CDN URLs listing to try and get it to work… it now has the following listed: cdn.willstocks.co.uk cdn.willstocks. com [https://cdn.willstocks.com/](https://cdn.willstocks.com/) [https://cdn.willstocks.co.uk](https://cdn.willstocks.co.uk) * In terms of the appending via PHP, my latest plan was to also include a WebP polyfill ([https://webpjs.appspot.com/](https://webpjs.appspot.com/)) so that all visitors would see the .webp version without an issue. * I attempted to do a cheeky: * `$content = preg_replace( '/(?<=["\'])[^"\']+?\.(?:jpe?g|png|gif)(?=["\'])/',' ${0}.webp', $content );` * But it doesn’t seem to like that, lol! Regex is a dark art and not one I’m all too well skilled in! I was fortunate in that 95% of the lazysizes implementation came as part of the theme I am using. * Do you want/need the full debug listing? - This reply was modified 6 years, 10 months ago by [Will Stocks](https://wordpress.org/support/users/willstockstech/). Reason: code block - This reply was modified 6 years, 10 months ago by [Will Stocks](https://wordpress.org/support/users/willstockstech/). Reason: regex had erroneous /m modifier * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11850038) * Ah, now I see why it isn’t parsing those images, it’s because they don’t have a data-src attribute. I presume that’s because of the way LQIP was implemented when a srcset is present. The parser only supports lazy loaders that use lazysizes with a data-src attribute at this time, so if there’s a way to implement that with your theme, that will work with JS WebP. Alternatively, you can just use our lazy loader (on the ExactDN tab), and it will work just fine. * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11850055) * I believe it is implemented that way to cater for WP’s responsive image sizing?` data-srcset` is fairy standard for lazysizes as far as I’m aware, for responsive images? * I will speak to the theme devs to understand more around the `data-src` vs `data- srcset` implementation and potential impact of changing. * Will `data-srcset` be supported at some point? * Is there also a reason that the image `src` isn’t being rewritten to `.webp` as I would’ve expected that to as well (although I can handle that one easily myself, just thought it was weird) * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11850094) * The data-srcset will be parsed automatically if a data-src attribute is present. In both of the implementations that we officially support, both a data-src and data-srcset are present on lazyloaded images. It is unlikely that we’ll change that in the near future, see the bit about 3rd-party compatibility at [https://docs.ewww.io/article/74-lazy-load](https://docs.ewww.io/article/74-lazy-load) * As for the src not being rewritten to .webp, that’s because (in this case) it’s expected to be a placeholder image which generally wouldn’t have a .webp alternative, as it needs to load on all browsers. * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11850104) * Ahhh OK cool, so in theory if I add a `data-src` attribute as well as my existing markup, I will be all good in terms of parsing and rewriting to WebP? * The JS WebP implementation isn’t a polyfill either is it. It’s “simply” (not simple, I know!) serving WebP to supported browsers and the jpeg/png to non-supported? - This reply was modified 6 years, 10 months ago by [Will Stocks](https://wordpress.org/support/users/willstockstech/). * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11850123) * Adding the data-src should sort things out with JS WebP. And it’s not a polyfill no, it’s much smaller since “all” it’s doing is detecting WebP support by the browser and then loading whichever image the browser supports (JPG/PNG vs. WebP). As you acknowledged, even that isn’t as simple as we like, what with folks loading content and images in a ton of different ways, including JS/AJAX requests. * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11850342) * It looks like it’s working now!! 🙂 Thank you [@nosilver4u](https://wordpress.org/support/users/nosilver4u/) * One edge case though. If you take a look at my sidebar and footer, I have a ` ` element with webp sources and a fallback jpeg. However, in Safari on my MacBook and iPhone, I’m not seeing those pictures load. When I check the console in those browsers, I’m seeing that the fallback `` tag is being rewritten. * Actual markup (backend) * ``` Load your WordPress site fast, using Cloudways ``` * Frontend (JS WebP): [Error] Failed to load resource: the server responded with a status of 403 () (Cloudways-WillStocksFooter-Desktop-Large.jpg.webp, line 0)[ Error] Failed to load resource: the server responded with a status of 403 () ( Cloudways-WillStocksSidebar-Non-Mobile.jpg.webp, line 0) [Error] Failed to load resource: the server responded with a status of 403 () (Cloudways-WillStocksSidebar- Non-Mobile.jpg.webp, line 0) * (Safari’s element browser shows that the element is still intact… but the console error disagrees!) * There are two issues here: 1. Safari doesn’t support webp, so it shouldn’t be converting those image tags? 2. If an image already has a .webp file extension, JS WebP is still appending . webp instead of respecting the existing extension? So when in Chrome (or any other browser), I’m not actually seeing these elements due to the extra .webp being appended. I can quick fix this by only having the .jpg listed and leaving JS WebP to do its thing, but thought I’d mention it! * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11850398) * Hmm, yeah, we should make sure that if a picture element already has image/webp sources that we aren’t mangling it. You could definitely just leave the jpeg sources and remove the webp ones and it’ll probably work, but we definitely should see if we can avoid mangling those incorrectly. * You can track the issue at [https://github.com/nosilver4u/ewww-image-optimizer/issues/125](https://github.com/nosilver4u/ewww-image-optimizer/issues/125) - This reply was modified 6 years, 10 months ago by [Shane Bishop](https://wordpress.org/support/users/nosilver4u/). Reason: added Github issue for tracking * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11850421) * I’ve implemented a little work around in S3 to bypass this for now 🙂 * I have a .webp file, a .webp.webp, a .jpg and a .jpg.webp 🙂 * That being said… for some reason, Safari is adamant about loading the .jpg.webp, even though that is not the markup 🙁 * Fortunately, my Safari traffic is fairly minimal… but it’s still a little annoying as I can’t work out why! haha * It’s so weird… every other image element is working perfectly now… but for some reason, in Safari, that `` element is behaving weirdly and trying to request the .webp version of the .jpg even though it’s not browser supported… - This reply was modified 6 years, 10 months ago by [Will Stocks](https://wordpress.org/support/users/willstockstech/). * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11851509) * Looking at one of the picture elements, it seems some of the WebP images have 2 type attributes, one is image/jpeg, the other is image/webp. So I think that’s probably the issue there. * You can grab the fixed code from GitHub: [https://docs.ewww.io/article/73-update-from-github](https://docs.ewww.io/article/73-update-from-github) * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11852057) * I will give that a go shortly, thanks [@nosilver4u](https://wordpress.org/support/users/nosilver4u/) 🙂 * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11863399) * Can confirm – working per deploying the animated gif fix as well 🙂 * Thread Starter [Will Stocks](https://wordpress.org/support/users/willstockstech/) * (@willstockstech) * [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/#post-11863416) * The GitHub deploy is a manual deploy isn’t it – it won’t get updates via wp-admin now? If I just wait for the next full release and re-install via wp-admin I’ll be all sorted moving forwards? Or will the GitHub release also be covered by wp-admin plugin updates? Viewing 15 replies - 1 through 15 (of 16 total) 1 [2](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/page/2/?output_format=md) [→](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/page/2/?output_format=md) The topic ‘WebP + WP Offload (S3 + Cloudfront)’ is closed to new replies. * ![](https://ps.w.org/ewww-image-optimizer/assets/icon-256x256.png?rev=1582276) * [EWWW Image Optimizer](https://wordpress.org/plugins/ewww-image-optimizer/) * [Frequently Asked Questions](https://wordpress.org/plugins/ewww-image-optimizer/#faq) * [Support Threads](https://wordpress.org/support/plugin/ewww-image-optimizer/) * [Active Topics](https://wordpress.org/support/plugin/ewww-image-optimizer/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/ewww-image-optimizer/unresolved/) * [Reviews](https://wordpress.org/support/plugin/ewww-image-optimizer/reviews/) ## Tags * [webp](https://wordpress.org/support/topic-tag/webp/) * 16 replies * 2 participants * Last reply from: [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * Last activity: [6 years, 10 months ago](https://wordpress.org/support/topic/webp-wp-offload-s3-cloudfront/page/2/#post-11863707) * Status: resolved