Showing Wrong Largest Contentful Paint (LCP) resource type

[Vipul Nema]

RUM data through google core web vital JS library and crux data for Largest Contentful Paint (LCP) resource type have large difference  .  Example crux shows more then 20% LCP as image whereas  RUM data shows less then 2%. 

Issue worse even more for APM pages where RUM script not able to provide such details. 

[Barry Pollard]

There’s not a lot of detail to go in that message but this article explains why you can see differences in these numbers:

https://web.dev/articles/crux-and-rum-differences

One reason could be third-party content in iframes. For example, YouTube embeds. If that’s the largest piece of content then CrUX will see this but, due to web security restrictions, JavaScript API calls used by RUM tools cannot and may fallback to a different, smaller, LCP like the heading.

Barry

On Wed 10 Sep 2025 at 10:46, Vipul Nema <vipuln...@gmail.com> wrote:

RUM data through google core web vital JS library and crux data for Largest Contentful Paint (LCP) resource type have large difference  .  Example crux shows more then 20% LCP as image whereas  RUM data shows less then 2%. 

Issue worse even more for APM pages where RUM script not able to provide such details. 

--
You received this message because you are subscribed to the Google Groups "Chrome UX Report (Discussions)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ux-repo...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ux-report/46413c14-8c09-4db8-8129-f6a76691e377n%40chromium.org.

[Vipul Nema]

Thanks for your reply. This doc was very helpful the understand the differences .

The discrepancy you mentioned is a significant challenge specially for news domain companies where a lot of 3rd party domains  like Ads rendered in iframes  . It's difficult to get buy-in from stakeholders like SEO and Product when our local tools can't reproduce the issues showing up in CrUX.

We need a reliable way to accurately measure the LCP of third-party content. Do you have any recommendations for a debugging approach or tools to help us bridge this gap?

[Barry Pollard]

As discussed in the web-vitals library limitations it is possible for iframes to measure their own LCP and beacon this back to the main iframe to report this as the LCP. However, this is quite tricky to implement accurately. However, it's unlikely you have access to third-party iframes to make such changes on that side.

You can also use lab tools (particularly with film strips) to look at individual pages to understand differences.

But basically this is one of the limitations of JavaScript APIs. Ideally third-party content being the largest content on the page is not as common as first-party content. LCP is a proxy for when the page "feels ready" to the user. Using the largest piece of content is usually a good proxy for that. However if in many cases that is ads, it's questionable whether that represents the page feeling loaded—do users come to see the ads? Or the content? Should the ads be the largest piece of above-the-fold content?

Videos may be more of an understandable use case and if most pages on your site are used to display large videos, then you may wish to consider alternatives to allow these to be measured more accurately (self-hosting, proxying them via an iframe in your control...etc.).