Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interaction to Next Paint (INP)

web.dev

Post reply on HN
Print view View original

61–70 of 77 posts

Re: Interaction to Next Paint (INP)

#61

Post by diroussel »

bob1029 wrote: post #46
benmccann wrote: post #16

INP feels like a pretty problematic way to compare sites because INP is going to be way lower on a site that doesn't do client-side rendering eventhough client-side rendering makes interaction with a site faster!

> client-side rendering makes interaction with a site faster! I am going to have to disagree. Final HTML from the server is just that. Its final. The client displays it and its done. No XHR, no web sockets, no JS eval. It's done. You can immediately use the webpage and the webserver doesn't care who you are anymore. With SPA, this is the best case. You maybe even start with SSR from the server and try to incrementall…

> I've never once seen a non-trivial (i.e. requires server-side state throughout) SPA that felt better to me than SSR.

What about gmail? That has all the state server side. How impressive would it be if all rendering was done server side?

Re: Interaction to Next Paint (INP)

#62

Post by minorninth »

wielebny wrote: post #28
haburka wrote: 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.

Honestly, displaying a loader as soon as I click add to cart would be an improvement on many sites. I'd welcome it.

A site that genuinely responds quickly is best. But for a slow site, I'd always prefer one that at least gives me instant feedback that I clicked something over one that doesn't.

Re: Interaction to Next Paint (INP)

#63

Post by crazygringo »

wielebny wrote: post #28
haburka wrote: 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.

But what you're describing as "gaming" is precisely the behavior this is supposed to incentivize.

Of course you should be setting a visual "in progress" state before you send out a request. And yes that's supposed to be instantaneous, not measured in "X or Y seconds". That's the entire point, to acknowledge that the user did something so they know they clicked in the right place, that another app hadn't stolen keyboard focus, etc.

Re: Interaction to Next Paint (INP)

#64

Post by deafpiano »

axlee wrote: 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…

Easy solution, remove all that adware crap.

Re: Interaction to Next Paint (INP)

#65

Post by jgalt212 »

devmor wrote: post #12
axlee wrote: 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.

has anyone had any luck with partytown?

https://partytown.builder.io/

Re: Interaction to Next Paint (INP)

#66

Post by cpncrunch »

axlee wrote: 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…

Thanks for this, you just solved my problem! I got an email about this INP thing this morning, but google had zero explanation why our INP timings were so high for a page that does practically nothing. I realised that I had removed analytics from our site last year, but I'd forgotten about this particular page, so that probably explains it.

Re: Interaction to Next Paint (INP)

#67

Post by Khoth »

wfhBrian wrote: post #18

Starts strong: > Chrome usage data shows that 90% of a user's time on a page is spent after it loads Clearly impressive, breakthrough, research going on at Google.

Or to put it another way, people waste 10% of their time on the web waiting for slow bloated garbage to load (or more when you take into account pages that do more loading when you touch them afterwards)

Re: Interaction to Next Paint (INP)

#68

Post by tunesmith »

Has anyone been able to demonstrate to their satisfaction that improving Web Vitals scores actually improves their search engine placement? We send web vitals field data to our own analytics servers to track P75, but Google changes its algorithm so much we can't quite prove that our various LCP/CLS/FID/INP changes are actually making any difference.

Re: Interaction to Next Paint (INP)

#69

Post by troupo »

iamakulov wrote: post #48
troupo wrote: post #42

Meanwhile "Engineering Leader" at Chrome argues that 2.4s to First Contentful Paint is fast: https://twitter.com/addyosmani/status/1678117107597471745?s=... Google's one (of many) heads has no idea what another (of many) heads says or does.

Isn’t that tweet talking about 2.4s for Largest Contentful Paint? It mentions 0.9 for FCP being fast, which I agree is pretty reasonable.

Funnily enough I clearly remember typing Largest Contentful Paint. But it turns out I typed First :)

My point still stands.

"The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page's content is rendered on the screen." [1]

Unless your server is overwhelmed, and can't send back data fast enough, there's literally no way to call "1 second before anything is rendered on screen is fast".

In the context of the tweet this is even more egregious. They were talking about Reddit's yet another redesign, and how it was fast. Reddit is a website that displays text and images. Their server responds in 200 milliseconds max. And yet, they were talking about how spending 0.9 seconds to display some info (menu on the left?), and 2.4 seconds to display actiual content is fast.

And that comes from "engineering leader at Chrome". We are at a point in time where people literally don't understand what fast is.

[1] https://web.dev/fcp/

Re: Interaction to Next Paint (INP)

#70

Post by youngtaff »

benmccann wrote: post #16

INP feels like a pretty problematic way to compare sites because INP is going to be way lower on a site that doesn't do client-side rendering eventhough client-side rendering makes interaction with a site faster!

People don’t care whether your site is server or client rendered… they care about fast interactions
Post reply on HN