Interaction to Next Paint (INP)

We started seeing reports about it in GSC early July, when over a single day all our scores turned to crap with no explanation.<p>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&#x27;t wait to lose on SEO due to your own products. And also, thanks for releasing this without the proper analysis tooling. (<a href="https:&#x2F;&#x2F;web.dev&#x2F;debug-performance-in-the-field&#x2F;#inp" rel="nofollow noreferrer">https:&#x2F;&#x2F;web.dev&#x2F;debug-performance-in-the-field&#x2F;#inp</a> : this is not tooling, this is undue burden on developers. Making people bundle an extra [&quot;light&quot; library](<a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;web-vitals" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;web-vitals</a>) with their clients, forcing them to build their own analytics servers to understand what web-vitals complains about...or is often wrong about)

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.<p>As long as they avoid the pattern of adding a global loading spinner that covers the whole screen. That’s just the worst possible loading screen. I suppose it would still pass this metric.<p>Also I’m not sure if I totally understand the metric - I think it’s simply when the next frame is rendered post interaction, which should easily be under 200ms unless you’re<p>1. doing some insane amount of client side computation<p>2. talking over the network far away from your service or your API call is slow &#x2F; massive<p>and both of these are mitigated by having any loading indication so I don’t understand how this metric will be difficult to fix.

I&#x27;m lacking lots of context obviously but: What good is a sophisticated metric when the pages they index are mostly blogspam SO clones etc? I&#x27;m not interested in the &quot;most responsive&quot; SO clone. Seems out of touch with what Google search is struggling with these days.

The real metric: INP with ad blocking enabled.<p>Example: NYTimes.com on Mobile Safari with AdGuard. 18 seconds.<p>Google is being really disingenuous with its so called metrics. A stroke of the pen could make INP 200ms across the top 500 sites.

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

I&#x27;ve generally had no gripes about this or web vitals in general except for one thing: group population[0]. It&#x27;s unfair to create a blast radius on a small or medium-sized business&#x27;s website simply because enough data doesn&#x27;t exist to determine the true extent of the user experience impact.<p>The most recent example I&#x27;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&#x27;s a chance users won&#x27;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.<p>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&#x27;t have the means to build their own map, event scheduler, or form experience. The punishment doesn&#x27;t fit the crime.<p>[0]: <a href="https:&#x2F;&#x2F;www.searchenginejournal.com&#x2F;grouped-core-web-vitals-scoring&#x2F;407899&#x2F;#close" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.searchenginejournal.com&#x2F;grouped-core-web-vitals-...</a>

See also: <a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;inp-get-ready-for-the-new-core-web-vital&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;inp-get-ready-for-the-new-core-w...</a>

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

Absolutely love how one company dictates how you should build your websites. Love it!

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&#x27;t quite prove that our various LCP&#x2F;CLS&#x2F;FID&#x2F;INP changes are actually making any difference.

Meanwhile &quot;Engineering Leader&quot; at Chrome argues that 2.4s to First Contentful Paint is fast: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;addyosmani&#x2F;status&#x2F;1678117107597471745?s=20" rel="nofollow noreferrer">https:&#x2F;&#x2F;twitter.com&#x2F;addyosmani&#x2F;status&#x2F;1678117107597471745?s=...</a><p>Google&#x27;s one (of many) heads has no idea what another (of many) heads says or does.

To me it sounds like this will help pattern of showing a skeleton screen when loading data. <a href="https:&#x2F;&#x2F;www.smashingmagazine.com&#x2F;2020&#x2F;04&#x2F;skeleton-screens-react&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.smashingmagazine.com&#x2F;2020&#x2F;04&#x2F;skeleton-screens-re...</a>

So... Chrome is going to officially spy on their users and report that data to Google?

Will Firefox support it?

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