Core Web Vitals After INP: What Actually Moves the Metric
INP, Interaction to Next Paint, replaced First Input Delay as a Core Web Vital. It is the metric most teams find hardest, because unlike loading speed you cannot fix it once and forget it. INP measures responsiveness across the whole visit, and the work that moves it is almost entirely about JavaScript on the main thread.
What changed with INP
FID only measured the delay before the browser started processing your first interaction. It was easy to pass and told you little. INP is stricter. It looks at the latency of interactions throughout the visit and reports a value near the worst one. A page that felt fine under FID can fail INP, which is why so many teams saw their scores move when the switch happened.
What INP actually measures
INP is the time from a user interaction, a tap, click, or key press, to the next frame the browser paints in response. It captures the full path: the input delay before processing, the time to run your event handlers, and the delay before the next paint. A good INP is under 200 milliseconds, measured from real users in the field.
| Part of INP | What it is | Common cause of delay |
|---|---|---|
| Input delay | Wait before the handler runs | Main thread busy with other tasks |
| Processing time | Running your event handlers | Heavy or synchronous handler logic |
| Presentation delay | Time to paint the next frame | Large DOM updates and layout work |
Scroll table horizontally →
What moves the metric
INP is a main-thread problem. The wins come from doing less work, and doing it without blocking. In rough order of impact:
- Break up long tasks so the main thread is free to respond to input.
- Reduce and defer non-critical JavaScript, especially third-party scripts.
- Yield to the main thread during heavy work instead of running it all at once.
- Keep event handlers light, and move expensive work off the interaction path.
- Trim excessive DOM size, which makes every update and paint more expensive.
// Instead of one long task, yield so input can be handled
async function processInChunks(items) {
for (const item of items) {
doWork(item);
// let the browser respond to pending interactions
await new Promise((r) => setTimeout(r, 0));
}
}What does not move it
This is where sprints get wasted. Image optimisation helps LCP, not INP. Layout tweaks help CLS, not INP. Shaving a few kilobytes off CSS does little for responsiveness. And chasing a green Lighthouse score in the lab proves nothing, because Lighthouse does not measure INP the way the field does. If a change does not reduce main-thread work during interactions, it will not move INP.
Third-party scripts deserve special suspicion. Tag managers, chat widgets, and analytics bundles frequently dominate main-thread time and wreck INP while contributing nothing to it that you would miss.
The third-party script tax
On most sites that fail INP, the biggest single cause is scripts the marketing team added, not code the engineers wrote. Tag managers, A/B testing tools, chat widgets, heatmap recorders, and analytics bundles all run on the main thread, and several of them attach their own event handlers to every interaction. Each one adds a little latency to every tap, and together they can push a page over the INP threshold on their own.
The awkward part is that these scripts rarely belong to the people fixing INP, so the fix is as much a conversation as a code change. Start by measuring the cost: record an interaction in the Performance panel and see which scripts own the long tasks. Then work through the list honestly. Does that heatmap tool earn its INP cost? Can the tag manager load fewer tags, or load them after interaction? Can the chat widget be deferred until the user shows intent?
A useful rule is that every third-party script should justify its place against the responsiveness it costs. Many cannot, once someone actually measures them. Removing two unused tags often does more for INP than a week of refactoring your own JavaScript, and it is a far cheaper change to ship.
How to debug it
Start in the field. The Chrome UX Report and the Core Web Vitals report in Search Console tell you which pages fail and on which devices, usually mobile. Then reproduce with the Performance panel in Chrome DevTools, record an interaction, and look for the long tasks blocking the main thread. Real user monitoring that attributes INP to specific interactions is the most useful tool of all on a complex app.
Remember the field data is a 28-day rolling window, so a shipped fix takes weeks to show fully in Search Console. Confirm the improvement in the lab and in real user monitoring first, then let the field catch up.
The takeaway: INP is a JavaScript and main-thread problem, not an images or layout problem. Focus on reducing and deferring work, breaking up long tasks, and auditing third-party scripts, and ignore the changes that only move other metrics. If INP is failing across templates, our Core Web Vitals engagement finds the main-thread offenders, and if the root cause is a heavy client-side app, our post on what Google renders is worth a read too.