> (Subsequent input delays are also bad for users, but subsequent input delays are usually only as bad as the first input delay.)
I'm not sure about this statement. It sounds reasonable but I can't recall seeing any research about FID being a proxy for all input delay throughout the entire duration of a session. I would hypothesize that optimizations that improve FID would also tend to improve input delay in general. My main message here is just that I haven't seen that research.
It's not a matter of first vs rest but observation that input while the page is loading is, often, where most of the egregious delays happen: the browser is busy parsing+executing oodles of script, sites don't chunk script execution and yield to the browser to process input, etc. As a result, we have FID, which is a diagnostic metric for this particular (painful) user experience problem on the web today.
Note that Event Timing API captures all input: https://github.com/WICG/event-timing. First input is just a special case we want to draw attention to due to the reasons I outlined above. That said, we encourage everyone to track all input delays on their site, and it's definitely a focus area for future versions of Core Web Vitals -- we want to make sure users have predictable, fast, response latency on the web.
I'm not sure about this statement. It sounds reasonable but I can't recall seeing any research about FID being a proxy for all input delay throughout the entire duration of a session. I would hypothesize that optimizations that improve FID would also tend to improve input delay in general. My main message here is just that I haven't seen that research.