41–50 of 77 posts
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!
Google's one (of many) heads has no idea what another (of many) heads says or does.
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.
With their engineering leader [1] arguing that 2.4s to display text and images is fast, no wonder they present "people still spend time on websites after they have spent an eternity loading" as a surprising find.
[1] https://twitter.com/addyosmani/status/1678117107597471745?s=...
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.
I guess it depends on how your interactions are implemented. If it’s an SPA then 200ms is absurdly slow. But if it’s a more traditional form submit or something then it would take a lot longer for your next set of pixels to comes through.
Earlier quoted context omitted.
I guess it depends on how your interactions are implemented. If it’s an SPA then 200ms is absurdly slow. But if it’s a more traditional form submit or something then it would take a lot longer for your next set of pixels to comes through.
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.
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.
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!
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 incrementally move from there. Regardless, the added complexity of SSR->SPA and other various hybrid schemes can quickly eat into your technical bullshit budget and before you know it that ancient forms app feels like lightning compared to the mess you proposed.
Reaching for SPA because you think this will make the site "faster" is pretty hilarious to me. I've never once seen a non-trivial (i.e. requires server-side state throughout) SPA that felt better to me than SSR.
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.
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.
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…
Have you used doordash.com? I don't know how they do it, but they manage to exceed 200ms on every single click, easily. And they're not alone.
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…