GoogleChrome / GoogleChrome/lighthouse
Timespan incorrectly captures CLS from user input
- Dominant language
- JavaScript
- Stars
- 30.8k
- Forks
- 9.8k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 20
Description
### FAQ
- [X] Yes, my issue is not about [variability](https://github.com/GoogleChrome/lighthouse/blob/master/docs/variability.md) or [throttling](https://github.com/GoogleChrome/lighthouse/blob/master/docs/throttling.md).
- [X] Yes, my issue is not about a specific accessibility audit (file with [axe-core](https://github.com/dequelabs/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_
Contributor guide
Research direction
Reproduce the issue on https://web.dev/ using Lighthouse 9.6.2 in Chrome DevTools, with timespan mode and a user-driven resize. Then trace how the timespan run records CLS and compare the reported value with the expected treatment of user-initiated layout shifts; done means resizing no longer produces an incorrectly high CLS.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- performance, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100