LCP is high on mobile but image loads fast

[Антон Балагуров]

Hi 

I am experiencing a very strange LCP result in Google Page speed. In performance tab I see LCP is 1000ms but in Google page speed it is about 3600ms. LCP image loads fast and first in order in performance tab. Wondering to know why Google page speed shows so different results. I don't see same issue on the Desktop. Also I tried to remove all js and css from the page and left only critical css but no effect to LCP score. Please help to figure out what is wrong


I am using slow 4G and 4x slowdon for local testing

https://pagespeed.web.dev/analysis/https-staging-fillrite-com-12v-dc-15-gpm-fuel-transfer-pump/9n1k0ppe7j?form_factor=mobile

[Barry Pollard]

It looks to me like you're doing everything right to load the LCP image correctly. You're preloading it with a high fetchpriority and it's displayed right away.

<link rel="preload" fetchpriority="high" as="image" href="https://staging.fillrite.com/media/catalog/product/f/i/fill-rite-fr1204h-12v-fuel-transfer-pump-left-side-view.jpg?optimize=high&bg-color=255,255,255&fit=bounds&height=600&width=600&canvas=600:600">

And then you use it later with similar attributes:

<img alt="main product photo" class="gallery-placeholder__image" fetchpriority="high" src="https://staging.fillrite.com/media/catalog/product/f/i/fill-rite-fr1204h-12v-fuel-transfer-pump-left-side-view.jpg?optimize=high&bg-color=255,255,255&fit=bounds&height=600&width=600&canvas=600:600"/>

Now, technically you shouldn't need to preload it, if it's discovered in the HTML, but it can help if it's buried deep down in that HTML (which it appears to be here), or if it's not in the HTML at all (and added by JavaScript or CSS later).

However, it does look like there is a lot of JavaScript executing and I think this is the main issue you see when running it through PageSpeed Insights, as it uses quite constrained devices for mobile testing. You can see a TBT of 3.2 seconds.

Additionally, it looks like there's some sort of destructive hydration going on as the image element is replaced with this one in the DOM as seen in the elements panel:

<img src="https://staging.fillrite.com/media/catalog/product/f/i/fill-rite-fr1204h-12v-fuel-transfer-pump-left-side-view.jpg?optimize=high&amp;bg-color=255,255,255&amp;fit=bounds&amp;height=600&amp;width=600&amp;canvas=600:600" alt="12V DC 15 GPM Fuel Transfer Pump" class="fotorama__img" loading="lazy" aria-hidden="false" id="magnifier-item-0">

Notice how the fetchpriority="high" attribute no longer exists and instead it has loading="lazy"? This is typical of destructive hydration used by some JavaScript frameworks after the JavaScript has executed.

The browser therefore sees this as a new element and if it's slightly bigger than the old LCP element (even by a pixel), then it will be re-emitted as a later LCP. I can't reproduce it here, but it's possible that's what's happening on the Lighthouse test machine and there is a risk that it could also happen in real life. Now the user probably won't notice this (as it will remove the old LCP element, and replace it with the new one at the same time), but that's difficult to be sure as there could be a gap so the LCP metric will measure this as a new, later LCP time.

So I would concentrate on reducing the amount of JavaScript if possible, and also seeing if you can do some non-desctructive hydration to leave the original element in place. That should keep Lighthouse happy AND reduce the risk to user of both 1) seeing a later LCP image and 2) having a non-interactive page for so long.

Thanks,

Barry

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/ea76977f-c831-48d4-bed4-70ccd11450c1n%40googlegroups.com.

[Tony McCreath]

I was on the same track as Barry and the destructive hydration.

The performance tool does not highlight the LCP element, indicating it had been removed, and the network events indicate the image was loaded a few times. A suspected late loading relates to building the magnifier, which may be replacing the product's image code with a new set of magnifying code.

[Антон Балагуров]

I disabled all js and css and left only critical-css to avoid destructive hydration, but I still see high LCP

https://pagespeed.web.dev/analysis/https-staging-fillrite-com-12v-dc-15-gpm-fuel-transfer-pump/y5w40dxa8j?form_factor=mobile&hl=en

[Антон Балагуров]

On Monday, November 25, 2024 at 11:28:31 PM UTC+2 to...@websiteadvantage.com.au wrote:

[Антон Балагуров]

Hi Barry

I disabled js and css on the website to display LCP without high Total Blocking Time. As you can see, LCP is still high 3-4 seconds. Maybe you have any suggestion what  also can be done? If possible cloud you please take a look on this page, maybe you have any advice? Please keep url prams in url to get page without js and css

https://staging.fillrite.com/12v-dc-15-gpm-fuel-transfer-pump?dfsdf=sdfsdf
https://pagespeed.web.dev/analysis/https-staging-fillrite-com-12v-dc-15-gpm-fuel-transfer-pump/f3t5zbqhqb?hl=en&form_factor=mobile

