3 ms·

> slow typing, UI interactions like opening a modal that shouldn't be taking 8s+, where's the literature on how those affect user satisfaction? That's right th

> slow typing, UI interactions like opening a modal that shouldn't be taking 8s+, where's the literature on how those affect user satisfaction? That's right there in the post. Google calls these things "input delay." One of the three primary metrics called out in Google's post is FID, "first input delay," which is the delay on the first user interaction. (Subsequent input delays are also bad for users, but subsequent input delays are usually only as bad as the first input delay.)

kaycebasques 6y ago
> (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.
- igrigorik 6y ago
  Input delay is bad, period. 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 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.

kaycebasques 6y ago

> (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.

igrigorik 6y ago
Input delay is bad, period. 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 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.