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.