Expanded Input Delay as possibility?

[Dave Smart]

I can definitely see why FID has been chosen, and it's got great merit.

But I wonder if there's room for a more extended metric to capture the experience on longer lived pages, where multiple inputs might occur? 

Example use case,  A web app that on clicking a button loads in a largish data set, the FID is very low here because the thread is quite at this point.

The data is displayed in a table, perhaps with a column being calculated from other fields, the user clicks to sort the field and the delay in that input is perhaps much longer than the very low FID the page recorded.

I think some visibility of that might give insight to developers that perhaps it's worth investigating using a worker to move it off the main thread, or doing the calculations server side, or investigate some more performant options.

Perhaps something akin to the new maximum session window approach CLS is taking?

Is this something that's too expensive to track? Perhaps too noisy?

[Nicolás Peña Moreno]

Hi, this is something we're actively looking into. We're currently writing up something that we'll share about what we've been thinking about in this space, so stay tuned :) But basically the plan is to 'expand' FID on two fronts: consider more than just the first input, and consider more than just the input delay.

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/2ed9139d-534a-43c4-b0b6-7ad250f39080n%40googlegroups.com.

[Dave Smart]

Sounds interesting, I'll look forward to reading that, thanks Nicolás!