Debugging INP vs Input Delay

[Radek G]

Hi, 

lastly I'm struggling with some weird issues about INP metric. To debug that vital I am using Web Vitals plugin with console logging turned on. Since my first touch with INP and Core Web Vitals I can't understand the way that INP is gained around website. 

Most of issues I get with INP is Input Delay. When I compare it with some Performance Data, I can't relay it to any of code that is based on JS stuff. Every issue I had was based on use of keyboard. So there is an question - is it possible that INP might gain poor results according only to CSS selectors? If so, how can I improve that? 

Unfortunalety I cant share any URL. 

[Barry Pollard]

It's difficult to be able to answer your questions without any detail to be honest.

Input delay suggests something else was running on the main thread and blocking the event handler from being able to start processing. In this case the web vitals extension can't give a huge amount of information because the event itself was not the cause, but something else started before that. The interactions it also shows, that will include non INP interactions, may help if it was another interaction holding it up, but if it was something else then this won't give a full picture.

I would suggest using DevTools and doing a performance trace which should give you a fuller picture of what all is running. If you have further questions and can share some of those screenshots, even if you can't share the URL, then we might be able to help further.

Another API, for finding similar information in the field is the Long Animation Frame API, which again can give more context to all that was running in at the time of the INP.

[Radek G]

Thanks Barry for your reply. I dived into Performance Tab at DevTools, it's looks like this:

There is no one-by-one task during keydown input. That one function execution related task - at center of the screenshot - it's some data that is sent to GTM. Source of some little events are from CWV extension. After zooming in on processing time:

I still can't identify process that have such impact on INP and what I can do to improve CWV results depending on interaction.

[Barry Pollard]

I can't understand that screenshot myself to be honest!

I see it is mostly mad up of input delay (the whisker on the left side) but 1) the hover over indicates it's mostly rendering delay that's a problem not input delay, which doesn't match the screenshot, and 2) there appears to be nothing on the main thread to indicate why there was a long delay!

So I'm as confused as you to be honest!

Some more questions:

• Is this interaction definitely on the main thread and not on another thread (for an iframe perhaps, which will have it's own thread below the main one)?
• Are you using CPU throttling which may be messing up the trace timings (but really shouldn't to that extent!)?
• Can you try in a different Chrome (Chrome Beta or Chrome Dev) to see if you can replicate?

[Radek G]

Happy to read that I am not only one struggled with CWV (exactly INP) data issues (^_^' )

Answering up to the questions: 

• Is this interaction definitely on the main thread and not on another thread (for an iframe perhaps, which will have it's own thread below the main one)?

Yes, that's the only thread on the website. All interactions I made and described as poor responsive are made using fast-clicked tab on website.

• Are you using CPU throttling which may be messing up the trace timings (but really shouldn't to that extent!)?

No, I'm not. I'm simulating User interactions using pure incognito on Chrome 121.0.6167.85 at MacBook Pro, 13-inch, M1, 2020. I'm using desktop view on DevTools.

• Can you try in a different Chrome (Chrome Beta or Chrome Dev) to see if you can replicate?

That's might be interesting - I just downloaded Chrome Dev (123.0.6262.5) and I can't get same results like on Chrome 121. There is no issues with INP at all. But still - almost 100% of mobile traffic on GSC shows that INP is about to improvement. 

[Michal Mocny]

Czesc Radek,

In these situations it becomes necessary to trace the page using Perfetto instead of just DevTools.  That is because a large input delay without any main-thread activity is almost always a sign of the interaction being held up either in the platform (o/s) or in the browser process.

If you are comfortable sharing the trace with us we can try to diagnose it.  You can email us directly if that helps.

I would suggest using these tracing categories:

On Tue, Jan 30, 2024 at 7:28 AM Radek G <rade...@gmail.com> wrote:

Happy to read that I am not only one struggled with CWV (exactly INP) data issues (^_^' )

Answering up to the questions: 

• Is this interaction definitely on the main thread and not on another thread (for an iframe perhaps, which will have it's own thread below the main one)?

Yes, that's the only thread on the website. All interactions I made and described as poor responsive are made using fast-clicked tab on website.

• Are you using CPU throttling which may be messing up the trace timings (but really shouldn't to that extent!)?

No, I'm not. I'm simulating User interactions using pure incognito on Chrome 121.0.6167.85 at MacBook Pro, 13-inch, M1, 2020. I'm using desktop view on DevTools.

• Can you try in a different Chrome (Chrome Beta or Chrome Dev) to see if you can replicate?

That's might be interesting - I just downloaded Chrome Dev (123.0.6262.5) and I can't get same results like on Chrome 121. There is no issues with INP at all. But still - almost 100% of mobile traffic on GSC shows that INP is about to improvement. 

Glad to see there's an improvement, but I'm not aware of any change that would account for this.  Unless there was a specific platform-level improvement to reduce Browser-level jank which decreased input delay on the way to the Renderer?

I would guess it could also just be sporadic and may come back...

 

wtorek, 30 stycznia 2024 o 12:23:31 UTC+1 Barry Pollard napisał(a):

I can't understand that screenshot myself to be honest!

I see it is mostly mad up of input delay (the whisker on the left side) but 1) the hover over indicates it's mostly rendering delay that's a problem not input delay, which doesn't match the screenshot

I think that might just be an issue with internationalization?  Some countries use commas to denote decimals and periods to denote thousands' separators.  But it appears to be inconsitently applied.

(345 + 2.1 + 7.7 = 354.8ms which is the stated total)

 

, and 2) there appears to be nothing on the main thread to indicate why there was a long delay!

So I'm as confused as you to be honest!

Some more questions:

• Is this interaction definitely on the main thread and not on another thread (for an iframe perhaps, which will have it's own thread below the main one)?
• Are you using CPU throttling which may be messing up the trace timings (but really shouldn't to that extent!)?
• Can you try in a different Chrome (Chrome Beta or Chrome Dev) to see if you can replicate?

On Tuesday, January 30, 2024 at 11:18:13 AM UTC Radek G wrote:

Thanks Barry for your reply. I dived into Performance Tab at DevTools, it's looks like this:

There is no one-by-one task during keydown input. That one function execution related task - at center of the screenshot - it's some data that is sent to GTM. Source of some little events are from CWV extension. After zooming in on processing time:

I still can't identify process that have such impact on INP and what I can do to improve CWV results depending on interaction.

piątek, 26 stycznia 2024 o 12:38:05 UTC+1 Barry Pollard napisał(a):

It's difficult to be able to answer your questions without any detail to be honest.

Input delay suggests something else was running on the main thread and blocking the event handler from being able to start processing. In this case the web vitals extension can't give a huge amount of information because the event itself was not the cause, but something else started before that. The interactions it also shows, that will include non INP interactions, may help if it was another interaction holding it up, but if it was something else then this won't give a full picture.

I would suggest using DevTools and doing a performance trace which should give you a fuller picture of what all is running. If you have further questions and can share some of those screenshots, even if you can't share the URL, then we might be able to help further.

Another API, for finding similar information in the field is the Long Animation Frame API, which again can give more context to all that was running in at the time of the INP.

On Friday, January 26, 2024 at 11:29:35 AM UTC Radek G wrote:

Hi, 

lastly I'm struggling with some weird issues about INP metric. To debug that vital I am using Web Vitals plugin with console logging turned on. Since my first touch with INP and Core Web Vitals I can't understand the way that INP is gained around website. 

Most of issues I get with INP is Input Delay. When I compare it with some Performance Data, I can't relay it to any of code that is based on JS stuff. Every issue I had was based on use of keyboard. So there is an question - is it possible that INP might gain poor results according only to CSS selectors? If so, how can I improve that? 

Unfortunalety I cant share any URL. 

--
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/6868352a-6a46-42da-b908-cb0bbd52b36an%40googlegroups.com.