Quick answer
Interaction to Next Paint measures how quickly a page visibly responds after a tap, click or key press, and it replaced First Input Delay as a Core Web Vital in March 2024. Measure it with field data, identify the slow interaction, then fix input delay, processing time or presentation delay by breaking up long JavaScript tasks.
A web.dev case study (2023) reports that redBus improved page INP by 72 per cent, which the case study describes as a 7 per cent overall increase in sales.
Interaction to Next Paint (INP) measures how quickly your page visibly responds when someone taps, clicks or types, and it replaced First Input Delay as a Core Web Vital in March 2024. To improve it you need to find which interactions are slow for real visitors, work out which part of the delay is to blame, and then break up or remove the JavaScript work standing in the way. This guide walks through that process step by step.
Why INP replaced First Input Delay
First Input Delay (FID) only measured one thing: the wait before the browser could start handling the very first interaction on a page. It ignored how long the handler itself took to run, it ignored how long the browser took to paint the result, and it ignored every interaction after the first. A page could pass FID comfortably while its filters, menus and add-to-basket buttons felt sticky for the rest of the visit.
INP fixes those gaps. It observes clicks, taps and key presses throughout the whole visit and measures the full time from the user’s input until the browser paints the next frame showing a response. The value reported for a page reflects one of its slowest interactions, so a single heavy button can drag the whole page down. Scrolling and hovering are not counted.
Google made the switch official in March 2024, so INP now sits alongside Largest Contentful Paint and Cumulative Layout Shift in the Core Web Vitals assessment. For a refresher on how the three fit together, see my explainer on what Core Web Vitals are and why they matter.
INP thresholds
- Good: 200 milliseconds or less.
- Needs improvement: above 200 ms and up to 500 ms.
- Poor: above 500 ms.
As with the other Core Web Vitals, the assessment is based on field data from real Chrome users, judged at the 75th percentile of visits. That means the experience on mid-range and older phones matters a great deal, because those devices have far less processing power than the laptop you are probably testing on.
The three parts of every slow interaction
The single most useful idea for fixing INP is that every interaction’s latency splits into three phases. Each phase has different causes and different fixes, so diagnose before you optimise.
| Phase | What is happening | Typical culprits |
|---|---|---|
| Input delay | The user has tapped, but the main thread is busy with something else, so the event handler cannot start | Long tasks from third party scripts, analytics, hydration, timers running in the background |
| Processing duration | Your event handlers are running | Heavy handler logic, synchronous state updates that re-render large parts of the page, layout thrashing |
| Presentation delay | Handlers have finished, and the browser is calculating styles, layout and paint for the next frame | Very large DOM, expensive CSS, rendering big lists, complex layouts recalculated on every change |
If most of the time is input delay, the fix is elsewhere on the page: something else is hogging the main thread. If it is processing duration, the handler itself needs work. If it is presentation delay, the page is too heavy to re-render quickly.
Step by step: measuring INP with field data
Lab tools struggle with INP because it depends on real people interacting with real pages. Lighthouse’s default page load test does not interact with the page at all, so it cannot report INP; Total Blocking Time is the closest lab signal it gives you. Here is the measurement process I recommend.
- Confirm there is a problem. Open the Core Web Vitals report in Google Search Console and check whether URL groups are flagged for INP on mobile, desktop or both. Mobile is usually worse.
- Check representative URLs. PageSpeed Insights shows field INP for a URL or its whole origin when there is enough Chrome User Experience Report data. Compare your main templates: home page, category or listing page, product or service page, blog post.
- Find the slow interactions. Field data tells you that a page is slow but not which button. Add Google’s open source
web-vitalslibrary using its attribution build and send the results to your analytics. It reports the element that was interacted with, the event type, and how long each of the three phases took. - Reproduce in DevTools. In the Chrome DevTools Performance panel, enable CPU throttling to approximate a mid-range phone, start recording, perform the slow interaction, and stop. The interactions track shows each interaction and its duration, and the main thread track shows exactly which scripts ran.
- Go deeper with Long Animation Frames if needed. The Long Animation Frames API, available in Chromium browsers, reports which scripts contributed to slow frames in the field. It is particularly useful for identifying third party scripts you cannot reproduce locally.
Once you have a list of slow interactions, each with a phase breakdown and a script to blame, you can prioritise. Fix the interactions people use most often first: navigation menus, filters, search boxes, add-to-basket and form submit buttons.
Fixing input delay: long tasks and third party scripts
The main thread can only do one thing at a time. A long task, meaning a single block of JavaScript that runs without pausing, prevents the browser from responding until it finishes. Common sources:
- Third party scripts. Chat widgets, tag managers loaded with dozens of tags, heatmap and session recording tools, ad scripts and social embeds. Audit each one. Remove what nobody uses, load the rest after the page is interactive, and consider replacing heavy widgets with a lightweight facade that only loads the real script when someone clicks it.
- Hydration. Sites built with React, Vue and similar frameworks often render HTML on the server and then “hydrate” it in the browser by running JavaScript for the whole page. During hydration, taps on visible buttons can wait or do nothing. Approaches such as partial or progressive hydration, server components and islands architecture reduce how much JavaScript has to run before the page responds.
- Timers and polling. Scripts that run on intervals, such as carousels, live counters and analytics heartbeats, can land just as a user taps.
The core technique is yielding: breaking long work into smaller pieces so the browser gets chances to handle input between them. You can yield with setTimeout, or with scheduler.yield() in browsers that support it, which lets the remaining work resume promptly once the browser has handled anything urgent.
Fixing processing and presentation delay
Do the visible part first. When a user clicks “Add to basket”, the immediate need is a visual response, such as a button state change or a counter update. Analytics events, recommendation fetches and saving to local storage can wait. Update the UI, yield, then run the rest.
Avoid layout thrashing. Reading a layout property such as an element’s height and then writing a style, repeatedly in a loop, forces the browser to recalculate layout over and over. Batch your reads, then batch your writes.
Debounce text input. Search-as-you-type and live filtering should not rerun expensive logic on every keystroke. Update the input immediately and run the heavy search after the user pauses.
Shrink the DOM. A very large DOM makes every style recalculation and layout more expensive, which shows up as presentation delay. Mega menus with hundreds of hidden links, product listings that render every item at once and page builders that nest many wrapper elements are common causes. Render long lists in chunks or virtualise them, and use the CSS content-visibility property for off-screen sections so the browser can skip rendering them until needed.
Limit re-render scope in frameworks. A small state change at the top of a component tree can re-render the whole page. Keep state close to where it is used and memoise expensive components.
Illustrative example: a slow filter on a category page
Imagine an online clothing shop in Lahore whose field data shows poor INP on category pages. The attribution data points to the size filter checkboxes. A DevTools recording on a throttled profile shows three things: a chat widget running a long task when the filter is tapped (input delay), a handler that re-filters and re-renders all products synchronously and fires several analytics events (processing duration), and a grid of every product in the category being laid out again (presentation delay).
A sensible fix plan for that shop would be: load the chat widget behind a facade so it only runs when opened; in the handler, tick the checkbox and show a loading state first, then yield before filtering; move analytics calls after the visual update; and render the product grid in pages rather than all at once. Each change targets one phase, and the attribution data shows which one still dominates after each release.
Responsiveness is only one dimension. If the same pages also jump around as they load, my guide on fixing Cumulative Layout Shift covers that side. If they are slow to show content at all, server and caching problems are a more likely culprit, which I explain in which hosting, caching and CDN changes actually improve LCP. For mobile-specific tactics, see how to optimise Core Web Vitals on mobile.
Questions people ask about INP
Can a faster server fix a poor INP score?
Rarely. INP measures what happens in the browser after the page has loaded, so it is almost always a JavaScript and rendering problem rather than a hosting one. A faster server helps LCP, but it will not shorten a long task triggered by a chat widget or a heavy click handler.
Why is INP fine on my laptop but poor in Search Console?
Field data reflects your real audience, and many visitors use phones with much less processing power than a desktop or recent laptop. Work that takes a moment on your machine can take several times longer on a budget Android device. Use CPU throttling in DevTools to get closer to their experience.
Do WordPress sites have INP problems too?
Yes. Page builders that output large DOMs, sliders, popup plugins, chat widgets and tag managers loaded with many scripts are common causes on WordPress. Removing unused plugins, delaying non-essential scripts until after interaction and simplifying heavy templates are typical starting points.
Does Total Blocking Time tell me my INP?
No, but it is a useful hint. Total Blocking Time measures main thread blocking during a lab page load, and pages with high blocking time often have poor input delay. It cannot tell you how slow your handlers or rendering are, so always confirm with field data.
INP work is detailed: it means reading traces, auditing third party scripts and sometimes changing how a theme or app is built. If you would like help, my website speed optimisation services include INP diagnosis using field data and a prioritised fix list. Start by asking for a free audit and I will tell you which interactions are slowing your pages.