handling impact of isInputPending on long tasks metrics?

[brendankenny]

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: Interaction with Long Tasks WICG/is-input-pending#37
• Chrome status entry

[patrickhulce]

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]

the last comment in that thread (WICG/is-input-pending#37 (comment)) 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]

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.