Measuring Layout Instability / CLS from IFRAMEs

[nicjansma]

The spec mentions that:

The cumulative layout shift (CLS) score is the sum of every layout shift value that is reported inside a top-level browsing context, plus a fraction (the subframe weighting factor) of each layout shift value that is reported inside any descendant browsing context.

and

The subframe weighting factor for a layout shift value in a child browsing context is the fraction of the top-level viewport that is occupied by the viewport of the child browsing context.

This seems like the right thing to do -- iframes affect the visual experience just as much as any other content.

I've found in practice, IFRAMEs aren't currently being accounted for CLS by synthetic or RUM tools:

• Lighthouse doesn't currently take IFRAMEs into account for the CLS score (Lighthouse isn't consistent about Layout Shifts from IFRAMEs GoogleChrome/lighthouse#11500), though it does show shifts from IFRAMEs in its diagnostics section. This will probably be fixed over time.
• RUM analytics packages like boomerang.js, perfume.js, web-vitals and LUX all only listen for layout-shift via a PerformanceObserver in the top-level frame.

I want to make sure RUM and synthetic tools are able to report the relatively-same score. When synthetic tools like Lighthouse start tracking CLS in frames, it may be hard to keep scores similar for some sites via RUM. That can lead to confusion of the metric and questioning its reliability.

For RUM, it would actually be hard to take layout shifts from frames into account:

• You'd need to register a PO for all every frame on the page
• Technically, you probably should crawl the entire frame tree and register in grandchildren/etc
• There may be short-lived frames (that have disappeared by the time RUM comes along), or dynamically introduced frames (that are hard to efficiently know about new ones) that would need PerformanceObserver registered for
• Shifts may come from cross-origin IFRAMEs which cannot have a PerformanceObserver
• Even if all of those shifts were somehow captured, calculating the subframe weighting factor (e.g. viewport percent) seems non-trivial (and time sensitive)

In light of all of this, I'd like to explore if we can try to have the top-level frame emit layout-shift data for all of its children/grandchildren/tree with an already-calculated subframe weighting factor attribute.

This could possibly be solved by w3c/performance-timeline#86 and could also benefit from w3c/resource-timing#210.

I realize that data from cross-origin frames may not be able to be surfaced, or, they'd need to opt-in somehow like in w3c/resource-timing#210.

Thoughts?

[npm1]

I definitely think this is an important problem worth solving, and in particular for CLS we really do want any shifts occurring in iframes to become visible via analytics providers and performance tooling. I also think that the solution to this problem is probably best tracked holistically for all performance entries, and we probably want something like 'bubbles' along with an opt-in from the iframe to its parent frame(s) allowing for content to be surfaced.

So basically I'd say this is equivalent to / blocked on w3c/performance-timeline#86.

[lasseschou]

I agree that this is something to look into. Registering a PerformanceObserver isn't free in terms of browser resources so having to register one in all frames seems to counter the intent of the observer in the first place. Most RUM tools don't do this, and at PageVitals we tried this initially but stopped because of the above. A top-level approach would be ideal.