As i am not expert on these things I will quote what Brian at Perfmatters has said on the matter:
In your HTML, Bricks is loading all of the WooCommerce gallery code below all the sidebar and product description. The gallery code really should be first in the HTML order. That’s how it is on a stock WooCommerce site.
I’m not sure there is anything we can do on our end unfortunately, as we simply grab what your theme or page builder is doing and then preload that. In this case, it appears that something with Bricks is causing the wrong LCP image to be tagged, and that is essentially flowing into our tool as well.
And without the proper LCP image preloaded, it loads way further down in the waterfall (load order).
I would reach out to Bricks and ask this:
Why is Google flagging the zoomed in product image as the LCP element? It should be the first image in the gallery.
Why is all the WooCommerce gallery code further down in the HTML after the sidebar and product description?
Feel free to forward them the entire email above if that is helpful. I realize that this is a little technical, but wanted to at least put all the information we discovered in one place. We spent quite a bit of time researching and trying a few things, but ultimately, the two points above are what is causing our preload feature not to work properly, and it’s not how WooCommerce out of the box works either. We work with a lot of WooCommerce sites and usually never have an issue preloading the LCP image in the gallery.
We’re wondering if perhaps Bricks changed something recently as we don’t remember that happening in the past.
…
Currently t is impossible to pass CWV due to the LCP created.
Would you be so kind as to provide a live link and a screencast using https://jam.dev showing and explaining the issue and your setup? Then, we can try to reproduce the problem. Thanks in advance!
Hi timmse,
As I mentioned in my initial post, this situation is outside my expertise, so I’m not sure that making a video would be helpful since I don’t fully understand the topic. However, I have a detailed email from Brian at Perfmatters, and he has given me permission to share it with you. I believe it contains all the information and links you need. Could you provide an email address where I can forward the Perfmatters email?
Thanks Mark
Hi Mark,
You have already sent us an email, but the content is identical to your report here and, unfortunately, does not contain any links or additional information.
You are welcome to send us your entire email history about this issue including access data to your website (so we can see/understand the problem) to help@bricksbuilder.io. We will be happy to look at it in detail.
Okay, let me start again.
On our website all our product pages based on a single product template have had recent a spike in the LCP score up to around 3.0. Previously, the score has been about 2.0 to 2.3. We raised the issue with Perfmatters, who reported that there were some minor DOM issues that needed attention, but the main issue appeared to be some Bricks code. I have just sent the email again to help@… to be sure you have it. However, it can be summed up in what Perfmatters advised us to ask you,:
I would reach out to Bricks and ask this:
Why is Google flagging the zoomed in product image as the LCP element? It should be the first image in the gallery.
Why is all the WooCommerce gallery code further down in the HTML after the sidebar and product description?
Subsequently we have addressed the HTML issue, ( on our staging site, but it had no impact on the high LCP score ) and asked the guys at Perfmatters to take another look. I have sent a second email to help@… which is Perfmatters response.
I am happy to give access to the staging site if you need that.
I would appreciate any advice you can offer. As i am not an expert in any of these matters, I thought quoting the guys at perfmatters might assist you in a more efficient manner than I can.
This was due to how it was implemented on your live site. The grid container holding the product gallery had order: -1 applied, which changed the visual and DOM order. I initially thought this might be the cause, as the Perfmatters team suggested, but on your staging site, that styling doesn’t exist. The HTML markup order is correct there, matching the visual layout, yet the same issue with Google detecting the thumbnail image as the LCP element exists.
I’m not entirely sure why this is happening. After some debugging, I was able to replicate the same issue locally using our Product Gallery element. Interestingly, when switching to a default WordPress theme, the issue disappears, and Lighthouse correctly identifies the main gallery image as the LCP element, not the thumbnail.
This suggests there’s likely an issue on our side that we’ll need to investigate further and fix. I’ve added this to our internal bug tracker to look into it in more detail.
After further digging, although the behavior of Lighthouse flagging the thumbnail as the LCP element (instead of the main gallery image) is something I’ve only been able to replicate with Bricks. When switching to a default WordPress theme, Lighthouse identifies a different element (not the main image either) as the LCP element.
However, the main issue here isn’t which element is flagged as LCP but the high LCP time itself. This appears to be a WooCommerce-related issue rather than a Bricks issue. For example, when testing locally:
Using the Twenty Twenty-Five theme with a default WooCommerce product template, the LCP time is around ~6.5s.
Switching to Bricks with a default product template, the LCP time is around ~5.2s.
While results may vary depending on the setup and neither result is ideal, this suggests the root cause lies with WooCommerce.
As for the markup question from Perfmatters, as I shared in my previous response: the styling causing the gallery to appear out of order isn’t default Bricks behavior, it was custom-added on your live site. On your staging site, where the markup matches the visual layout, this issue is resolved. Hopefully, this adjustment will help Perfmatters optimize the LCP further once the correct image is detected.
Let me know if you have further questions or if Perfmatters shares additional insights!