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.

[Hubert Heller]

Subject: Re: YouTube embed CLS on flixxy.com — thank you + three small asks

 

Hi Barry,

 

Thank you for the detailed reply — it settles months of investigation on my end, and I appreciate you taking it back to both the Chrome and YouTube teams. I want to be clear this isn't a complaint: your explanation matches what I found, and your point that these shifts "are not happening in the usual, unexpected way that CLS is intending to highlight" is exactly the heart of it.

 

To make sure I'm representing your finding correctly going forward: the root cause is the video player component being moved in and out of the viewing area between videos / at end-of-video transitions — not, as I'd earlier speculated, a DASH stream-quality upgrade resizing the <video> element. I'll use your framing.

 

For what it's worth on my side, I think I have an unusually clean reproduction that might help the internal case for the Chrome-side exclusion you mentioned you're exploring:

 

- My homepage and my ~9,000 video pages run an identical ad stack, footer, and consent layer. The only structural difference is that the video pages have an in-place, click-to-play YouTube embed and the homepage does not.

- The homepage sits at 0.00 CLS in Search Console. The video pages sit at ~0.30 p75 in CrUX (561 URLs, both mobile and desktop).

- A Chrome Performance trace isolates it to a single 0.25 shift attributed to VIDEO.video-stream.html5-main-video, firing mid-playback, well outside any recent-input window.

- My own web-vitals RUM reads ~0, consistent with the cross-origin subframe attribution you described.

 

So it's a controlled natural experiment — hold everything constant, add the YouTube embed, and only then does CLS go "poor" — with the exact element and timing already isolated. If that's useful to whoever is scoping the exclusion work, it's yours; I'm happy to share traces, URLs, or field data.

 

Three small questions:

 

1. Is there a public crbug tracking the Chrome-side work to exclude these non-user-experienced shifts? If so I'd like to star and follow it, and it would help to be able to point publishers to it.

 

2. Short of a code fix, would a documented known-issues acknowledgment be feasible? Every third-party tool currently reports my site as "failing" CLS for something Chrome and YouTube agree isn't my fault, and a citable note would help.

 

3. Is there anything specific you'd want captured in a reproduction (particular throttling, video types, trace settings) that would make my case more useful to the team?

 

Thanks again for engaging with this so directly — it's genuinely appreciated.

 

Best,

Hubert

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.

[Amit]

Hi Hubert,

First of all, Please do not use AI to write matter here.
Make this group AI free.

Thanks,

Amit