Any guidance on a problem area

[Matthew DeLambo]

On the New York Times site, we're tracking down some of the poorest event targets. One target that stands out prominently with a poor INP score (above 2000) and many impressions, is the paragraph on article pages. Those paragraphs usually only feature text with links (I'm still trying to determine if there is ever more).

Here's the selector, if you want to try it out on any NYTimes article:

document.querySelectorAll('div.css-s99gbd.StoryBodyCompanionColumn>div.css-53u6y8>p.css-at9mc1.evys1bk0')

What could cause that? Clicking/highlighting paragraph text? Clicking links?...but I would expect an `a` tag event target in that case.

Any guidance would be helpful in debugging this issue further 🙏

-Matt

[Barry Pollard]

Do you have a way of seeing which user agents are affected by this? There was a bug which affected links opened in a new tab, but it was fixed a while back. However, some sites have reported still seeing this in their analytics for older browsers or Samsung Internet (which does not update for every Chrome release) so that's a potential reason. If you can filter these out of your analytics you can concentrate on your real issues.

--
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/d940ed7a-2284-4aa2-abd3-e946fc48456fn%40googlegroups.com.

[Matthew DeLambo]

Hey, sorry it took a sec to get this data. This is a query for yesterday (9/28) which shows the number of INP impressions for the paragraph selector, browser name and version:

It appears to be affecting recent versions of Chrome and Edge the most.

[Matthew DeLambo]

For some reason, the embedded screenshot failed to save. Here's the text version of those results:

f0_ name version_major
6100 Chrome Mobile 117
2072 Edge 117
1340 Firefox Mobile 117
473 Chrome Mobile WebView 117
301 DuckDuckGo Mobile 5
285 Amazon Silk 116
273 Firefox Mobile 118
197 Chrome 113
183 Chrome 103
177 Facebook 433
175 Googlebot 2
110 Chrome Mobile 115
84 Chrome Mobile 111
67 Chrome 111
49 Chrome Mobile 112
47 Firefox Mobile 115
42 Firefox 114
41 Opera Mobile 77

[Dave Smart]

One action I have found causes INP on text on mobile chrome press to highlight > share

Not recorded it being huge but might depend on device / size of paragraph?

[Barry Pollard]

OK so looks like it's not that bug then. And btw I don't think it's "affecting recent versions of Chrome and Edge the most", it's just more likely they are more common browsers nowadays. But I agree it definitely appears to be affecting recent browser versions.

Other than that bug, we're not aware of any general slowness around clicks (particularly on just texts rather than interactive elements) so this sounds more site-specific. I do note there are a lot of click handlers on the document and body:

And similar for other event handlers. That main...103 seems to listen to everything event happening on the page!

When I profile it with 4x slowdown (I have a high spec machine), I can clearly see some small tasks as I click different paragraphs:

So suggest you start there. Do let us know how you get on.

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/0c7ac143-3960-4b4a-b0a7-bd31a7a276f9n%40googlegroups.com.

[Michal Mocny]

I just tried to play with the page, Mobile emulation, without any CPU throttling.

There happened to be a lightbox interstitial to prompt me to subscribe:

Because I did not find any way to dismiss the prompt, I simply just tried clicking outside of the bounds of the interstitial hoping it would close.  This click happened to overlap with a loading-related (very) Long Task:

Again, no throttling, on a macbook.  This specific task ran from 1.25s into page load to 2.5s into page load-- which seems like a likely time for folks to accidentally click anywhere on the page, including just blank text.

What I would suggest is to try to break down the timings of the Interaction-- could you confirm that all of the latency comes from Input delay before event handlers even begin to run?

Another way to confirm this hypothesis quickly would be to just compare against FID data for the same page sessions, if you are still recording those as well.

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

[Matthew DeLambo]

Thanks for the advice. What are you using to test small tasks Barry? ...LoAF?

I'm doing some Chrome Performance profiling, and realizing that in simulated mobile, simply clicking on a paragraph a couple times can sometimes cause a bad INP score. What exactly is happening there?

[Matthew DeLambo]

f I wasn't clear by my question: If INP is timing an event until there is visual feedback, wha is the visual feedback that is expected for a click in text in a paragraph?

Am I testing this wrong?

[Barry Pollard]

INP measures any interaction until the next paint including that paint. For some interactions (including these here) there may be no paint so the paint time itself is not included, but it still measures the interaction cost until there is the opportunity to paint as, during this time, other interactions are not able to execute.

This is why long tasks seen in the Performance Panel trace after interactions are important to concentrate on, even if there is no "paint" as such.

On Fri, 29 Sept 2023 at 20:24, 'Matthew DeLambo' via web-vitals-feedback <web-vital...@googlegroups.com> wrote:

If I wasn't clear by my question: If INP is timing an event until something animates, what exactly is the animation for a click to text in a paragraph?

Am I testing this wrong?

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/611643ac-1397-4cef-8a02-3c4d606e0a19n%40googlegroups.com.

[Matthew DeLambo]

