#485: Layout Instability Shifted Element Surfacing

Visit on Github.

Opened Mar 17, 2020

Hello TAG!

I'm requesting a TAG review of Layout Instability Shifted Element Surfacing.

Today it is difficult for web developers to understand the cause of a high CLS score using the Layout Instability API, because nothing in the score or the PerformanceEntry connects back to the specific DOM elements that were affected by the layout shift.

CLS Shifted Element Surfacing (SES) is an effort to surface a subset of the shifted DOM elements in the LayoutShift interface. This will improve the "actionability" of CLS for developers.

Further details:

  • I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: n/a
  • The group where the work on this specification is currently being done: WICG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C
  • Major unresolved issues with or opposition to this specification: n/a
  • This work is being funded by: Google

You should also know that...

This feature adds a new attribute ("sources") to an interface defined in an existing specification (Layout Instability). The PR to amend the spec with this feature is not yet landed but we are proactively initiating TAG review to optimize the time available to review. There is some discussion on the PR review thread which may alter some aspects of the API.

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify [github usernames]

Discussions

Comment by @torgo Mar 18, 2020 (See Github)

Hi! On "The group where standardization of this work is intended to be done" can you be more specific? Will this be going to the web performance working group?

Comment by @torgo Mar 18, 2020 (See Github)

On the explainer, can you please take a look at our explainer explainer? We'd really like to see more info here – and please remember this explainer is not intended to just be for the purposes of the TAG review. It's about writing some documentation about how the technology works that will keep providing value down the line as the spec matures...

Comment by @skobes-chromium Mar 31, 2020 (See Github)

Thanks for the comments and apologies for the delayed update.

Shifted element surfacing has now been added to the master explainer for the Layout Instability API. The "Source Attribution" section describes the new attribute. I think this makes more sense than having a separate explainer, since this is an extension to an existing API rather than a brand new API.

The updates to the spec have also been committed; the sources attribute and the LayoutShiftAttribution interface are now included in the Layout Instability API specification in WICG.

Standardization of this work is intended to be done in the CSS web performance working group.

Discussed Apr 6, 2020 (See Github)

Rossen: this moved to WICG, the explainer link won't get you there

Tess: can you fix the link in the issue?

David: most recent comment says it's in the master explainer now

[aside conversation about change policy related to documents under review. rossen explained how it works for another api review board he participates in. we don't currently have such a policy. Hard to have document stability when reviewing living standards.]

Tess: L.I.S.E.S. is a very dense name. what does it even mean? ELI5

David: does "surfacing" here mean "we are surfacing this data with an API"

Rossen: yes.

... the idea is you compute a layout stability score, which is an approximation of how much layout has changed between rAF frames. 0 means no change. anything more than zero means your layout is not stable.

... this score is computed based on shifts that are not caused by transforms or scrolling. IOW if you're animating with transforms, your layout is actually stable. this is to catch dom nodes being inserted / removed, etc.

... this feature is intending to compute the cost of reflow at the document level by aggregating these per-frame scores.

... they have a couple of different multipliers, an impact fraction and a distance fraction. the impact fraction is a bit confusing. it computes a fraction based on the elements box in comparison to the overall animation frame. i don't know how and why that matters that much. distance is straightforward.

David: this came in post-wellington and assigned to today. i haven't looked at it. i feel some deja vu looking at this. there have been multiple attempts to solve this problem before. we've reviewed 2 or 3 of them.

Tess: why will this approach succeed when the previous ones didn't?

David: one thing I'm not understanding: how does what we're being asked to review here relate to the overall API we reviewed in w3ctag/design-reviews#393. i think what we're reviewing now is the "source attribution" section.

... i should read the source attribution section more closely.

... this is about saying in these layout shift reports it will put up to 5 elements and list them so the website can figure out what the problem is when it sees high layout shift numbers.

Tess: should we push this out?

David: i just read it. it has the feel of a lot of the web performance work. sites are having these problems, so we fish around for metrics to expose to help people debug their problems. the way to find that out is to get it out there and see if it's useful for people.

... one question: do these accumulate in a way that will keep orphaned nodes alive? i should add a comment with some questions.

Tess: okay, let's leave those questions & mark as 'pending external feedback'.

Rossen: in the privacy section, it says this exposes resource timing, and that means fingerprinting. it's limited to the current browsing context. re: resource timing and fingerprinting, i don't see why this doesn't apply to this api too.

Tess: sounds like a good question to ask them

[push out one week

Comment by @dbaron Apr 6, 2020 (See Github)

So we looked at this briefly in our Breakout B today.

A few thoughts:

  • How long lived are these LayoutShift performance entries going to be? Is there a risk that they'll (via the LayoutShiftAttribution) entrain a bunch of dom nodes that would otherwise be garbage and cause memory leaks? (And would this happen on all pages, or just those that invoke certain things?)

  • In general, a lot of this feels like trying things to figure out what metrics are going to be useful for sites to figure out their performance problems. It's... hard for us as the TAG to guess what's going to be useful here, other to say it would be great if the end result is that the successful experiments end up baked into the web platform and the unsuccessful ones don't.

Comment by @atanassov Apr 7, 2020 (See Github)

Another question based on your Privacy Section, can you elaborate why does "statistical fingerprinting" apply to resource loading but not Layout Instability?

Comment by @skobes-chromium Apr 9, 2020 (See Github)

On memory leaks: this actually came up on the PR and we made some changes as a result: LayoutShiftAttribution does not retain a DOM node after it is removed from a document. The getter for the node attribute returns null in this case (via the "get an element" algorithm from the element timing spec). So the attribution acts like a weak pointer, and still provides some information (new and previous visual rects) when node is null.

On privacy: we do not claim that fingerprinting applies to resource loading but not layout instability. On the contrary, the intent is to disclose that layout instability is affected by resource loading, and therefore shares the same theoretical fingerprinting opportunities.

Discussed Apr 13, 2020 (See Github)

Rossen: need to spend some additional time on this one. The overall feedback was "sounds like a useful thing"... "why didn't the previous approaches work?"

...addresses layout jank across

[bump 2 weeks

Comment by @dbaron May 27, 2020 (See Github)

From https://github.com/w3ctag/design-reviews/issues/485#issuecomment-606343223:

Standardization of this work is intended to be done in the CSS web performance working group.

Did you mean the CSS Working Group, the Web Performance Working Group, or some combination of them?

Comment by @dbaron May 27, 2020 (See Github)

@atanassov and I just took a look at this again in a breakout at our virtual face-to-face. I think we're happy closing this; what we've seen seems reasonable. We encourage you to continue to get feedback from the appropriate working groups (I suspect Web Performance is probably the right venue but that it's useful to get a bit of feedback from CSS), and to get data on whether this is a useful approach for the performance that affects users and for what developers want to measure.

Comment by @skobes-chromium May 28, 2020 (See Github)

Thanks - I think I meant the Web Performance working group, which publishes specs for APIs like Performance Timeline, Paint Timing, etc.