Clicking anywhere on the page finalizes FID about web-vitals-extension HOT 5 CLOSED

In some cases, though, an element is interactive even if the page doesn't add an event listener. For example, text selection cannot happen if the main thread is blocked, but most developers don't add event listeners to all their text nodes. The same is true for links. Whether or not a link has an event handler, it still can't be clicked if the main thread is blocked.

I think the metric is doing the right thing here, though I agree it's a bit weird to be penalized for a user tapping a completely empty part of the screen (where they don't expect anything to happen).

from web-vitals-extension.

I think the metric is doing the right thing here, though I agree it's a bit weird to be penalized for a user tapping a completely empty part of the screen (where they don't expect anything to happen).

Thank you for sharing your thoughts on the metric WAI here, Phil. Given some of the potential for it being weird to penalize a user for tapping an empty part of the screen, I think the right call here is to take this feedback back to the Chrome Metrics team rather than doing any special casing / checks you are not in an empty part of the screen for the extension specifically.

Going to close this one up :)

from web-vitals-extension.

@philipwalton as an fyi

from web-vitals-extension.

This is working as intended, though I'd be curious to hear how you think it could be clearer in the docs.

The intention of FID is understand: was the main thread blocked when the user first tried to interact with the page? Which is subtly different from: was an actual event listener delayed from executing?

The problem with the latter is it would be very easy to game. Developers could simply add event listeners to the window and then it would be no different from the former. So rather than encourage this hack, the former definition was chosen. Does that make sense?

from web-vitals-extension.

From my understanding of the docs/API, only user interactions with interactive UI are counted in FID. This was my reading of the click a link, tap a button, or use custom controls examples. I wouldn't expect a user's attempt to interact with non-interactive UI to affect FID, because there's no perceptible experience to measure. The spirit of the interaction delay metric is to get a sense for how long the user had to wait after they asked the page to do something. When clicking a dead corner of the page background, there's nothing for it to do and so I wouldn't expect FID to be affected.

Maybe there's a chicken-and-egg problem if the event handlers haven't been bound yet and there's no way to know if the click was on an interactive element?

from web-vitals-extension.