INP: The Core Web Vital That’s Quietly Costing You Rankings

There’s a Core Web Vital that quietly became part of Google’s page experience signals, that is hardest to pass on mobile, and that few business owners have heard of. It’s called INP, Interaction to Next Paint. If your site feels laggy when people tap buttons or open menus on a phone, this is the metric measuring it, and Google is watching.

What INP is, and why it replaced FID

In March 2024, Google replaced its old responsiveness metric, First Input Delay (FID), with Interaction to Next Paint (INP) as an official Core Web Vital. The reason: FID only measured the delay before the first interaction was processed, a low bar most sites passed easily. INP is far stricter. It measures how quickly your page visually responds across the full lifecycle of a visit, every tap, click and key press, and reports one of your worst interactions. In short, FID asked “did the page react?”; INP asks “did the page react quickly, every time?”

The numbers that matter

Per Google’s own documentation, the Core Web Vitals “good” thresholds are:

• INP (responsiveness): under 200 milliseconds
• LCP (loading): under 2.5 seconds
• CLS (visual stability): under 0.1

INP is measured at the 75th percentile of real visits, so you can’t pass by being fast for some users; you have to be responsive for most of them. An INP between 200 ms and 500 ms “needs improvement”; over 500 ms is “poor”. And because INP captures the worst moments of a session, the metric many sites comfortably passed under FID, they now fail under INP, especially on mid-range Android phones.

What actually causes a bad INP

INP problems are almost always a JavaScript problem. When someone taps a button, the browser has to run your scripts before it can paint a response. If the main thread is clogged, the screen freezes for a beat, and that beat is your INP score. Common culprits:

• Heavy, bloated JavaScript bundles and too many third-party scripts (chat widgets, trackers, ad tags, marketing pixels).
• Page builders and plugin-stacked WordPress sites loading scripts on every page whether they’re needed or not.
• Long “tasks” that block the browser from responding to taps.
• Expensive work fired on every interaction instead of being deferred or broken up.

How to fix it

The good news: INP is very fixable, and the fixes also make your whole site feel faster. In rough order of impact:

• Cut the JavaScript. Remove scripts you don’t need, and load the rest only where they’re actually used. This single step fixes most INP failures.
• Tame third parties. Audit every chat box, tracker and pixel, each one runs code on your users’ phones. Defer or drop the non-essential.
• Break up long tasks so the browser can respond to taps between chunks of work.
• Measure real users, not lab tests. Use Google’s Search Console Core Web Vitals report and field data (CrUX), because INP only shows its true colours on real devices.
• Be wary of heavy themes and plugins. On WordPress, the fastest INP fix is often a leaner build rather than another optimisation plugin layered on top.

Why this is worth your attention

Core Web Vitals are a genuine, if modest, Google ranking factor, and they’re a tie-breaker in competitive results. But the bigger prize is conversion: a page that responds instantly to a tap feels trustworthy and keeps people moving toward an enquiry or sale. A laggy one bleeds customers long before Google’s ranking maths even comes into play. INP is where “it just feels slow” becomes a number you can fix.

If your site stutters on a phone, that’s INP, and it’s costing you both rankings and customers. We build sites lean by default: minimal JavaScript, no plugin bloat, and Core Web Vitals in the green from day one.

Sources: Google Search Central, “Understanding Core Web Vitals and Google Search results” (LCP 2.5s, INP 200ms, CLS 0.1 thresholds) and the Search Central blog announcement introducing INP as a Core Web Vital, replacing FID in March 2024.