Re: Specifying the calculation of INP from Event Timing entries

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


That INP definition is correct, though I'm not sure you need the middle
clause (that I've highlighted in italics as that's covered by the previous
quote)?

It is covered in web.dev/inp <https://web.dev/articles/inp#what-is-inp> in
these statements:

An interaction's latency consists of the single longest duration
> <https://w3c.github.io/event-timing/#ref-for-dom-performanceentry-duration%E2%91%A1:%7E:text=The%20Event%20Timing%20API%20exposes%20a%20duration%20value%2C%20which%20is%20meant%20to%20be%20the%20time%20from%20when%20user%20interaction%20occurs%20(estimated%20via%20the%20Event%27s%20timeStamp)%20to%20the%20next%20time%20the%20rendering%20of%20the%20Event%27s%20relevant%20global%20object%27s%20associated%20Document%E2%80%99s%20is%20updated> of
> a group of event handlers that drive the interaction, from the time the
> user begins the interaction to the moment the browser is next able to paint
> a frame.


and this piece (hidden behind a "Details of how INP is calculated" summary
heading:

To give a better measure of the actual responsiveness for pages with a high
> number of interactions, we ignore one highest interaction for every 50
> interactions. The vast majority of page experiences don't have over 50
> interactions, so the worst interaction is most often reported. The 75th
> percentile of all page views is then reported as usual, which further
> removes outliers to give a value that the vast majority of users experience
> or better.


(1/50 is the same as 98th percentile).

and finally we advise measuring the 75th percentile across all page views:

To ensure you're delivering user experiences with good responsiveness, a
> good threshold to measure is the 75th percentile of page loads recorded
> in the field, segmented across mobile and desktop devices


This is also covered in MDN
<https://developer.mozilla.org/en-US/docs/Glossary/Interaction_to_next_paint>
:

INP measures the worst length of time (minus some outliers), in
> milliseconds, between the user interaction on a web page and the next frame
> presentation after that interaction is processed. Scrolling and zooming are
> not included in this metric. INP is calculated using the Event Timing API
> <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming>..
> Asynchronous operations such as network fetches or file reads usually do
> not delay INP as painting can occur while such operations are handled.


> All eligible interactions throughout the page lifetime are considered. For
> highly interactive pages of 50 or more interactions, the 98th percentile is
> used to exclude some extreme outliers that are not reflective of overall
> page responsiveness.


And for the more technical people that wanna see how it's actually
calculated in code, rather than prose, we have the web-vitals.js reference
implementation as you note.

So I'm not sure what more documentation we need to do here on INP?

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


Subparts (FYI, we in Google are trying to unify on "subparts" over
"phases") are a separate thing meant to help point developers in the right
direction of where to concentrate to resolve INP issues.

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


Again this is correct (there the same frame is defined as ending at the
same time taking into account coarsening and rounding issues —
web-vitals.js uses "within 8ms"). This matches the definition that has been
on web.dev/inp diagrams since the beginning:

[image: image.png]

and, for interactions that span multiple frames this diagram further down:

[image: image.png]

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


As discussed offline yesterday, the only place this should happen is in
DevTools which has a somewhat naive interpretation of subparts (that we are
in the process of updating). In effect that's a bug/limitation of the
current DevTools implementation. If you have examples where web-vitals.js
is doing this incorrectly then please let me know.

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


That is entirely your prerogative, however in the interests of
"standardisation" as per this e-mail thread it would be good to understand
your concerns and see if we can agree on something. Or, if not, then
perhaps avoid the use of the same "subpart names" (input delay, processing
duration, and presentation delay) with different meanings.

An "interaction" may be made of multiple event handlers (some of which may
be added by your code, some by third-party code) but they are all fired
based off of the same "user interaction". Treating event handlers
separately is one technical way of looking at it, and does allow you to
concentrate on that code if it's the one at issue, but risks losing the
total duration visibility of code directly linked to that interaction.

For example, at a high level, I advise:

   - High Input Delay: Nothing to do with *this* interaction's code. Look
   at other code or general business of the page.
   - High Processing Duration: Look at *this* interaction. Try to repeat in
   the lab and fix.
   - High Presentation Delay: Likely look at *this* interaction. Try to
   repeat in the lab and fix.

Looking at event handlers individually narrows that Processing Duration
phase meaning you may assume it's not this interaction more often (when it
actually is).

But open to hearing your concerns and alternative approach!

On Wed, 5 Feb 2025 at 17:59, Andy Davies <andy.davies@speedcurve.com> wrote:

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