the behaviour of previewing JPEG and WEBP images is very different on both Desktop and Mobile views. Is this expected behaviour?
JPEG’s render in preview mode as a full-scale image, whereas WEBP is not scaled and is rendered with vertical and horizontal sliders on the Desktop and a very small viewport on Mobile devices. In both cases the viewport is tiny and the user experience is horrible. See attached screenshots.
Given that Google and best practices across all platforms recommend utilising efficient image formats to improve FCP and LCP and thus search rankings, it’s becoming important to transition off JPEG and similar older image formats.
As it stands, in the latest version of Jevelin WEBP format is not acceptable for a production environment. Can you provide some indication if this part of the front-end UX is on the roadmap for improvement?
Thanks in advance.
I am just bumping my query as it’s been a few days and I have not received any feedback on this matter.
Just to confirm, are you referring only to the issues with the image lightbox/window?
We recently tested it on our testing website, and everything seemed to be working fine. Could you please let us know if you are using any plugins to add the webp functionality?
thank you for getting back to me.
The answer is no, I’m not converting JPEGs to WEBP. Simply uploaded a webp format image to the gallery and linked the image to the product. Attached are a screenshot of the page and image being rendered and a copy of the image being served.
Also, Link to the public product page – https://www.gkauthentic.com/product/gauvine-underwear-2011-second-skin-brief/
The behaviour is the same for all webp images only.
I have cleared both the WP Rock cache and the Cloudflare cache and disabled both temporarily, but it doesn’t change the behaviour.
It seems connected to the iframe within this div, If I change the height from 500px to 1200px the image displays outside of the div frame but does not scale to fit within the frame.
<div id=”lightcase-content”><div class=”lightcase-contentInner” style=”opacity: 1; width: 800px; height: 500px; max-width: 100%;”><iframe src=”https://www.gkauthentic.com/wp-content/uploads/2023/09/2011-gauvine-second-skin-brief-burgundy-front.webp” width=”800″ height=”500″ frameborder=”0″ style=”width: 800px; height: 500px; max-height: 1058px;”></iframe></div></div>
What behaviour do you experience on your end? Can you use the attached image to test and verify your environment is different?
That’s definitely an unusual issue. It sounds like it might be due to a plugin conflict. Could you try disabling your plugins one at a time to see if that resolves the problem?
Also, we suggest using plugins like WebP Express. They’re quite handy in situations where WebP might not be available or functioning properly in some browsers. The plugin would then automatically provide the JPEG version as a fallback.
That will take a while to achieve. I have no staging environment, unfortunately.
I have noted a separate issue, but I am unsure if I should raise a new request for this. It is related to updating the WP Bakery plugin via the facility provided within the theme Plugins section. I get the error as attached in the screenshot. Is this a known issue or something unique as well?
Are you using the latest theme version (5.8)? If not, then you can download it below and please try updating again.
Please login to access this file
Otherwise we can recommend disabling the WPBakery page builder before attempting to update it and trying again.
Let us know if that helps! 🙂
I’m running the latest 5.8 theme that has been published by you. I haven’t used a beta for a long while.
I followed your recommendation of updating WP bakery with poor results. Capture 1 shows the update failing prior to the WP-bakery plugin being disabled. Capture-2 shows the update status after the WP-Bakery plugin was disabled then the update carried out. However, returning to the plugins page (Capture-3) shows that the update did not take place, whats worse the WP bakery plugin then cannot be enabled again so half the website using this plugin for page layout becomes a mess on the front end. Not the best integration with this plugin. What’s worse you don’t know if you can rely on the feedback provided regarding the update status/outcome.
If it wasn’t for my All-in-One backup/restore solution I would be pretty messed up right now.
Before you suggest it is the WP Rocket plugin, I cleared the cache before and after the updates and disabled the plugin or one update attempt with the same outcome.
I was finally able to update the WPBakery plugin, but the successful method was different from your suggested options, which all failed due to a minimum version dependency of WPBakery required to be 7.1.x (in my case it was the previous major version 6.13.x). This dependency caused a failure loop, where the plugin would not update and be deactivated following attempts to do so. Also, if the plugin was deactivated first, then it will still fail to update and remain deactivated from that point on, causing display issues with pages built with WPBakery.
The successful method was to deactivate + delete the WPBakery plugin from the site! Then, reinstall the Beta Theme version which reinstalls WP Bakery at the required 7.1.x version, after which the plugin can be reactivated and the WPBakery-built pages are then restored to their configured state.
In doing so I also noted the following:
1.) Woo Template Thank you.php is out of date (v 3.7.0) – the current version is 8.1.0.
2.) WPBakery is already at v7.2 – The Jevelin Theme version 5.8 is at WP Bakery v7.1.
May I request, please, to include the updated versions of the highlighted items in the next theme release?
That is great!
Sure, thank you for letting us know. We will add those fixes in the next theme update.
thank you. I do appreciate the support.
Coming back to the original issue I raised within this request, I have now installed a copy on a staging instance, allowing me some flexibility to test.
I have disabled ALL plugins apart from WooCommerce, but the behavior of the WEBP images remains unchanged in preview mode. You previously suggested that the reported behavior is likely due to a plug-in compatibility/interference-related problem. I can prove now that this is a red herring.
I switched the Theme to Avada (same with all but WooCommerce enabled) and the rendering of the webp image in preview mode is scaled within the viewport and the preview frame is not rendering a zoomed-in image requiring slide bars to scroll to view…
Please see the attached evidence and examples.
I’m not sure what the solution is here, but surely this proves that it is not a plugin-related issue?
that’s a negative.
The image you have tested is a JPG, the issue resides with WEBP format images.
You will see a combination, images with the background removed have been photoshopped and exported in JPG format (originally in WEBP), and images with background have been imported in the native format they were received (WEBP). The images with the background do not scale down or resize to fit within the preview window bounds. This is my issue.
I’m currently forced to going through a process to Photoshop and convert WEBP images to JPG, but this is a backward step for which I will also pay with SEO penalties compared to similar websites employing WEBP images, as well as suffer with the UX in terms of speed and page load.