Issue debugging INP

[Matthew DeLambo]

It's been hard to debug nytimes.com INP problems. We started pushing the INP attribute data to our metrics service. Unfortunately, the most occurring event target, by far, with a high INP score has an empty value. This data was captured in the last month.

What causes an empty event target? Any advice on more data that we could send up or techniques we could use to analyze this stuff?

-Matt

[Brendan Kenny]

What causes an empty event target?

`target` is a getter that returns a reference to the target element only once accessed. If the target element is no longer in the DOM at that point, `target` will return `null`. A common reason for this is that the interaction itself removed the element (e.g. clicking through a cookie banner). 

Any advice on more data that we could send up or techniques we could use to analyze this stuff?

There aren't perfect solutions here:

- Depending on the page, you may already know most of the ways DOM elements can be removed from the page. This can narrow the candidates considerably, but isn't generally scalable.

- One thing the `web-vitals` library does is create a string selector for the target soon after the performance entry is seen, which will at least cut down on the number of cases where the target is removed from the DOM somewhere in the window between the interaction and when the performance entries are processed.

- You can log event targets (e.g. a selector) interacted with in the event handler itself, though this risks making the interaction slower

There's discussion about building in a way to identify targets even after they've been removed from the DOM here:

- https://github.com/w3c/event-timing/issues/126

- https://crbug.com/1406234

--
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/a2ee7426-1123-48e4-8ecc-2cac6be8c9f4n%40googlegroups.com.

[Barry Pollard]

There are also other reasons why a null event target could be reported. For example, https://bugs.chromium.org/p/chromium/issues/detail?id=1428899

Could you also explain how you are collecting the INP events? Are you calling the Performance Observer yourself, or using a library like web-vitals.js or some oyster RUM tool? I tried to look at the nytimes.com site itself but it wasn't immediately apparent how these were collected from a brief look.

Any advice on more data that we could send up or techniques we could use to analyze this stuff?

The Long Animation Frames API is a new API which has just entered origin trail and can give a lot of information to help debug INP issues, especially those that are less about the event target itself, and more about the general business on the page which can then cause a knock on impact to INP when the user does interact with the page. We think this will be a key API to identify responsiveness issues so keen to hear feedback on it!

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/CAL6E%3DExxbShktzbvZdC7SOLPUHWhYunR2dLxhVtNJHgtJbkZOw%40mail.gmail.com.

[Matthew DeLambo]

Thanks for the feedback.

We are using the web-vitals.js library to forward the inp score AND the attributes to our metrics service. The web-vitals `eventTarget` attribute is the field I was referring to as being empty/null in a lot of cases. We are running a large React app so it sounds like re-rendering is causing the issue. Our biggest setback has been that inp is hard to debug in synthetic environments.

Is there a way to fix this issue in the web-vitals lib where the attributes are saved for a given node at the time of the event, or by cloning the node so that its attributes can be referenced later?

We will give LoAF a try.

[Barry Pollard]

One fix we did land in web-vitals.js was https://github.com/GoogleChrome/web-vitals/pull/354 (which was included in v3.4.0) so if you have some SVG buttons (e.g. hamburger menus) then that might improve things if still on a previous version, though you'll still see some issues where it's not set for the other reasons (that bug I gave, or the element being removed from the document).

Is there a way to fix this issue in the web-vitals lib where the attributes are saved for a given node at the time of the event, or by cloning the node so that its attributes can be referenced later?

No unfortunately not, because the issue is the Performance Observer entry is actually missing the original node so it's already gone before web vitals gets to see it. So this needs to be fixed in Chrome itself and, in some cases (e.g. element being removed from the document) in the spec as well. Will chase the team on this.

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/27ac9cb9-d828-483f-ac52-30e2c2b5549dn%40googlegroups.com.

[Michal Mocny]

I think it was briefly suggested above, but I will list it out in more detail:

You can try leverage the fact that event.type and event.timeStamp will match the PerformanceEventTimingEntry name and startTime.  Here is a super rough example.  (You may want to use capture phase instead of bubble phase, change event types, what you save about the target, etc)

Besides working around some of the limitations of the PerformanceObserver quirks, that approach would be resilient to re-rendering issues -- though we have heard requests to have the Performance Timeline automatically save target selectors.  Some of the other performance timeline entries do already save the node ID, at least.

If you are using React, perhaps you can create an "ObservableEventCallback" helper function that wraps only specific components and then you would additionally be able to use React Component attribution -- though of course this would require explicit instrumentation.  I don't know enough about React Event propagation to know if you could get away with global handlers and still inspect components for component-specific attribution.

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/CAH6JyLSGAG0_%3DOPj1Pt9Agj3OfQgFMKu%2Bbpyp_6rL%3DdiSNWi8A%40mail.gmail.com.