Expose what caused the layout instability.

[tdresser]

No description provided.

[bryanmcquade]

A few thoughts / challenges here (based on conversation with tdresser):

• we accumulate jank per frame, so we'd probably want to batch up the jank causes within each frame and report them once (as opposed to reporting every element that moved, as we process it)
• we need to bound the amount of information we report (maybe we report top N largest elements that moved?)
• we can report elements that shifted, but it seems out of scope to report what caused that shift. for example, if a script changes an image's size and that causes element Y to move around it, it seems out of scope for us to try to report that element X changed size due to script. rather, we can report that element Y moved. i imagine developers should be able to figure out the cause of the elements changing location when they debug / review their code. devtools could conceivably provide richer information to augment the API, showing both what moved as well as potentially elements that changed size to cause the move.

[skobes-chromium]

I agree it would be very useful for web developers to have some way of attributing layout shifts back to the elements that "caused" them, for some notion of causality. However this would involve a lot of complexity given the amount of indirection between (for example) an image changing size after load and some elements elsewhere on the page being placed differently after layout.

A more limited form of attribution is possible by visual inspection with the "show layout shift regions" mode that is now available in devtools.

[skobes-chromium]

We have begun some exploration of this in Chromium.

I think that surfacing a subset of the elements that shifted solves the biggest challenge of understanding a report of layout instability, without doing full causality attribution (e.g. back to a different element whose insertion caused the shifted element to shift).

We are contemplating an extension to the API that would include an array of top 5-10 shifted DOM nodes in the PerformanceEntry object as entry.impactedNodes = [...].

These would be approximately selected by size with some smarts for ignoring redundant descendants of a shifted container. Reporting all of the shifted nodes (versus only top N) is probably not feasible due to performance impact.

Would be great to have feedback from the developer community about whether this would be useful or not.

[nicjansma]

Gaining access to at least some of the attribution of the shifts would be very useful for anyone that is using the API or reporting on something like CLS.

We're experimenting with exposing CLS in boomerang, and we know that as soon as we expose the metric, there will be questions of "what's causing this number to be what it is" and "why did it change?".

We could probably find a way to package up some of that contributing node information (e.g. capture each node's id="" or class="" or xpath/csspath), in cases that the users of boomerang need to debug the metric further.

[gi11es]

I think that top affected elements is very valuable information, it sounds like a good compromise. Anything that can put us on the trail of the cause helps. For us it should be sufficient to understand what happened in the vast majority of cases.

[npm1]

Note that you cannot expose the elements if those are inside shadow DOM. What's the plan in that case?

[skobes-chromium]

In that case we could expose the shadow host in its place.

[npm1]

Exposing the closest ancestor that's not in shadow DOM makes sense (the shadow host can also itself be within a shadow tree, i.e. they can be nested). I don't know if there's a word for that... 'top-level shadow host'.