layout-stability-metric.md

https://github.com/ehanley324/layout-instability/blob/master/explainer.md

I agree that "Jank" isn't the best term here.
Something like "Layout Stability" is, I think, a better term.

"So I think, at the very least - renaming it to scrollLayoutJank or something similar would aid in its intuitiveness."
This isn't scrolling related - it's about content moving around within the viewport.

"Starting with jank isn't the best approach as it's a subjective metric as one persons jank is another person's smooth."
For layout stability, I don't think this this is the case.
This metric is defined so that for most pages, there should be 0 layout instability.
There are some tricky animated cases that are a bit fuzzy, but the general case is very clear.

From discussion at the call, it seems that the naming was the only objection here. Here are some options for the name:
Prefix: Content, Dom, Layout
Suffix: Instability, Movement, Shift

The score could also be inverted and we could invert the naming correspondingly (for example, LayoutStability). Any thoughts on which of these would be a good name, if any? Other proposals welcome.

I voiced some concerns in Lyon on the term 'Jank'. Personally I think Layout Instability works best. DOM Instability to me could just be changes to the DOM tree structure of the page that may or not have visible layout implications so I think the Layout prefix is more descriptive.

I personally prefer "Layout Stability", followed by "Layout instability".

I can't think of a prefix that's reasonable except for "Layout", for reasons like what @bgirard shared.

@gregwhitworth would LayoutStability or LayoutInstability make sense to you?

Ok, I've been thinking about this more and more and before I jump back into the name debate, I want to call for clarity of the point of this API again.

The reason I ask is due to a statement that was made on the call (I'm paraphrasing):

There is no way to determine the cause of the low score

Based on that statement my issue with this API comes down to one thing, a score has been defined that is not really useful. It will inform you that there is a problem but in no way will it help you solve that problem. That makes me wonder what value this is bringing to web developers?

Switching gears back to the name, we're probably going to have just overload Layout here - which only conflates the problem I denote above because a webdev may receive this negative score and will want to look at CSS or why flex/grid/block, etc is causing issues when in actuality it's the heavy image that took forever to load in the ad network that is above the paragraph. So yes, the layout moved but it's actually due to a large resource coming in after the initial render was possible.

Personally, I wouldn't put this API in its current form into the platform, I would look at why "Layout Instability" occurs (maybe the top 5 reasons*) and then derive potential scores off of those as they'll be able to be diagnosable for the web developer.

• I understand that some of these reasons may have nothing to do with the site itself but things between the server serving the content and the rendering engine that the author has no control over (eg: slow network, low end hardware, etc).

We don't expect the average web developer to touch this API. The common case here will be for RUM analytics vendors to surface this data to users, highlighting issues the developer wasn't aware they had.

You're right that actionability is sometimes tricky here, but the first objective is to make sure developers realize there's a problem. Once developers know there's a problem, we can tackle actionability via:

• Documentation (e.g., try enabling the unsized media policy and set your font-display values to optional).
• Local developer tooling letting devs dig in further, with more actionable output.
• Possibly in the future, better attribution baked into the layout stability API.

Does that seem reasonable? I think step 1 is ensuring folks are aware of the problem and step 2 is making it simple to fix it.