On Friday, September 29, 2023 at 3:29:16 PM UTC-4 Barry Pollard wrote:

INP measures any interaction until the next paint including that paint. For some interactions (including these here) there may be no paint so the paint time itself is not included, but it still measures the interaction cost until there is the opportunity to paint as, during this time, other interactions are not able to execute.

I don't know if that should be broadly applied. The New York Times site is not highly interactive. The vast majority use case is to open and scroll/read content. Sure a user may casually click on some text but in that use case they are not experiencing anything adverse. What's the point of penalizing in that context?

[Barry Pollard]

Interactions without any visible paint are the vast minority, hence why the metric is currently calculated as it is. Most interactions have some visible update (even if it's just the browser UI changing the 3D effect of a button, or closing a select menu) which gives feedback to the user that the interaction has been registered.

Your "no-op" interactions are the exception to this where there really often is no intended paint (other than potentially text select which should in most cases be handled by the browser when the main thread is free), but there can still be consequences that are more difficult to measure. This was discussed previously here: https://bugs.chromium.org/p/chromium/issues/detail?id=1322628 and it was decided to leave as is for now. But we're always open to hearing feedback on how to improve the metrics.

One more point to note is that, if "no-op" interactions cause significant enough slowdown to impact INP, then it is highly likely that "real interactions" would also be impacted. In fact the overall INP score may go up if "no-op" interactions are excluded from the equation since these are likely the lowest interaction times but would be excluded for users that performed no other interaction.

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/0f9f4618-74da-4b45-aaeb-e2cf63df3912n%40googlegroups.com.

[Michal Mocny]

Barry's right: if "no-op" interactions are catching this slowdown, then "real interactions" are likely to do so, and probably be even slower.  Thus, you are receiving more signal to help diagnose real responsiveness issues.

But beyond that, even a claimed "no-op" interaction is almost always doing some operation:

• Some events will only begin fetch requests, or make storage updates, or trigger async effects... Although the event itself may not directly request paint, the completion of the work may very well still provide an important update for the user.  In such cases, measuring just input delay and event processing is still measuring important responsiveness.
• As Barry mentioned, the browser often has default actions, though most of these will do rendering work.  But not all side effects are visual: you may be starting audio, firing notifications, etc.
• Finally, even in the case where there is literally not a single event listener (which again, seems to not be the case on this page) and not a single default style applied to the interaction -- long running blocking tasks can still block accessibility features from running, which may be important especially after interactions.

In any case, it's hard to know when an interaction is really a "no-op for users", and so we measure every interaction.

(I do understand that sometimes that time to feedback wasn't actually visible to the user and so not indicative of overall experience, but hope you understand the many other cases where that is not true.)

-Michal

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

[Philip Walton]

While I'm sure it's true that most people opening NY Time pages just want to scroll and read content, keep in mind that many of those articles contain links to other articles, and if the reader clicks on one of those links while there's a long task executing on the main thread, the browser needs to wait for that task to finish before it can follow the link.

So even if there's no visible paint for some interactions, there are plenty of cases where a blocked main thread (or slow event handler code) can impact the experience in a way that is noticeable to the user. So that's why it is important to minimize main thread blocking time (which is what INP is attempting to measure and address).

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

[Matthew DeLambo]

I got a chance to dig into this today. The embedded sheet shows the top 10 poor INP scores grouped by selector, ordered by number of impressions. Ignore the first row with selector "undefined". 

Some interesting findings:

- 39% of events originated from non-interactive content, most likely clicks on text content or a body container

- Taking a weighted average of the non-interactive vs interactive scores, the non-interactive events look a lot higher at 2192 vs 1377. Interestingly, after eyeballing more results, the really high INP scores are more often for non-interactive content.

My theory is that for the LARGE group of "undefined" we would likely see a similar result because the body of our content gets re-rendered by React a couple times due to data updates as the app is loading.

[Michal Mocny]

Thank you for sharing this!

One thing to note: INP today when measured from PerformanceObserver API suffers from certain race conditions during document unload-- i.e. which comes first, unload or next paint?  Today you cannot measure Event Timings which are still in the middle of measurement at unload time (because you can no longer run JS).  (crbug). So at least for your hyperlink/nav results, I suspect the "real" p75 would be slightly higher (if you did measure those long-running interactions that were slower than unload).

Based on your description of the site, it sounds like the primary causes of responsiveness issues on these pages is just general main thread contention and rendering work.  Looking specifically at loading time TBT, a sample PSI run suggests there is room for improvement.  That means that no specific event handler or specific effects which follow interactions are the low hanging fruit.

You could test that hypothesis by trying to attribute your INP scores down into more concrete time breakdowns (input delay, processing times, rendering and presentation delays), as e.g. this workshop suggests.  This would tell you if event processing times are the culprit, or mostly just other stuff.

Alternatively, to just see if it is mostly just loading TBT, you could also just compare INP scores to the time of interaction to see if it correlates.

-Michal

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/8cf786cc-8d05-45da-9ebf-04a8238f2154n%40googlegroups.com.