Timespan incorrectly captures CLS from user input

[ramironieto]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://web.dev/

What happened?

When running lighthouse on timespan mode and resizing a page it shows high CLS.

What did you expect?

it should be low as it is within the time window of a user-initiated layout shift, and the resizing is done by the user.

What have you tried?

No response

How were you running Lighthouse?

Chrome DevTools

Lighthouse Version

9.6.2

Chrome Version

105.0.0.0

Node Version

No response

OS

Mac

Relevant log output

No response

[adamraine]

How are you resizing the page? With DevTools open and Lighthouse running I am unable to resize the page manually.

[adamraine]

Never-mind, I needed to resize the window not just the inspector pane. I can repro this.

[adamraine]

We ignore the had_recent_input flag for the first set of layout shifts

lighthouse/core/computed/metrics/cumulative-layout-shift.js

Lines 24 to 29 in 0ce84c0

	// Chromium will set `had_recent_input` if there was recent user input, which
	// skips shift events from contributing to CLS. This flag is also set when
	// Lighthouse changes the emulation size. This results in the first few shift
	// events having `had_recent_input` set, so ignore it for those events.
	// See https://bugs.chromium.org/p/chromium/issues/detail?id=1094974.
	let ignoreHadRecentInput = true;

Instead of the current implementation, maybe we should do this for any layout shifts that occur within the first X ms of the trace starting.

[connorjclark]

isn't that when (real, bad) shifting is most likely to happen?

Ideally the resize events that happen when a window is resized should be marked as "input" for purposes of CLS.

[adamraine]

isn't that when (real, bad) shifting is most likely to happen?

Yeah, that's why we want to ignore had_recent_input for those events. I'm proposing this logic will stay the same for LS events within the first 500ms of tracing.

If every LS event is triggered by some user input then the current logic will count them all.

[connorjclark]

Ah, right. The negation here tripped me up. But why would a manual resize be limited to just the first X ms? You can resize a the windows during devtools LH audit anytime.

[adamraine]

But why would a manual resize be limited to just the first X ms?

We are concerned with the Lighthouse emulation resize at the start of the run being treated as a user input by LS events. Any LS event with had_recent_input = true within the first 500ms of tracing could have been set with had_recent_input = true because of the Lighthouse emulation resize.

LS events only look for user input in a 500ms window before the LS. This is where the 500ms figure comes from.

[adamraine]

https://bugs.chromium.org/p/chromium/issues/detail?id=1302667