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.).

[Vipul Nema]

Hi Team,

Thanks for the clarification on the LCP limitations of the web-vitals library and the distinctions between real-user and lab data.

My findings from using lab tools like Lighthouse and the Chrome DevTools Performance panel also  consistently show that my site's main heading is the LCP, not the ads loaded within third-party iframes. Are these tools  also are designed to ignore content within cross-origin iframes like JS based API?
example URL - 

This raises a final, important question for us.

does this mean In case  News website consist of Ads in first viewport, there  LCP score in CrUX is likely to be worse (higher) than the LCP scores I am getting from my Lighthouse reports, chrome performance panel and RUM tools ?

[Barry Pollard]

Are these tools  also are designed to ignore content within cross-origin iframes like JS based API?

These tools are not "designed" to ignore content within cross-origin iframes, but it is an extra complication they do not currently measure. Ideally they would be, but there are complications involved in including these.

does this mean In case  News website consist of Ads in first viewport, there  LCP score in CrUX is likely to be worse (higher) than the LCP scores I am getting from my Lighthouse reports, chrome performance panel and RUM tools ?

Yes, this is possible. But it really depends on the page and how it uses cross-origin iframes.

Now you've given an actual example page, I can provide more details:

• This page loads a full-viewport add a few seconds after page load. Because of that it is a risk to become the LCP if the user has not interacted before then, depending on the content of the ads and if they are bigger than the other content.
• It also depends if there is any user interaction (click, scroll..etc.) before the ad shows as that would lock the LCP to the largest element before then.
• You can use the chrome://ukm URL to see exactly what is sent to Chrome. In some cases I see this:

Which states that the CrossSiteSubFrame LCP time (1878) became the LCP for the page.

• But I'm also seeing cases like this:

Which suggests the LCP in the iframe was NOT chosen as the page LCP and the quicker 526 time was chosen as the overall LCP (either because none of the content of the ad was larger than the pages LCP, or because an interaction happened to freeze the LCP before the ad showed).

• Now let's see if we can fugure out what most of your users are seeing. If you look at the LCP subparts using a tool like CrUXVis we can see this:

Now it's important to note that these subparts are only available for image LCPs, but this shows that there was a large delay of 4 seconds after page started loading before that LCP image was found. That long delay strongly suggests it was due to the late content showing well after page load (for example the ad popping up).

So yes all this suggests that late-loading ads probably are causing the larger LCP times you see in CrUX.

Which then leaves a few new questions:

• Is the CrUX LCP the accurate LCP? By the definition of LCP yes it is. This is the largest content shown to the user. However, is it representative of when the page is loaded? Well that's much more subjective. The page content IS available much earlier. But then a full-screen pop-up covers all that content later. So it's arguable when the "page is loaded" and I can see arguments for both of these times. But as I say, from a pure definition of what LCP is designed to measure it's correct. Either way, while full-screen ads may be good for revenue, it is "bad UX" for the user. So this is a choice the site owner needs to make if that additional revenue is worth it despite the user annoyance and how it's difficult to measure LCP in tooling.
• Is it "fair" that the later LCP time is used? Well as per above explanation, that is the accurate LCP.
• What can you do about it? The first option is to do nothing and accept this trade off has been made and not being able to measure LCP easily is part of that trade off. You also understand this now and do have a measure of this in CrUX (as well as a measure of the non-ad LCP in RUM). The other option is to move to different ad options (e.g. ads embedded in the page, ads only showing on interaction, ads only shown below the fold), while ensuring the real content is the LCP. But there are likely revenue consequences to those choices as users may interact with the ads less. Experimenting and measuring different options would be advised.
• Should Web Performance Tooling measure this situation better to match CrUX? Ideally yes! But there are complications from privacy and security issues (which are difficult to overcome), to complexity in tooling and prioritisation within tooling teams (Lighthouse, DevTools...etc). This lack of cross-frame Core Web Vitals metric is something we've been aware of since the launch of Core Web Vitals but has so far not been prioritised to to improve this (in large part because of the complexity needed to accurately include these).

All that may not be the answer you're looking for, but hopefully helps you understand the issue more.

Barry

[Vipul Nema]

Thanks Barry,

Thanks again — the information you shared was very helpful. The chrome://ukm URL, in particular, was really insightful.

Could you also share more documentation or details on the different properties shown there? For example, I noticed PaintTiming.LargestContentfulPaintIsCrossOrigin = 0. Does this indicate that the LCP image is from a first-party source or 3rd party ads.

Appreciate your guidance.

--

Regards,
Vipul Nema

[Barry Pollard]

Unfortunately that field is not reliable, at least for videos - see this bug: https://crbug.com/401210847

So I tend to just look at the timings in the fields I shared previously.

The other useful one is LargestContentfulPaintType. Which you can see how to decode in that bug.