Interaction to Next Paint (INP) is a Core Web Vital that measures how quickly a page responds to user interactions, from the moment of input to the moment the next frame is painted. It reports roughly the worst interaction latency across the whole page visit and replaced First Input Delay as a Core Web Vital in March 2024.
What Is Interaction to Next Paint?
Interaction to Next Paint, usually shortened to INP, is a responsiveness metric. Where load metrics care about how fast a page appears, INP cares about how fast the page reacts when a person actually uses it: clicking a button, tapping a menu, typing in a field, or opening an accordion.
It observes interactions throughout the entire visit, not just the first one, and reports roughly the worst experience at the 75th percentile of real users. That single number is what Google uses to judge whether your page feels responsive.
Why Did INP Replace First Input Delay?
First Input Delay only measured the input delay of the very first interaction, and only that delay, not the full work required to paint a response. Because most pages are idle by the time a user first clicks, almost every site passed FID comfortably.
INP covers all interactions and the full path to the next paint, including processing and presentation. That makes it far harder to game and far more representative of what users actually feel, which is why Google swapped it in as a Core Web Vital in March 2024. You can see how it sits alongside the other vitals in our Core Web Vitals fixes for startups breakdown.
How Is an Interaction Measined?
Every interaction INP measures is made of three sequential phases. The total latency is the sum of all three, and each phase points to a different cause and a different fix.
| Sub-part | What it covers | Typical causes | Primary fix |
|---|---|---|---|
| Input delay | Time from input until the event handler starts, while the main thread is busy | Long tasks, hydration, third-party scripts blocking the main thread | Break up long tasks and yield to the main thread |
| Processing time | Time spent inside the event handlers themselves | Heavy computation, fetching, state updates, re-renders in handlers | Move work out of handlers, debounce, show feedback first |
| Presentation delay | Time to style, layout, and paint the next frame | Layout thrashing, forced synchronous layout, large DOM, expensive CSS | Reduce DOM size, avoid forced reflow, simplify paint |
To read which part dominates, open a Performance trace and inspect the long task around the offending interaction. The slice before the handler runs is input delay; the handler block is processing time; the style and layout work after it is presentation delay. The fix changes depending on which slice is largest.
What Are Google'S Published INP Thresholds?
Google's thresholds are measured at the 75th percentile of real user visits, split by mobile and desktop, and a page is judged on the worse of the two. A good INP is 200 milliseconds or less.
- 200 ms or less is good.
- Between 200 ms and 500 ms needs improvement.
- Above 500 ms is poor.
These are field-data thresholds, not lab numbers. A clean local Lighthouse run means little if your real users on mid-range phones are hitting 600 ms because of tag-manager and hydration work.
Why Is INP Harder to Fix Than LCP?
Largest Contentful Paint is a load metric: it happens once, early, and mostly depends on page weight, server response, and image delivery. INP is a behavior metric, and that is what makes it stubborn.
It only surfaces after users do something, usually late in a session, and the cause is rarely raw page weight. The usual offenders are third-party scripts, client-side hydration, and heavy event handlers that fire on the main thread at the worst possible moment. That is also why INP tends to fail on mobile first, where CPU headroom is smallest. Our LCP guide covers the load side if you want the contrast.
How Do You Break Up Long Tasks to Lower Input Delay?
Input delay grows when the main thread is busy with a long task before your handler ever runs. The fix is to stop monopolizing the thread: split large synchronous chunks into smaller ones and yield between them so input can be processed.
- Break loops and batch jobs into chunks under 50 ms.
- Yield with scheduler.yield, or fall back to a setTimeout or requestIdleCallback style pattern for non-urgent work.
- Defer analytics, prefetch, and non-critical initialization until the user is idle or after first interaction.
The goal is headroom: when a click arrives, the thread should be free to handle it instead of finishing a 300 ms script.
How Do You Reduce Processing Time Inside Event Handlers?
Processing time is the work your own code does once a handler fires. The cheapest win is to do less of it, and to do it later.
- Avoid heavy work directly inside handlers; move it to after visual feedback is shown.
- Debounce or throttle expensive handlers, especially scroll, resize, and input events.
- Split state updates and re-renders so a single interaction does not recompute the whole tree.
Showing a spinner, optimistic UI, or an immediate class change before the heavy work runs is a legitimate and effective fix. Users perceive responsiveness the moment they see a frame change, even if the backend work continues afterward.
How Do You Cut Presentation Delay and Avoid Layout Thrashing?
Presentation delay is the time to turn the result of your handler into the next painted frame. The classic trap is layout thrashing: reading layout in a handler, then writing, then reading again, forcing the browser into repeated synchronous reflows.
Batch your DOM reads and writes, avoid forced synchronous layout inside handlers, reduce overall DOM size, and keep CSS selectors and paint costs modest. A smaller, flatter DOM and simpler style rules directly shorten the time from "handler done" to "frame painted."
How Should You Diagnose a Failing INP?
Fixing INP starts with field data, not a hunch. Follow this sequence before you touch code.
- Confirm failing INP in Google Search Console or CrUX field data rather than lab-only tools.
- Identify the failing URL group and the device class, since mobile is usually the failure point.
- Reproduce with the Web Vitals browser extension, which logs interaction attribution.
- Capture a Performance trace while performing the exact offending interaction.
- Read which sub-part (input delay, processing, or presentation) dominates the trace.
- Fix that specific sub-part using the matching technique above.
- Re-verify the change in field data before declaring victory.
Skipping the field-data confirmation is the most common mistake. Lab tools will not show you the third-party tag that only fires for real logged-in users.
Why Is Your Marketing Tool Stack Hurting INP?
Tag managers, analytics, chat widgets, consent tools, and A/B testing scripts are among the biggest INP offenders we see on startup sites. They inject main-thread work that competes directly with the interactions you want to feel fast.
Marketing tooling decisions are therefore responsiveness decisions. Audit the tag stack and ask what each script actually earns. Move what can move to server-side tagging, defer non-essential tags until after interaction, and drop or lazy-load anything that does not pull its weight. A chat widget that costs 400 ms of input delay on every click is a conversion problem, not just a performance metric. If your site is a single-page app, the SPA page speed guide shows where these scripts pile up.
What Is the Difference Between INP and FID?
The difference is scope. FID measured only the first interaction and only the input delay portion of it, which is why nearly every site passed. INP measures all interactions across the visit and the full path from input to the next painted frame, including processing and presentation.
In practice, FID told you almost nothing about real responsiveness, while INP reflects what a user feels when they click through your product. Treat FID as retired: INP is the metric that matters now for both search ranking and genuine UX.
Frequently Asked Questions
What Is a Good INP Score?
A good INP score is 200 milliseconds or less, measured at the 75th percentile of real user visits across mobile and desktop. Between 200 and 500 ms is considered needs improvement, and anything above 500 ms is poor. Because the threshold is field data, a fast local test does not guarantee a good score for your actual users on slower devices.
What Does INP Mean in Web Performance?
INP stands for Interaction to Next Paint, and it is a Core Web Vital that measures responsiveness, the delay between a user interaction and the next visual update. It captures roughly the worst interaction on a page rather than an average, so it reflects the moments users remember as feeling slow. It replaced FID in March 2024.
How Do You Improve Interaction to Next Paint?
You improve INP by attacking whichever sub-part dominates: break up long tasks and yield to free the main thread for input delay, move heavy work out of event handlers and debounce expensive ones for processing time, and avoid layout thrashing while reducing DOM size for presentation delay. Showing immediate visual feedback before heavy work is a valid and effective fix.
Why Is INP Harder Than Other Core Web Vitals?
INP is harder because it is not a load metric. It depends on what real users actually do during a session, so it surfaces late and is driven by behavior rather than page weight. Third-party scripts, hydration, and heavy event handlers cause most failures, and these are easy to miss in lab tests that do not replicate real interaction patterns.
Is INP a Ranking Factor?
Yes, INP is a Core Web Vital and part of Google's page experience signals, so poor INP can affect search rankings. More importantly, it reflects real responsiveness that influences bounce rate and conversion on the interactions that matter most. Treat it as both an SEO and a conversion issue, not just a developer metric.
Key Takeaways
- INP measures responsiveness from user input to the next paint and replaced FID as a Core Web Vital in March 2024.
- Good INP is 200 ms or less at the 75th percentile, with 200 to 500 ms needing improvement and above 500 ms poor.
- An interaction splits into input delay, processing time, and presentation delay, and the fix differs for each.
- Diagnosis must start in field data, then a Performance trace identifies which sub-part dominates.
- Marketing tags, analytics, chat widgets, and A/B scripts are major INP offenders and should be audited or moved server-side.
- FID only measured first-interaction input delay; INP covers all interactions and the full path to paint.