What is Interaction to Next Paint (INP)?
Why INP replaced FID in 2024, how it measures the full latency of every interaction, what a busy main thread does to it, and how to keep that thread free to respond.
Interaction to Next Paint (INP) measures responsiveness: how quickly a page visibly reacts when someone taps, clicks, or presses a key. It watches every interaction across the whole visit and reports how long the slowest ones take to produce a visible change on screen. INP is one of the three Core Web Vitals, it replaced First Input Delay in March 2024, and a good score is 200 milliseconds or less.
What INP actually measures
Every interaction has three phases, and INP measures all of them end to end. Input delay: the time before the browser can even start handling the event, usually because the main thread is busy with other JavaScript. Processing time: how long your event handlers take to run. Presentation delay: the time to render the resulting visual change to the screen. INP is the full span from the tap to the “next paint” that shows the result. A page can have a fast input delay — which is all FID ever measured — and still feel sluggish because the processing and rendering that follow are slow.
INP versus FID
First Input Delay only measured the input-delay phase of the first interaction on the page. That is a narrow slice: it ignored everything after the browser started processing, and it ignored every interaction but the first. Most pages passed FID comfortably, which made it a weak signal. INP is the honest version — the complete latency of interactions throughout the visit. This is why many sites that sailed through FID do not pass INP, and why the switch mattered rather than being a rename.
The common causes of poor INP
INP problems are almost always about the main thread — the single thread where the browser runs JavaScript and updates the page. If it is busy, interactions wait. Long JavaScript tasks that monopolize the thread are the primary cause. Heavy event handlers that do too much work synchronously on every click or keypress. Third-party scripts — analytics, tag managers, chat widgets, ads — competing for the same thread. A large or complex DOM that makes every render expensive. Excessive re-rendering in JavaScript frameworks that redo more work than the interaction required.
How to improve it
The goal is to keep the main thread free to respond. Break up long tasks into smaller pieces and yield to the main thread between them — modern code can use scheduler.yield() or fall back to yielding manually — so the browser can handle a pending interaction rather than finishing a 300 ms block first. Defer non-critical JavaScript so it is not competing during the moments a user is most likely to interact. Audit third-party scripts and remove or delay the ones that do not earn their cost. Move heavy computation off the main thread into a web worker. And do the minimum work necessary in the handler itself: update what the user needs to see now, and schedule the rest for later.
How to check yours
INP is best measured in the field, because it needs real people performing real interactions — a synthetic test that never clicks anything cannot produce a true INP. Our Core Web Vitals checker reads your real-user INP from field data, which is what Google scores. In the lab, the page speed checker reports Total Blocking Time, the standard lab proxy for responsiveness: it measures how long the main thread was blocked during load, which is the same underlying problem INP exposes. Reduce Total Blocking Time in the lab, and your field INP should follow over the next few weeks.
Frequently asked questions
- What is Interaction to Next Paint (INP)?
- INP is a Core Web Vital that measures responsiveness — how quickly a page visibly reacts to taps, clicks, and key presses across the whole visit. It captures the full latency from an interaction to the next screen update, and reports roughly the slowest interaction. A good INP is 200 milliseconds or less at the 75th percentile of real visitors.
- What is a good INP score?
- 200 milliseconds or less is good, between 200 and 500 milliseconds needs improvement, and above 500 milliseconds is poor. Like the other Core Web Vitals, it is measured at the 75th percentile of your page loads in field data from real Chrome users.
- What is the difference between INP and FID?
- First Input Delay measured only the input-delay phase of the first interaction on a page — a narrow slice that most pages passed easily. INP measures the complete latency, including processing and rendering, of interactions throughout the entire visit and reports the worst. INP replaced FID as a Core Web Vital on 12 March 2024 because it reflects real responsiveness far more honestly.
- What causes poor INP?
- Poor INP is almost always a busy main thread. The usual causes are long JavaScript tasks that monopolize the thread, heavy event handlers doing too much work on each interaction, third-party scripts like analytics and chat widgets competing for the thread, a large or complex DOM, and frameworks re-rendering more than an interaction requires.
- How do I improve INP?
- Keep the main thread free to respond: break long JavaScript tasks into smaller pieces and yield between them, defer non-critical JavaScript, audit and remove or delay costly third-party scripts, move heavy computation into a web worker, and do the minimum work in each event handler — update what the user needs to see immediately and schedule the rest for later.
- Can I measure INP in a lab test?
- Not fully. A true INP needs real people performing real interactions, so a synthetic lab test that never clicks anything cannot produce one. In the lab, Total Blocking Time is the standard proxy — it measures how long the main thread was blocked during load, which is the same root problem INP exposes. Reduce Total Blocking Time and your field INP should improve over the following weeks.