Re: Specifying the calculation of INP from Event Timing entries

I don't think it needs to be a spec in the same sense of the W3C terms but
I do think it needs to be documented.

As far as I'm aware INP is calculated by:

Choosing the longest duration Event Timing entry that has an interaction
id, and where there is more than one the same choosing the one with the
longest duration, and where there are many events choose the entry with the
98the percentile longest duration

And the Input Delay, Processing Time & Presentation Delay phases are
defined from the Event Timing entry that was used for INP

But when I went searching for definitions I couldn't find one anywhere
(other than reading web-vitals.js code and that's open to error)


Where it gets more complicated is that Chrome and web-vitals.js are
coalescing Event Timing entries which presented in the same frame and so
producing different definitions of the INP phases

Which seems to use the following approach:

- Input Delay is the earliest startTime to the earliest processingStart
across all the Event Timing entries in the frame
- Processing Time is from the earliest processingStart to the latest
processingEnd across all the Event Timing entries in the frame
- Presentation Delay is from the latest processingEnd to the latest endTime
across all the Event Timing entries in the frame

This approach leads to some event handlers being classified in Input Delay
for some interactions, and at other times exactly the same event handler
being classified in Processing Time depending on whether the event
handlers all run in the same presentation frame

I'm clear why I don't want to use the Chrome / web-vitals.js definition but
as it's not documented I suspect others might not even know what the
approach is or how it may affect them

And documenting it would save others going through the process I went
through and save Barry from all the questions I asked him



On Tue, Feb 4, 2025 at 6:09 PM Michal Mocny <mmocny@google.com> wrote:

> It's an interesting question.  The web platform specifications define the
> public web platform features: Event Timings (for INP), Layout Instability
> (for CLS).  Largest Contentful Paint the web feature is more closely
> matching LCP the metric (though even there, there are gaps, like merging
> iframes).
>
> I think there is not typically a "spec" for INP/CLS other than the
> specific conventions that the Core Web Vitals program uses, and those are
> defined on sites like web.dev (as you linked) and reference implemented
> on web-vitals.js.  Other RUM providers I think have always deviated in
> small ways (i.e. loading-only vs post-load, etc) and might always need to
> deviate.
>
> That said: we do have a note in the non-normative section
> <https://wicg.github.io/layout-instability/#cumulative-layout-shift> of
> layout instability spec for DCLS and CLS, with a usage example -- though
> that description isn't up to date with the latest CLS CWV metric...
>
> I would be happy if someone wanted to add documentation to all the
> non-normative sections of all the specs to define these, but I'm not also
> not sure about it.
>
> On Tue, Feb 4, 2025 at 12:13 PM Andy Davies <andy.davies@speedcurve.com>
> wrote:
>
>> https://web.dev/articles/inp contains an abstract overview of what INP
>> represents but…
>>
>> There's no actual specification for how INP it should be calculated from
>> Event Timing entries.
>>
>> Don't know whether this should exist within this CG or be raised in the
>> WebPerf WG but as it's a 'standard' metric then I think it should be
>> documented
>>
>> Thanks
>>
>> Andy
>>
>> --
>>
>> Andy Davies
>> Web Performance Consultant, SpeedCurve
>>
>>
>>