layout-stability-metric.md

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

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.