-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider expose FID duration
as first INP
score, for cases when its under durationThreshold
#228
Comments
This is something I had originally considered but ultimately decided against for a few reasons:
I don't think either of these are really strong reasons not to, but I'm also hesitant to add code to the library for a use-case that really only benefits the extension (which can do this itself). The other thing is, if you don't need the onINP((metric) => {
// If the metric show 0, fall back to the `first-input` entry.
if (metric.value === 0) {
const entry = performance.getEntriesByType('first-input')[0];
metric.entries = [entry]
metric.value = metric.delta = entry.duration;
}
console.log(metric);
}); But to add proper support for this in the library, then I'd have to integrate it into the logic that keeps track of the 10 longest interactions, which adds complexity that most people likely don't need. Anyway, like I said above, I'm not 100% against adding this, but I want to make sure it's useful to regular users of the library and not just add it for the extension. Tangentially, I wish we had made the new PerformanceObserver(console.log).observe({
type: 'event',
buffered: true,
durationThreshold: 40,
includeFirstInteraction: true, // Rather than a separate entry type.
}); |
Filed crbug.com/1325826
It is that low, at the time of the first interaction. I guess you mean that the second interaction, if it was <durationThreshold, may affect INP in ways we don't catch with onINP. Fair, but tbh, that doesn't convince me we shouldn't record the first-input.
I do agree the current demand is just the extension, and we can fix there. However, if any RUM providers start measuring INP, the fact that INP is an OPTIONAL metric, recording NULL in cases where there is an interaction will have a larger measurement effect than recording FID.duration instead of some slightly larger INP.
I like it!
I wasn't here for the history, but my understanding is that first-input shipped before event timing and we don't want to remove anything ever. So it wasn't so much that we added
Interesting. Personally, I don't think we need this property. I agree that it would be nice if event timing could expose the first-input even if it was under 16ms. Perhaps we could change the durationThreshold minimum of 0 to allow actual 0 for the first-input only? That wouldn't support the case you show above (asking for 40ms min and first-input) but can handle that in either of the above strategies you list. Net/net, I think you are right that we don't need to add this to web-vitals.js. Even though I worry about the default behaviour, there are simple workarounds that can be used. We may be able to just fix the spec to make it work better by default. |
One more consideration:
...seems to work well enough. It's roughtly equivalent to |
onINP
relies on event timingdurationThreshold
and provides a default of 40ms (configurable down to 16ms).There are cases where we report
onFID
but notonINP
because of this threshold.first-input
event timing actually does already expose theduration
value so we can report the full latency exactly as INP would measure it, and not just the input delay.Would help address GoogleChrome/web-vitals-extension#103
The text was updated successfully, but these errors were encountered: