The hero video is your Largest Contentful Paint, and the default embed weighs 1,149 kB

Poster or first frame, whichever is earlier, and 3 per cent of video elements have a poster

Chromium's changelog for the change is blunter than web.dev about what it replaced: videos had previously been ignored for LCP unless they had a poster image, and after it a video element can become an LCP candidate exactly like an image. Pages with large auto-playing videos should start seeing that video used as the LCP element, it says, and scores may improve or regress depending on what element is currently being chosen. Chrome began shipping it to users roughly 22 August 2023, rolled out to existing Chrome 116 installs over 14 days.

Now put the Web Almanac's numbers against it. In the June 2024 crawl the poster attribute was present on 3 per cent of video elements. Autoplay was on 23 per cent, playsinline on 14. So for most video elements on the web there is no poster to load, which leaves the first frame presentation as the only timestamp available, and a first frame is only presented without an interaction when the video autoplays. A hero video that autoplays muted and inline is exactly the case where the metric stops waiting on one image file and starts waiting on video bytes.

A small population, walking into a room built for images. A video element appears on 6.7 per cent of mobile pages and 7.7 per cent of desktop pages, and in the July 2025 crawl the LCP content type was an image on 76.0 per cent of mobile pages and 85.3 per cent of desktop ones. The advice written for that room, preload the hero image and size it properly, is not wrong. It just does not describe the element you put there.

The poster attribute is on 3 per cent of video elements. For the other 97, the metric is waiting on video bytes.

Three reference documents define this metric and only one of them mentions the first frame

web.dev says poster or first frame, whichever is earlier. MDN's page for the LargestContentfulPaint interface lists what counts as contentful and gives video exactly one line: the poster images of video elements. Not the first frame. Nearly three years after Chrome 116 shipped.

The W3C editor's draft is stranger. The words poster, animated and first frame do not occur in it at all, and the word video occurs once, inside an array of tag names belonging to the specification's own tooling script. Its processing model handles painted images and painted text nodes and nothing else. web.dev attributes the video rule to the Largest Contentful Paint API. The document defining that API does not contain it, and the rule everybody quotes lives in a Chromium metrics changelog.

The draft is candid about why this is hard, in a non-normative Limitations section: the API is based on heuristics, and as such, it is error prone. The changelog adds the caveat that matters more. At launch, the change only affected UKM and so CrUX reporting of LCP, and did not affect PerformanceObserver observations as measured in JavaScript. Read that twice. It moved the number Google collects and left the number your own page reads alone.

One default embed carries 971 kB of JavaScript, and the median mobile home page ships 632 KB of it

Zach Leatherman measured one default YouTube embed on one video on 11 December 2023 and published the breakdown: 1,149 kB of compressed wire weight, of which 971 kB JavaScript, 61 kB for a 1280x720 JPEG poster, 48 kB of CSS, 41 kB of iframed HTML and 28 kB for three Roboto web fonts. Those five account for the total exactly. And, in his words, this conspicuously does not include any preloading of video content.

Set it beside the page it lands on. The Web Almanac's 2025 page weight chapter, drawn from the July 2025 crawl of 15,426,398 mobile websites, puts the median mobile home page at 632 KB of JavaScript, 911 KB of images, 122 KB of fonts, 77 KB of CSS and 22 KB of HTML. One embed brings one and a half times the entire script budget of that median page. It also does not amortise: resources are not shared, so two embeds weighed 2.4 MB and three weighed 3.6 MB.

The facade version of the same video weighed 31 kB, being 6 kB of JavaScript, 3 kB of CSS and a 22 kB poster, with nothing iframed until the click. A reduction of 1,149 kB to 31 kB. That is a better argument than the one usually made for it: the lite-youtube-embed README claims the element renders approximately 224x faster, and that figure carries no method, no unit and no denominator. Its supporting evidence is six screenshots whose filenames all begin Screen Shot 2019-11-03. Quote the two weights instead.

CrUX measures inside the embed and your RUM tool cannot

A top level page has no access to content inside an iframe, not even a same-origin one, so performance metrics for that content can only be measured by the iframe itself. That is a security rule, and it applies to every analytics vendor equally. CrUX is measured by the Chrome browser rather than by JavaScript on the page, so it has no such limit and does report metrics from inside iframes. web.dev names this exact case: an autoplaying, playsinline video element's first painted frame can count as an LCP candidate, and embeds for popular video streaming services may put that element in an iframe.

On 10 September 2025 Vipul Nema posted the consequence to the Chrome UX Report discussion group: CrUX showing more than 20 per cent of LCP as image where his RUM data showed less than 2 per cent. Barry Pollard, a Chrome web performance developer advocate and a named author of the web.dev LCP page, answered the same day. Third-party content in iframes, for example YouTube embeds. If that is the largest piece of content then CrUX will see it, while the JavaScript API calls used by RUM tools cannot, and may fall back to a different, smaller LCP like the heading.

Nema's follow up two days later is the part every performance lead recognises: it is difficult to get buy-in from stakeholders like SEO and Product when local tools cannot reproduce the issues showing up in CrUX. There is a narrow route out. A sub-frame can measure its own LCP and beacon it to the parent, which web.dev suggests and which Pollard calls quite tricky to implement accurately. The web-vitals library reconciles the CrUX and RUM differences where it can, and says of this one that the iframe issue is not covered.

The embed becomes the largest element in the dataset Google collects, and vanishes from the one you installed.

Google removed the audit that flagged this, and 77 per cent of desktop home pages still trip it

Lighthouse had an audit for exactly this, called Lazy load third-party resources with facades, where a facade is defined as a static element that looks similar to the embedded third-party but is not functional and therefore much less taxing on the page load. That documentation now opens with a warning: the audit has been removed as of Lighthouse 13. Issue 16430 in the Lighthouse repository, opened on 8 April 2025 and since closed, records the reasons. Possible user input that would load the third party even with a facade in place. Developer hesitation about non first party code. Potential degradation, because a YouTube facade needs a second click to run.

Google did not decide facades were wrong. It decided the audit was hard to keep and that the second click is a real cost. The Almanac's July 2025 crawl still ran Lighthouse 12, so the metric survived one more year: 77 per cent of the 12,155,374 desktop home pages crawled and 41 per cent of the mobile ones could benefit from third-party facades, as measured by Lighthouse. In June 2024 those figures were 70 per cent and 45. Desktop got worse. The Almanac adds its own caveat too, that facades bring sometimes perceptible delays once a user does interact, and with videos in particular double clicks or taps needed to start playing.

2.5 seconds or less at the 75th percentile is good, between 2.5 and 4.0 seconds needs improvement, and over 4.0 seconds is poor. In the July 2025 crawl 62 per cent of mobile sites had a good LCP against 74 per cent of desktop, with mobile carrying nearly double the poor rate, 13 per cent against 7. Mobile is the column a 1,149 kB embed lands in.

Google's own page on Core Web Vitals and Search, last updated 10 December 2025, goes exactly this far and no further: good Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward. That is not a ranking promise, and anybody selling you one has stopped quoting Google.

What to do about it

1. Look up the page in CrUX and find which element it names, because the embed that becomes your LCP is invisible to the RUM tool you installed to watch it.
2. Swap the default YouTube embed for a facade or a self hosted file, then give whatever remains a poster attribute and preload the poster.
3. Set the target as 2.5 seconds at the 75th percentile, mobile and desktop reported separately, and check it in field data four weeks after the change.