handling impact of isInputPending on long tasks metrics?

GoogleChrome / lighthouse

Automated auditing, performance metrics, and best practices for the web.

https://developer.chrome.com/docs/lighthouse/overview/

Apache License 2.0

28.21k stars 9.35k forks source link

handling impact of isInputPending on long tasks metrics? #11747

Open brendankenny opened 3 years ago

brendankenny commented 3 years ago

navigator.scheduling.isInputPending is shipping by default in current Chrome stable (m87). Without user input, any page using isInputPending has a strong reason to believe yielding during long tasks won't improve user experience so it could keep on chugging instead.

This may have a large impact on any metric looking at long tasks (TBT, TTI) compared to what a real user would experience when loading the same page.

There was a discussion in the WICG about how it should interact with the Long Tasks API and warnings against long tasks, as well if there should be a way to tell if isInputPending was called during a particular long task: https://github.com/WICG/is-input-pending/issues/37
Chrome status entry

patrickhulce commented 3 years ago

There was some good discussion about this at TPAC too. My primary concern with checking if it was called is that we need to be sure how often it's called. I imagine we'll need to do some sort of shimming like we do with rIC.

brendankenny commented 3 years ago

the last comment in that thread (https://github.com/WICG/is-input-pending/issues/37#issuecomment-698617998) brings up the gameability problem with it, too. Calling isInputPending would essentially bless a long task as fine even if the page had no intention of acting responsibly regardless of the isInputPending result.

paulirish commented 3 years ago

We think an approach like "flip on isInputPending in certain circumstances" could make sense and be more fair to pages using this. Possibilities, always flip on (during a task) at 5000ms since navigation. or flip on after XXms in a long task.

Next step:

find out how to control the value of isInputPending()
find a working/production app/page using this
explore what diff emulation approaches make sense. perhaps talk to framework-side contact to determine what a fair/deterministic
test impact on long-task metrics like TBT and TTI

mostly chillin for now.

we're happy to hear from people familiar with isInputPending() use in frameworks, etc. "good first issue" if this is you.