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?
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.
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 6 years, 9 months ago by
Will Stocks. Reason: code block
-
This reply was modified 6 years, 9 months ago by Will Stocks. Reason: regex had erroneous /m modifier
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.
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)
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.
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, 9 months ago by Will Stocks.
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.
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:
- Safari doesn’t support webp, so it shouldn’t be converting those image tags?
- 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!
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 6 years, 9 months ago by
Shane Bishop. Reason: added Github issue for tracking
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 6 years, 9 months ago by Will Stocks.
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
I will give that a go shortly, thanks @nosilver4u 🙂
Can confirm – working per deploying the animated gif fix as well 🙂
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?
