2 images not converted to .webp on the home page
-
Hello,
On the home page of my site, there are 2 images that do not convert to .webp even though they are well located in the wp-content/uploads file.
This one, which is a banner that appears when I don’t put the image of an article forward (and on which is located the logo of the site, which is well converted to .webp)
=> https://i69.servimg.com/u/f69/11/39/41/06/imagif11.jpgAnd this one, which is the image of the highlighted article
=> https://i69.servimg.com/u/f69/11/39/41/06/imagif12.jpgThe other images, which are also in the wp-content/uploads directory, are well converted to .webp
Ex : => https://i69.servimg.com/u/f69/11/39/41/06/imagif13.jpgYet, the folder is 100% converted
=> https://i69.servimg.com/u/f69/11/39/41/06/imagif14.jpgI tried to disable the CDN (Amazon Cloudfront associated with Wp Rocket), Autoptimize too, but it doesn’t change anything.
Does anyone have a solution to this problem? These are the 2 heaviest images on the page that are not converted to .webp at the moment
Thank you in advance.
Best regards,
Kévin CAROL
The page I need help with: [log in to see the link]
-
Hi @kevinc81,
I have a couple suggestions based on what I can see. I would start by asking which option you are using for display of WebP images, <picture> tags or rewrite rules? I’m not entirely sure either would work, though, given other elements of you setup. I see that you are using a CDN (though I know you said you disabled for now) and that you are storing your images on a subdomain, https://cdn.karnoden.fr. I tried doing that on my test setup (storing and linking images from cdn.mydomain.com), and neither option would result in WebP images loading. I think for this to work properly, the images either need to be stored on the same domain as your main website installation (for the rewrite rules option), or (for the <picture> tag option) on your main website installation or on a Pull type CDN (and you need to enter the CDN URL in the Imagify options page).
I would also say if you use the <picture> tags option, then there is no way to get the 1st and 2nd images you linked to display in WebP format, because they are displayed as CSS backgrounds. The <picture> tag option replaces tags with <picture> tags and provides elements inside for both browsers that support WebP and those that don’t. There is no way this option can swap out CSS background images. Given you are planning to use a CDN, you can’t use the rewrite rules option, which limits solutions for these 1st two images you linked.
Another question I would ask is are you entering the following HTML manually?
<img width="455" height="341" src="https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min.jpg.webp" class="attachment-post-thumbnails size-post-thumbnails wp-post-image lazyloaded" alt="Hokkaido – Sapporo : Aper?u de la ville" title="Hokkaido – Sapporo : Aper?u de la ville" sizes="(max-width: 455px) 100vw, 455px" srcset="https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min.jpg.webp 455w,https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min-300x225.jpg.webp 300w" data-ll-status="loaded">
I ask this because I’ve never seen Imagify output something like that before, as they typically replace tags with <picture> tags that have <source> elements for WebP and a fallback tag for JPG or PNG when browser support requires it. I don’t believe the code I pasted above from your site will provide support for browsers without WebP capability, which according to https://caniuse.com/#feat=webp is about 20% of people (IE11-, iOS Safari, and Safari). I think the fact you’re using a subdomain may be preventing Imagify from replacing your image tags as <picture> tags, but even if that weren’t the case, you’d want to have your image tag with your src attribute pointing to the original JPG version of the image. Then Imagify takes care of formatting the <picture> element as needed to use WebP when possible, and JPG when not.
Hope I could at least provide some help. Let me know if I made any incorrect assumptions about your setup, and also if you have any questions about anything I posted.
Hello @joejoe04
First of all, thank you for your answer.
Here is my Imagify/Wp Rocket setup :
– https://i69.servimg.com/u/f69/11/39/41/06/imagif15.jpg
– https://i69.servimg.com/u/f69/11/39/41/06/imagif16.jpg
– https://i69.servimg.com/u/f69/11/39/41/06/imagif17.jpg
Since both Imagify and Wp Rocket detect the options enabled in either application, it’s either I choose the option on Imagify “display images in Webp format on the site” (with tags), or on Wp Rocket “enable caching for WebP”. I tried to use only Imagify for Webp, but the site behavior is exactly the same.The CDN is currently enabled, I disabled it for testing purposes only. Without CDN both images are not converted to Webp. Without CDN I used the option “use rewrite rules”, but without effect.
—-
For your other question, I don’t touch the html code of my page. The only addition that exists is the pixel facebook code in the header
Here’s what the code looks like when disabling conversion to Webp :
– https://i69.servimg.com/u/f69/11/39/41/06/imagif18.jpgIndeed, currently webp images are not displayed on IE11 and safari. It’s annoying on Safari.
Is there a good behavior to adopt to avoid this problem?Thank you very much for your help.
Best regards,
Kévin CAROL
Hi Kévin,
No problem at all, I’m happy to help if I can, and hopefully we can get you to an acceptable solution. I’m not sure you’re going to be able to get to 100% of your images being served as WebP if you are using both a CDN and CSS background images, being that the rewrite rules option is needed for CSS background images and rewrite rules are not compatible with CDNs.
I see that you tried disabling your CDN and using the rewrite rules, which did not work for you. I would ask though, did you try appending a query string to the background image URLs (like https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-anciens-bureaux-du-gouvernement-de-hokkaido-kevin-carol-min.jpg?test=123)? I ask because I know browser caching can really be stubborn in using images already cached (in this case the JPG version), even if you have the developer tools panel open with cache disabled, and you do an “Empty cache and hard reload.” Might be worth testing.
How were you testing whether the images were served as WebP? I ask this because when using the rewrite rules option, the image URLs will still show in the source code as though the JPG version is being linked to. To test if WebP images are loading for sure, you’d want to add a unique query string to the CSS background URLs (to prevent any caching issues like above), go to the “Network” tab in developer tools, and click the “Img” or “Images” tab, then reload. You should see your CSS background images in the list of images that show up, and the “Type” should show as webp, if it’s working properly. You may already know this, but figured I’d make sure.
I really can’t be sure what’s happening when you have the
<picture>
tags option enabled that would cause your<img>
tags to not be converted to<picture>
tags. Could have something to do with a LazyLoading option enabled, either through your theme or WP Rocket maybe? There could also be some issue with how your theme and Imagify are interacting. Sometimes, themes load the HTML after Imagify has already checked for<img>
tags (though I’m not sure that’s the case here because while no<picture>
element is created, the URLs are being changed from the JPG ones to the WebP ones, I assume by Imagify or WP Rocket).I can say, when I test similar code to yours in my test page:
<img width="455" height="341" src="https://mydomain.com/wp-content/uploads/2020/07/fireworks-01.jpg" class="lazyloaded" alt="test" title="test" sizes="(max-width: 455px) 100vw, 455px" srcset="https://mydomain.com/wp-content/uploads/2020/07/fireworks-01.jpg 455w, https://mydomain.com/wp-content/uploads/2020/07/fireworks-02.jpg 300w" data-ll-status="loaded">
I get the following output:
<picture> <source type="image/webp" srcset="https://mydomain.com/wp-content/uploads/fireworks-01s.jpg.webp?x=3737 455w, https://mydomain.com/wp-content/uploads/fireworks-02s.jpg.webp?x=3737 300w" sizes="(max-width: 455px) 100vw, 455px"> <img src="https://mydomain.com/wp-content/uploads/fireworks-01s.jpg?x73403&x=3737" sizes="(max-width: 455px) 100vw, 455px" srcset="https://mydomain.com/wp-content/uploads/fireworks-01s.jpg?x=3737 455w, https://mydomain.com/wp-content/uploads/fireworks-02s.jpg?x=3737 300w"> </picture>
This output uses the
<picture>
element to solve the issue you are having with the lack of support for Safari and IE11-, as the first<source>
element serves the WebP image for browsers that support it, while the<img>
element serves the JPG image for browsers like Safari and IE11-.However, when I try the same bit of code as above, only I change the URL so it’s linking to an image on a subdomain, like https://sub.mydomain.com/wp-content/uploads/fireworks-01s.jpg?x=3737, I get a similar output to what you currently get (No
<picture>
element), only my image URLs are not converted to the WebP versions and the JPG image is loaded. So I think possibly the fact that your image urls are not on your primary domain could be causing issues. I tried adding https://sub.mydomain.com to Imagify’s CDN URL specification field in options, and that didn’t help.I might try uploading a test image to your primary domain, https://karnoden.fr, making sure it’s optimized by Imagify and has a WebP version created, and then creating a test page with the same HTML code you are using for the images on your home page (only in this case, you’ll be linking to an image on your primary domain), to see if your
<img>
gets converted to a<picture>
element in that scenario, as is supposed to happen. If that works, then at least we’d know the subdomain is the issue.If that doesn’t work, and since you are using a CDN, what I would probably try next is to disable other plugins one by one, while also appending a unique query string to one of the images to break any caching issues, and then test refreshing the page to see if a
<picture>
element is created, as it is supposed to be. There could be some interaction between another plugin and Imagify that is causing issues. You could also try temporarily changing to a backup theme to see if<picture>
elements are then generated.Let me know what, if any, of this helps, and we can keep trying to get closer to a solution that works for you.
- This reply was modified 4 years, 4 months ago by James Huff.
- This reply was modified 4 years, 4 months ago by joejoe04.
- This reply was modified 4 years, 4 months ago by joejoe04.
Hello @joejoe04
Thank you very much for that complete answer. I’m not good at English but I think I understood
First, I activated the webp only in Imgaify, I checked in the source code and now the images are coded this way (except the 2 problematic images) : for example
<picture class="attachment-post-thumbnails size-post-thumbnails wp-post-image" title="Hokkaido – Sapporo : Anciens bureaux du gouvernement de Hokkaido"> <source type="image/webp" srcset="https://karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-anciens-bureaux-du-gouvernement-de-hokkaido-kevin-carol-455x341-min.jpg.webp 455w, https://karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-anciens-bureaux-du-gouvernement-de-hokkaido-kevin-carol-455x341-min-300x225.jpg.webp 300w" sizes="(max-width: 455px) 100vw, 455px"/> <img width="455" height="341" src="https://karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-anciens-bureaux-du-gouvernement-de-hokkaido-kevin-carol-455x341-min.jpg" alt="Hokkaido – Sapporo : Anciens bureaux du gouvernement de Hokkaido" srcset="https://karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-anciens-bureaux-du-gouvernement-de-hokkaido-kevin-carol-455x341-min.jpg 455w, https://karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-anciens-bureaux-du-gouvernement-de-hokkaido-kevin-carol-455x341-min-300x225.jpg 300w" sizes="(max-width: 455px) 100v
w, 455px”/>
</picture>`
I tried to load the page on Safari, the display looks fine.
=> https://i69.servimg.com/u/f69/11/39/41/06/imagif19.jpgAbout adding a query string, I tried several php code to add a query string test in url containing “.jpg” or “.png” only but I didn’t succeed. Do you know any php code for this?
I tried to disable everything: all the plugins, the lazyloading… The two images that don’t convert to .webp continue to be unconverted.
I’m okay to run tests with you, just tell me the procedure and I’ll do my best. Thank you for that.
I think I’ve taken into account everything you’ve described to me. If I’ve omitted anything, please don’t hesitate to tell me again
Best regards,
Kévin CAROL
<picture class="attachment-post-thumbnails size-post-thumbnails wp-post-image" title="Hokkaido – Sapporo : Aper?u de la ville"> <source type="image/webp" srcset="https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min.jpg.webp 455w, https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min-300x225.jpg.webp 300w" sizes="(max-width: 455px) 100vw, 455px"/> <img width="455" height="341" src="https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min.jpg" alt="Hokkaido – Sapporo : Aper?u de la ville" srcset="https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min.jpg 455w, https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-toyohira-gawa-kevin-carol-455x341-min-300x225.jpg 300w" sizes="(max-width: 455px) 100vw, 455px"/></picture>
- This reply was modified 4 years, 4 months ago by kevinc81.
Glad to hear you have gotten most of your images to load properly in WebP format!
Those last 2 images might be tough to load in WebP format though, since they are CSS background images. The rewrite rules option would work for both
<img>
tags in HTML and CSS background images, but since you are using a CDN, this is not an option.I noticed the CSS background images are being added inline in the HTML. Is your theme doing this via the customizer?:
<div class="image-slider clearfix rocket-lazyload lazyloaded" title="Hokkaido - Sapporo: Hokkaidō-jingū" style="height: 575px; background-image: url(https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-hokkaido-jingu-kevin-carol-min.jpg);" data-ll-status="loaded"><div class="container"></div>
If it is your theme doing this, you may want to contact the theme developer and request they add support for WebP with a fallback to JPG or PNG for browsers that don’t support it.
Given that all your other images are now loading properly as WebP, I don’t know that you need to do anything else with query strings, but I’ll explain what I’d do in case you need to test something out in the future. Wherever you are entering the image URL, just add a unique query string at the end. For example, if you were going to enter https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-hokkaido-jingu-kevin-carol-min.jpg, I would enter something like https://cdn.karnoden.fr/wp-content/uploads/2019/11/hokkaido-sapporo-hokkaido-jingu-kevin-carol-min.jpg?test=123. Then each time you want to test a change you made, just change that number to something new, and you’ll be sure you’re being served a non-cached image.
Hope this helps, and let me know if you have any other questions.
Hello @joejoe04
Thank you for your answer.
I’m pretty sure that’s the theme that makes the code like that. Without lazyload, wp-rocket and cdn the code is different of course but its structure is the same.
So I’m going to ask the authors of the theme and I’ll let you know.Thanks for the explanation on the query strings, I understood the interest!
Write you soon for the rest
Best regards,
Kévin CAROL
Hello @joejoe04
I’m sorry for the delay.
Here is the response from the creators of the theme.
I’ll take a look, but I don’t think I’ll venture into this kind of modification for only 2 images. The optimization of my site is already correct for me, I’m not sure that investing time in it is worth it!
@kevin-carol,
We are using inline background-image to display the slider post. Not sure if that is causing an issue. This theme was designed this way and we this theme is not tested with imagify plugin too. I just now came to know about .webp now only. I read all the reply from @joejoe04 also. We can’t do change this code in our theme for you if inline background image is creating an issue for this plugin. We designed this theme this way to display in background image and it has some reason to do so. Thousands of users will get an issue if it is removed from the lnline background. You can change the code if you wish to. I can show the direction where the code is from.
Goto theme folder > inc > settings > pixgraphy-settings.php on L151 and change your code according to your needs.If you are unable to do it then you need to hire someone to customize the code who can do it easily within 10-15 minute. Also to notify that we don’t have customize service recently.
Child Theme:
If you’re modifying a parent theme you didn’t build personally we recommend using a child theme. If you do that then updating to new version, all customized code will be lost.
Child Theme : https://codex.www.ads-software.com/Child_ThemesAlso you can download free child theme sample
https://themefreesia.com/theme-instruction/pixgraphy/#!/childtheme
Best Regards,
Daniel!Best regards,
Kévin CAROL
No problem about the delay, and I would agree, those kinds of modifications would not be worth it to me either. Glad we could at least get you to full optimization of images and display of most in WebP format.
Best of luck to you with your website!
- The topic ‘2 images not converted to .webp on the home page’ is closed to new replies.