INP (Interaction to Next Paint) is the Core Web Vital that measures your page's responsiveness: the time between a user clicking, tapping, or pressing a key and the browser displaying the next visual frame in response. The lower, the better.
Since March 2024, INP has officially replaced FID (First Input Delay) as the interactivity metric in Google's Core Web Vitals. Unlike FID, INP evaluates every interaction during the session, not just the first one.
INP vs FID: Why Did Google Change the Metric?
FID only measured the delay before the browser processed the very first interaction. It was useful as an initial load signal, but it ignored everything that happened after: menu clicks, form submissions, internal searches. Many sites had an excellent FID and still responded slowly during normal browsing.
INP corrects that blind spot by measuring the interaction with the highest latency during the entire session. This better reflects the real user experience throughout a visit.
Which Interactions Does INP Count?
- Mouse clicks
- Touchscreen taps
- Keyboard presses
Scrolling and hovering do not count for INP, as they don't generate "response frames" in the same way.
How INP Is Calculated
For each qualifying interaction, the browser measures three phases:
- Input delay: the time from the interaction until the main thread is free to process it.
- Processing time: how long the JavaScript event handlers take to run.
- Presentation delay: the time from when the handlers finish until the browser paints the next frame.
The sum of all three phases is that interaction's latency. The final INP score is the latency of the worst interaction in the session (with a small statistical margin to ignore extreme outliers in sessions with very many interactions).
Google's Thresholds
| INP Score | Rating |
|---|---|
| 200 ms or less | Good |
| Between 200 ms and 500 ms | Needs improvement |
| More than 500 ms | Poor |
The goal is an INP of 200 ms or less. Above 500 ms, users perceive the page as clearly slow and unresponsive.
What Causes a High INP?
The root cause is almost always a blocked main thread. When JavaScript is busy running long tasks, user interactions queue up and wait their turn.
Long JavaScript Tasks
Any task that occupies the main thread for more than 50 ms is considered a "long task." Third-party scripts — analytics, live chat, advertising, social media widgets — are the primary culprits. Poorly optimized first-party code is also a factor: heavy loops, inefficient rendering, or costly synchronous calculations.
Heavy Event Handlers
Doing too much work inside a click or keypress handler directly increases the processing time. If clicking a button triggers a synchronous API call, a full layout recalculation, or manipulation of hundreds of DOM nodes, the INP climbs.
High Presentation Delay
Even if handlers finish quickly, if the browser has to calculate a complex layout or render many new elements before painting the next frame, the presentation delay spikes. Reducing the number of elements affected by each interaction helps here.
How to Diagnose Your INP
You need real user data to properly diagnose INP:
- PageSpeed Insights — shows the INP at the 75th percentile of your real users (CrUX data). This is your starting point.
- Search Console → Core Web Vitals — groups your site's URLs by INP status using real user data.
- Chrome DevTools → Performance — record an interaction session. Each interaction appears as a block on the timeline. Find the longest blocks and expand them to see which phase is losing time.
- PerformanceObserver API — implement
new PerformanceObserver()with the'event'type to log interaction latencies from real users in production.
Chrome's Performance panel also highlights "long tasks" in red on the main thread — that's where you should start investigating.
How to Improve INP
Improving INP means freeing up the main thread so it can respond to interactions faster. These are the most effective strategies:
1. Break Up Long Tasks
Split heavy work into smaller tasks using setTimeout(fn, 0) or the scheduler.yield() API (where available). This gives the browser the opportunity to process pending interactions between tasks.
2. Lazy-Load Third-Party Scripts
Analytics, advertising, and social scripts are often the number-one source of long tasks. Load them with defer or async, or better yet, delay them until after the user's first click using the "facade" technique — a placeholder element that loads the real script only when the user interacts with it.
3. Optimize Your Event Handlers
Move heavy work out of the main handler. If you need to process data after a click, use requestAnimationFrame for visual work and offload the rest to a Web Worker. Avoid mass DOM manipulation inside a handler.
4. Reduce DOM Size
A DOM with thousands of nodes makes every layout recalculation slower. Aim for fewer than 1,500 total nodes and use virtualization for long lists (render only the visible items).
5. Use CSS for Animations and Transitions
CSS transitions run on the compositor thread, not the main thread, so they don't affect INP. Whenever possible, delegate animations to CSS instead of JavaScript.
If your site has a problematic INP and you're not sure where to start, a web performance specialist can pinpoint exactly which long tasks are hurting your score.
Also check out our complete web performance guide to see all the metrics in context.
INP's Impact on SEO and Conversion
With FID's replacement in March 2024, INP is now an active ranking signal in Google. A poor INP in a competitive niche can cost you positions against competitors with a better user experience.
The impact on conversion is even more direct: if a user clicks "Add to Cart" and the page takes 800 ms to visually react, the feeling that "something didn't work" increases abandonment. Google studies show that sites with a good INP have significantly higher conversion rates than those with a poor INP.
Key Takeaways
- INP measures the latency of the worst interaction in the session; the target is 200 ms or less.
- It replaced FID in March 2024 because it evaluates the entire session, not just the first interaction.
- The most common root cause is the main thread blocked by long JavaScript tasks.
- Third-party scripts (analytics, ads, social) are the usual suspects.
- To improve INP: break up long tasks, lazy-load third-party scripts, and optimize your event handlers.
Is your INP above 200 ms? Contact us at elenlace.com and we'll run a performance audit to pinpoint exactly what's blocking your main thread.
FAQ
Does INP affect all types of websites?
Yes, but it matters most for highly interactive sites: e-commerce stores, complex forms, Single Page Applications (SPAs), and media sites with search bars or filters. A static blog with minimal JavaScript rarely has INP problems.
Why is my INP good in lab tools but poor in field data?
Lab tools (Lighthouse, DevTools) simulate controlled conditions with few active scripts. Field data reflects real users with browser extensions, variable connections, and long sessions where JavaScript accumulates work. Always prioritize field data for INP.
Can a 200 ms INP be achieved on heavily JavaScript-driven sites?
Yes, with the right techniques. The most demanding sites in the world — Gmail, YouTube, Amazon — maintain acceptable INP by splitting work into small tasks, using Web Workers for heavy computation, and lazy-loading third-party scripts.
Does INP measure only the visual response time or also internal processing?
INP measures the total time from the interaction to the next painted frame, which includes the input delay, processing time, and presentation delay. It does not measure what happens after that first frame (for example, a subsequent animation) — only the immediate visual response.
Further reading
Other providers and guides worth comparing:
