Core Web Vitals get treated like a report-card exercise: run the test, screenshot the green scores, move on. That stops working once Interaction to Next Paint (INP) is the metric doing the judging, because INP punishes decisions made deep inside how a page is built, not just how fast the first pixel appears.
What actually changed
First Input Delay only measured the first click or tap on a page, so a site could pass while every interaction after that first one felt sluggish. INP measures the slowest interaction across the entire visit - the tenth click counts as much as the first. A site can post a fast Largest Contentful Paint and still fail INP if a filter, a modal, or an "add to cart" button responds late.
Where INP actually breaks in practice
- Large third-party scripts - chat widgets, analytics, ad tags - blocking the main thread right when a visitor tries to interact
- JavaScript frameworks re-rendering more of the page than the interaction actually changed
- Image and font loading competing with interaction handlers for the same thread
- Event handlers doing expensive work synchronously instead of breaking it into smaller tasks
What we check on every build
Every web development project we scope now starts with a third-party script audit, because that is where most of the INP budget quietly disappears. After that: component-level code splitting so an interaction only re-renders what actually changed, deferred non-critical scripts, and real device testing rather than trusting a lab score from a fast office laptop.
“A fast homepage with a slow checkout is a slow site, because Google measures the page a visitor is actually on - not your best page.”
If your site was built more than a couple of years ago, there is a good chance nobody has looked at this since launch. Worth a proper audit before it shows up as a ranking problem instead of a performance one - get in touch and we will tell you honestly what we find.