Support » Plugin: EWWW Image Optimizer » WebP + WP Offload (S3 + Cloudfront)

  • Resolved Will Stocks

    (@willstockstech)


    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

    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 to see the link]

Viewing 15 replies - 1 through 15 (of 16 total)
  • Will Stocks

    (@willstockstech)

    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 nosilver4u

    (@nosilver4u)

    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.

    Will Stocks

    (@willstockstech)

    Thanks @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.co.uk

    In terms of the appending via PHP, my latest plan was to also include a WebP polyfill (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 4 weeks ago by  Will Stocks. Reason: code block
    • This reply was modified 4 weeks ago by  Will Stocks. Reason: regex had erroneous /m modifier
    Plugin Author nosilver4u

    (@nosilver4u)

    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.

    Will Stocks

    (@willstockstech)

    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 nosilver4u

    (@nosilver4u)

    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

    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.

    Will Stocks

    (@willstockstech)

    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 4 weeks ago by  Will Stocks.
    Plugin Author nosilver4u

    (@nosilver4u)

    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.

    Will Stocks

    (@willstockstech)

    It looks like it’s working now!! 🙂 Thank you @nosilver4u

    One edge case though. If you take a look at my sidebar and footer, I have a <picture> 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 <img> tag is being rewritten.

    Actual markup (backend)

    <picture class="lazyload sidebar-ad">
    	<source type="image/webp" media="(max-width: 320px)" srcset="https://cdn.willstocks.com/wp-content/uploads/affiliate/cloudways/Cloudways-WillStocksSidebar-Mobile-Small.webp">
    	<source type="image/jpeg" media="(max-width: 320px)" srcset="https://cdn.willstocks.com/wp-content/uploads/affiliate/cloudways/Cloudways-WillStocksSidebar-Mobile-Small.jpg">
    	<source type="image/webp" media="(max-width: 770px)" srcset="https://cdn.willstocks.com/wp-content/uploads/affiliate/cloudways/Cloudways-WillStocksSidebar-Mobile-Large.webp">
    	<source type="image/jpeg" media="(max-width: 770px)" srcset="https://cdn.willstocks.com/wp-content/uploads/affiliate/cloudways/Cloudways-WillStocksSidebar-Mobile-Large.jpg">
    	<source type="image/webp" media="(min-width: 771px)" srcset="https://cdn.willstocks.com/wp-content/uploads/affiliate/cloudways/Cloudways-WillStocksSidebar-Non-Mobile.webp">
    	<source type="image/jpeg" media="(min-width: 771px)" srcset="https://cdn.willstocks.com/wp-content/uploads/affiliate/cloudways/Cloudways-WillStocksSidebar-Non-Mobile.jpg">
    	<img class="lazyload sidebar-ad" src="https://cdn.willstocks.com/wp-content/uploads/affiliate/cloudways/Cloudways-WillStocksSidebar-Non-Mobile.jpg" alt="Load your WordPress site fast, using Cloudways">
    </picture>

    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 nosilver4u

    (@nosilver4u)

    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

    • This reply was modified 4 weeks ago by  nosilver4u. Reason: added Github issue for tracking
    Will Stocks

    (@willstockstech)

    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 <picture> 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 4 weeks ago by  Will Stocks.
    Plugin Author nosilver4u

    (@nosilver4u)

    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

    Will Stocks

    (@willstockstech)

    I will give that a go shortly, thanks @nosilver4u 🙂

    Will Stocks

    (@willstockstech)

    Can confirm – working per deploying the animated gif fix as well 🙂

    Will Stocks

    (@willstockstech)

    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)
  • You must be logged in to reply to this topic.