On Tue, Nov 26, 2024 at 1:44 PM Barry Pollard <barryp...@google.com> wrote:

I'm seeing a lot of changing results here so suspect you're working on this site right now? That makes it difficult to advise here.

Let me know if you have any specific questions.

To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/7dd0c01b-d589-4a54-98c0-b135609a077dn%40googlegroups.com.

--

С уважением, 
Балагуров А. В.

[Barry Pollard]

I'm seeing a lot of changing results here so suspect you're working on this site right now? That makes it difficult to advise here.

Let me know if you have any specific questions.

On Tue, 26 Nov 2024 at 09:56, Антон Балагуров <anton.b...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/7dd0c01b-d589-4a54-98c0-b135609a077dn%40googlegroups.com.

[Антон Балагуров]

I removed all CSS styles but LCP is still 3.0 seconds. Next step I will try to reduce DOM size but it is so strange because as you mentioned you saw better LCP result on more complex pages

On Tue, Nov 26, 2024 at 5:53 PM Barry Pollard <barryp...@google.com> wrote:

I can't quite repeat that slow an LCP (even with 20x slowdown) but I do see a lot of style and layout causing a good bit of render delay. Here's an example with just a 6x slowdown on an M1 max:

I can't quite figure out why this is. The page is a little complex—hence why Lighthouse warns about an excessive DOM size but that's only a little over the 800 elements recommended so I'd be surprised if that was causing such an issue. I've definitely seen much more complex pages layout a lot quicker.

It would be worth trying to remove chunks of the page (or CSS) to see if you can narrow down while this is the case.

While on the subject of CSS, I've only had a brief look though it and with "Enable CSS Selector Stats" on but CSS like this could be improved:

            .catalog-product-view .product-info-right .fieldset .field.qty .control .increase-qty {
                box-shadow: none;
                border-color: #e9eef0;
                background: 0 0;
                border-radius: 0;
                width: 25px;
                height: 46px;
                padding: 5px;
                color: #ccc;
                border-left: none
            }

This requires every element with a class of increase-qty to check if it's a child of any element with a control class, which then requires checking if it's a child of any element with a field and qty class, which...etc. That's all very expensive to figure out for style and layout! Do you need all that, or could this be massivelt simplified to:

            .increase-qty {
                box-shadow: none;
                border-color: #e9eef0;
                background: 0 0;
                border-radius: 0;
                width: 25px;
                height: 46px;
                padding: 5px;
                color: #ccc;
                border-left: none
            }

And similarly for all other long class names. Overall I count over 6 and a half thousand lines of CSS (after pretty printing), which is quite a lot. And some of the rules are quite complex (like the above example). So I suspect that's the main reason for the long layout. It would be worth seeing if that could be simplified. Or even narrowed down to see which lines are causing the most issues (by experimenting with removing them and re-profiling).

Not sure if anyone else on the group has any better ideas to narrow this down?

[Barry Pollard]

[Антон Балагуров]

I reduced DOM size to ~ 600 elements, hided main image and run new test, I see that LCP is still on 3.0 seconds, LCP element now is <h1>. Now it looks like as a bug in LCP calculation. Do you know how PageSpeed calculates LCP and what can lead to high LCP time in this case?

https://pagespeed.web.dev/analysis/https-staging-fillrite-com-12v-dc-15-gpm-fuel-transfer-pump-html/f7kewiykr5?hl=en&form_factor=mobile

[Tony McCreath]

I did some cache busting tests (random query parameter) in the performance tool and noticed that the initial HTML took a long time to load. TTFB went from ~500ms to 3 seconds (4 x slowdown, fast 4G). I wonder if PSI is being a bit misleading and the real LCP issue is in the HTML loading time for new URLs.

A bit of a PSI hack: You could gather more debugging information and insert it into the H1 so you can see it in the PSI results. e.g. extra performance data.

[Barry Pollard]

I spent some time looking at this, and I agree PSI is being overly slow here.

There's still some things that could be faster (for example, there's a huge, blocking script for New Relic right at the top of the page that personally I'd move to the bottom of the page) but overall it seems PSI is being unrepresentatively slow.

It turns out when I checked in with the PSI team, that this issue has already been raised: https://github.com/GoogleChrome/lighthouse/issues/16201 and in the next PSI release, we'll be relaxing the throttling for PSI from the usual 4x slowdown to 1.5x or 1.2x which is a more representative and realistic slowdown based on the servers PSI seems to be running on.

Apologies if I sent you off on the wrong track originally. I'd not noticed that Lighthouse was quite that slow for LCP and I'm not sure if this regressed recently (I don't think it was always this way!). But either way it should be addressed soon. Hopefully it still gave you some clues for some other improvements so wasn't time completely mis spent!