Cross-origin YouTube iframe CLS — attribution and mitigation options for publishers?

[Hubert Heller]

Hi all,

I run Flixxy.com, a family-friendly curated video site with ~9,000 pages embedding YouTube videos via the IFrame Player API and lite-youtube. Our mobile CrUX p75 CLS has been stuck at 0.27–0.30 since November 2025 despite resolving every CLS source our parent-frame PerformanceObserver can see (GA4 now reports near-zero parent-frame CLS on fixed pages).

I finally connected a Pixel via USB remote debugging today and captured the attached DevTools trace. It shows a 0.1529 layout shift at t=19.08s during playback, with the tooltip identifying the culprit as video.video-stream.html5-main-video 392 × 220 - an element inside the cross-origin YouTube iframe. The Insights panel says "Could not detect any layout shift culprits," which I understand to mean the heuristic can't introspect the cross-origin frame, even though the shift itself is clearly visible in the filmstrip (the video area collapses and content below jumps up).

A few questions I'm hoping someone can help with:

1. Is CrUX counting these cross-origin iframe shifts in my site's p75 CLS? My understanding is yes, via the Subframe Weighting Factor per the Layout Instability spec, but I'd like to confirm. This would explain why GA4 (parent-frame only) shows CLS ≈ 0 while CrUX shows 0.27.
2. Is the "video.video-stream.html5-main-video" shift a known pattern? It seems to correlate with pre-roll-ad-to-main-video transitions or video state changes. Has Google's YouTube Embed team or the Web Vitals team published guidance for publishers embedding YouTube at scale?
3. Mitigation options that actually work? I've considered:
   • Adding sandbox="allow-same-origin allow-scripts" to the iframe?
   • Click-to-play poster pattern so user tap provides hadRecentInput forgiveness for all subsequent shifts
   • Locking iframe height via aspect-ratio CSS (already done — doesn't prevent internal shifts)
   Has anyone measured real-world CrUX improvements from any of these approaches?
4. Is there a way to signal to Chrome that a cross-origin iframe's shifts shouldn't count against the host page? Something analogous to how iframes with loading=lazy don't affect parent LCP? I understand the security/UX rationale for counting them, but publishers have zero control over third-party embed internals.

Happy to share additional traces, GA4 custom-dimension data, or CrUX history if useful. Screenshot of the DevTools trace attached.

Thanks, Hubert Heller Flixxy.com

[Hubert Heller]

Following up after 11 days with no replies. I now have additional DevTools traces showing the shift consistently attributed to video.video-stream.html5-main-video inside the cross-origin YouTube iframe. One of the layout shift culprits is identified as an unsized image element from a YouTube ad creative (Aldro_k94J...fff-no-rj).

Two specific shifts captured today at approximately 7.83s and 8.26s after user click — both well outside the 500ms hadRecentInput forgiveness window. Typical pre-roll ad timing (5-15 seconds after user interaction) makes click-to-play forgiveness ineffective for this category of shift.

Can anyone from the CrUX team or YouTube Embed team comment on:

1. Whether this is expected behavior given the Subframe Weighting Factor design?
2. Whether the YouTube team has any plans to provide explicit dimensions on internal ad creative containers to prevent these shifts?
3. What mitigation options remain for publishers who have already implemented all conventional CLS fixes (aspect-ratio containers, click-to-play facades, CSS containment)?

[Barry Pollard]

Hi Hubert,

Apologies for the delay in responding. We have noted your concerns and have been investigating if there is any way of resolving this issue on either the Chrome or YouTube side. Unfortunately, we have not yet found a resolution.

I believe we discussed this exact issue on this site before a few years back (or maybe this was another member of your team?). The way CLS is measured in Chrome is based on where elements are observed to be moving around. In this case the elements are moving (hence why this is measured in Chrome) as the video player component is moved in and out of the way and new creatives are shown between videos. However, I agree that in this instance the "shifts" that happening are not happening in the usual, unexpected way that CLS is intending to highlight (hence why YouTube has not prioritised implementing a fix for this, and because of some knock on effects they believe that could potentially have).

To answer your previous questions:

1. Is CrUX counting these cross-origin iframe shifts in my site's p75 CLS? Yes these will be included because Core Web Vitals measure user experience across the page, including iframes.
2. Is the "video.video-stream.html5-main-video" shift a known pattern? As per the previously linked thread, we in Chrome/CrUX and the YouTube team are aware that the way YouTube implements end of video transitions is currently measured as CLS. Unfortunately, it is not an easy fix for either team to implement to avoid this being counted as CLS.
3. Mitigation options that actually work? Unfortunately, this is not something you can mitigate on your side.
4. Is there a way to signal to Chrome that a cross-origin iframe's shifts shouldn't count against the host page? No, this is not possible. In most cases, when third-party embeds cause UX issues we do want to measure them whether you have control over fixing them or not, sicne they are issues users are experiencing regardless of that lack of control on your side. And we do not give any special exceptions to Google-owned properties. This case is an unusual case where the user impact is arguably not being reflected in the metric for technical reasons.

And your latest questions:

1. Whether this is expected behavior given the Subframe Weighting Factor design? I'm not sure what you mean by "Subframe Weighting Factor design", but yes iframes/subfframes are included in top-level page CrUX calculations since those are the pages users experience those metrics on. And yes this can cause discrepancies between measurements that RUM solutions can measure and CrUX, due to security reasons.
2. Whether the YouTube team has any plans to provide explicit dimensions on internal ad creative containers to prevent these shifts? It is not the lack of explicit dimensions that is the problem here (though that often does cause CLS issues so I understand why you thought this might be the issue). The issue is with the shifting of the video player component in and out of the viewing area between videos. Currently, they do not plan to change this in a way that would cause the CLS calculation to ignore it. We are also looking to see if Chrome can exclude these non-user experienced "shifts" from the CLS calculations but that is not trivial either.
3. What mitigation options remain for publishers who have already implemented all conventional CLS fixes (aspect-ratio containers, click-to-play facades, CSS containment)? At present these are no mitigations for this particular issue.

The Core Web Vitals are intended to measure the experience accurately for the vast majority of sites, and the feedback we have received is that they broadly do. I do appreciate how frustrating it is when they don't on your site, particularly for reasons that are outside of your control and which arguably are not measuring the user experience.

For now, you have to understand that this is a known issue and my advice would be to continue to monitor your other user experience measures — including your RUM-collected CLS to identify if any other, actual CLS issues start to happen on your site.

Thanks,

Barry

--
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/ba2edc6e-5008-4197-ae09-3f349780c8e9n%40chromium.org.

[Hubert Heller]

Hi Barry,

Thank you for the detailed response.

Some additional context that you might find interesting: years ago you helped me work around the 'cards at end of video' CLS issue by suggesting loop=1 with a playlist. That worked well until November 2025.

With YouTube's increased ad serving frequency, I suspected that those loop transitions may have become new CLS opportunities. So, on April 24, I removed the loop=1&playlist=... parameters.

 

Based on your description of the issue ('shifting of the video player component between videos'), I hope this will at least help to reduce CLS impact on long-engagement sessions.

 

I'm currently in the CrUX rolling window waiting for data. My goal with this “mitigation” attempt is to move

the mobile CLS p75 from 0.30 (Poor) into the Needs Improvement range (under 0.25).

Hubert, www.flixxy.com

 

From: Barry Pollard [mailto:barryp...@google.com]
Sent: Monday, April 27, 2026 6:21 PM
To: Hubert Heller
Cc: Chrome UX Report (Discussions)
Subject: Re: [CrUX Discuss] Re: Cross-origin YouTube iframe CLS — attribution and mitigation options for publishers?

 

Hi Hubert,

 

Apologies for the delay in responding. We have noted your concerns and have been investigating if there is any way of resolving this issue on either the Chrome or YouTube side. Unfortunately, we have not yet found a resolution.

 

I believe we discussed this exact issue on this site before a few years back (or maybe this was another member of your team?). The way CLS is measured in Chrome is based on where elements are observed to be moving around. In this case the elements are moving (hence why this is measured in Chrome) as the video player component is moved in and out of the way and new creatives are shown between videos. However, I agree that in this instance the "shifts" that happening are not happening in the usual, unexpected way that CLS is intending to highlight (hence why YouTube has not prioritised implementing a fix for this, and because of some knock on effects they believe that could potentially have).

 

To answer your previous questions:

1.      Is CrUX counting these cross-origin iframe shifts in my site's p75 CLS? Yes these will be included because Core Web Vitals measure user experience across the page, including iframes.

2.      Is the "video.video-stream.html5-main-video" shift a known pattern? As per the previously linked thread, we in Chrome/CrUX and the YouTube team are aware that the way YouTube implements end of video transitions is currently measured as CLS. Unfortunately, it is not an easy fix for either team to implement to avoid this being counted as CLS.

3.      Mitigation options that actually work? Unfortunately, this is not something you can mitigate on your side.

4.      Is there a way to signal to Chrome that a cross-origin iframe's shifts shouldn't count against the host page? No, this is not possible. In most cases, when third-party embeds cause UX issues we do want to measure them whether you have control over fixing them or not, sicne they are issues users are experiencing regardless of that lack of control on your side. And we do not give any special exceptions to Google-owned properties. This case is an unusual case where the user impact is arguably not being reflected in the metric for technical reasons.

And your latest questions:

1.      Whether this is expected behavior given the Subframe Weighting Factor design? I'm not sure what you mean by "Subframe Weighting Factor design", but yes iframes/subfframes are included in top-level page CrUX calculations since those are the pages users experience those metrics on. And yes this can cause discrepancies between measurements that RUM solutions can measure and CrUX, due to security reasons.

2.      Whether the YouTube team has any plans to provide explicit dimensions on internal ad creative containers to prevent these shifts? It is not the lack of explicit dimensions that is the problem here (though that often does cause CLS issues so I understand why you thought this might be the issue). The issue is with the shifting of the video player component in and out of the viewing area between videos. Currently, they do not plan to change this in a way that would cause the CLS calculation to ignore it. We are also looking to see if Chrome can exclude these non-user experienced "shifts" from the CLS calculations but that is not trivial either.

3.      What mitigation options remain for publishers who have already implemented all conventional CLS fixes (aspect-ratio containers, click-to-play facades, CSS containment)? At present these are no mitigations for this particular issue.