Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Measuring Layout Instability / CLS from IFRAMEs #80

Open
nicjansma opened this issue Oct 5, 2020 · 1 comment
Open

Measuring Layout Instability / CLS from IFRAMEs #80

nicjansma opened this issue Oct 5, 2020 · 1 comment

Comments

@nicjansma
Copy link

nicjansma commented Oct 5, 2020

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:

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
Copy link
Collaborator

npm1 commented Jan 27, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants