Live data from Hacker News

Interaction to Next Paint (INP)

web.dev

51–60 of 77 posts

Re: Interaction to Next Paint (INP)

#51
post #25

This may be controversial but I think this has the potential to be a brilliant metric because it measures some part of web UX that’s often neglected. It’s time consuming to make every single interaction display some sort of loading message but it really helps make the site feel responsive. As long as they avoid the pattern of adding a global loading spinner that covers the whole screen. That’s just the worst possible…

> This may be controversial but I think this has the potential to be a brilliant metric because it measures some part of web UX that’s often neglected. It also seems to be a metric that is very easily gamed. If all that matters is instant feedback, then just draw that loader as soon as user clicks add to cart, do not wait for the request to start. It does not matter that it will take X or Y seconds.

> It also seems to be a metric that is very easily gamed.

Fun fact: the current JS-specific metric (which is being fazed out) is First Input Delay, and it was explicitly designed to avoid this gaming:

> FID only measures the "delay" in event processing. It does not measure the event processing time itself nor the time it takes the browser to update the UI after running event handlers. While this time does affect the user experience, including it as part of FID would incentivize developers to respond to events asynchronously—which would improve the metric but likely make the experience worse. > - https://web.dev/fid/

I wonder why they decided to reconsider this trade-off when designing INP.

Re: Interaction to Next Paint (INP)

#53
post #10

We started seeing reports about it in GSC early July, when over a single day all our scores turned to crap with no explanation. We are in the yellow, but the biggest culprits for blocking time are...Google Tag Manager, GAds (and Ganalytics where we still have it). So yeah, thanks Google, can't wait to lose on SEO due to your own products. And also, thanks for releasing this without the proper analysis tooling. ( http…

I for one commend Google's efforts to improve the web's chances of long-term survival by eliminating themselves and hopefully tracking in general.

It's hilarious how AMP pages have become a cesspool of JS dark patterns trying to bombard with you with as many ads as possible and keep you from escaping their site.

Re: Interaction to Next Paint (INP)

#55
post #25

This may be controversial but I think this has the potential to be a brilliant metric because it measures some part of web UX that’s often neglected. It’s time consuming to make every single interaction display some sort of loading message but it really helps make the site feel responsive. As long as they avoid the pattern of adding a global loading spinner that covers the whole screen. That’s just the worst possible…

[deleted]

Re: Interaction to Next Paint (INP)

#56
post #12
post #10

We started seeing reports about it in GSC early July, when over a single day all our scores turned to crap with no explanation. We are in the yellow, but the biggest culprits for blocking time are...Google Tag Manager, GAds (and Ganalytics where we still have it). So yeah, thanks Google, can't wait to lose on SEO due to your own products. And also, thanks for releasing this without the proper analysis tooling. ( http…

>We are in the yellow, but and biggest culprits for blocking time are...Google Tag Manager, GAds and GAnalytics. This has been the case for over a decade with Google's "Lighthouse" analysis tool as well. I used to use it as part of a site analysis suite for my clients - a good portion of the time, my smaller clients would end up deciding to replace Google Analytics entirely with a different product because of it.

If they can't give up Google Analytics or Google Ads, but still want the perf, give Cloudflare Zaraz a try. I am Product Specialist there, if you need an intro in person, happy to do it. Just reach out to me on Linkedin / twitter.

Re: Interaction to Next Paint (INP)

#57

At first glance, 200ms INP is a pretty high latency for a "good" rating. As a comparison, I believe 200ms is an average https roundtrip. I'd expect most interactions to be much lower than that.

That was my first impression too but then I thought about what it’s actually measuring: page responsiveness, not animation jank. I’m not going to expect a 16ms response or anything for every animation but much slower & you see jank. For page interactivity though? 0.2s is pretty damn fast. Human response time is 0.15-0.25s So it’s pretty reasonable

.2s is slow for a redraw. Just because it might take you 200ms to click after something happens doesn't mean you can't see/notice when things take that long.

Re: Interaction to Next Paint (INP)

#58

Earlier quoted context omitted.

Based on the fact that they're hooking into events like onclick, I'd say that they are not looking at traditional form submits, because then the metric would just effectively be First Contentful Paint or something. My interpretation is that they are indeed looking at first paint after an event handler has been fired on the same page.

This is correct (source: working in web perf for 5 years). INP is the time between you click/press a key/etc and the moment the next paint happens. It’s only measured for on-page interactions, not for navigations. It’s basically like http://danluu.com/input-lag/ but as a web metric.

Thanks for confirming, yeah that makes sense. Side note, that input-lag thing is a very cool resource.

Re: Interaction to Next Paint (INP)

#59

Earlier quoted context omitted.

That was my first impression too but then I thought about what it’s actually measuring: page responsiveness, not animation jank. I’m not going to expect a 16ms response or anything for every animation but much slower & you see jank. For page interactivity though? 0.2s is pretty damn fast. Human response time is 0.15-0.25s So it’s pretty reasonable

.2s is slow for a redraw. Just because it might take you 200ms to click after something happens doesn't mean you can't see/notice when things take that long.

I’m not saying it’s fast. I’m saying that based on the goal of what it is measuring (user input responsiveness) it’s fast enough. For the purposes of the metric anyhow.

Plus, speaking from far too long of a career dealing with user testing, respond too fast and users thing you didn’t actually do anything.

So you’re kind of boned either way. This is just measuring programmatic delay.

Re: Interaction to Next Paint (INP)

#60
I've generally had no gripes about this or web vitals in general except for one thing: group population[0]. It's unfair to create a blast radius on a small or medium-sized business's website simply because enough data doesn't exist to determine the true extent of the user experience impact.

The most recent example I've observed this on was a website with a heavy interactive location finder experience that lived on a single page. Fine, penalize that page. There's a chance users won't initially navigate there anyway. However, because a (very minimal, practically irrelevant amount of) similar content on the rest of the page was present on 18 other pages, the impact was huge.

The reality of the web today makes this pretty dire in my mind. Many businesses choose to run websites that are generally fast, but they have to engage with third-party services because they don't have the means to build their own map, event scheduler, or form experience. The punishment doesn't fit the crime.

[0]: https://www.searchenginejournal.com/grouped-core-web-vitals-...

Post reply on HN