Land experimental responsiveness metric in user flows

The new responsiveness metric has mostly settled and so we want to include support for it in situations where there can be (real or automated) user input.

The steps foreseen:

• add the high-percentile responsiveness metric for timespans - #13917
• add a metric N/A state (that may not be notApplicable) in the report perf category renderer for when there was no user input in the trace - #13981
• add an interactions audit for debugging responsiveness, e.g. here are the keypresses with the slowest response, here’s the breakdown of what was blocking the response (time in script, layout, paint, etc) - #13982
• Add relevantAudits? Would be similar to TBT’s relevantAudits - #13982
• add to navigations if interactions present in the trace, but as a diagnostic audit, not a metric
• timespans don’t yet support simulated throttling, but navigations do. Investigate if simple CPU multipliers are enough to get simulated numbers or if more sophisticated lantern simulations are needed
• yarn update:flow-sample-json --rebaseline-artifacts Trace to update the sample flow trace for the new EventTiming trace events (see https://github.com/GoogleChrome/lighthouse/pull/13979#discussion_r868407873)

[adamraine]

Would that be possible?

It should be possible as part of #13898

[brendankenny]

We don’t remove metrics if they are N/A though

yes, but only because there’s never been a notApplicable metric before and the display code is valueEl.textContent = audit.result.displayValue || ''. There was not a plan here 😃

I think the argument is convincing, I just want to make sure to explore the options because it does remove basically the only way we have for an audit to remove itself from the report. If that’s something we ever want to do for metrics, we’ll either have to change this again (which may not be possible) or add yet another mechanism to do so.