If your pages load quickly but menus hesitate, accordions judder and form steps feel sticky, Interaction to Next Paint is the metric to investigate. INP measures the latency of qualifying clicks, taps and key presses across a visit, from the interaction until the browser paints the next visual response. Per web.dev, good INP is 200 milliseconds or less, needs improvement is above 200 to 500 milliseconds, and poor is above 500 milliseconds, assessed at the 75th percentile of page loads in field data, separately for mobile and desktop. This guide teaches the general discipline: find the guilty interaction, split it into its three phases, and fix the phase that is actually slow.
The short answer: what INP measures and the 200ms line you must get under
INP is not a load metric. A page can achieve a strong Largest Contentful Paint and still fail INP because every later interaction waits on a busy main thread. The reported value reflects the slowest interactions of the visit, with outliers handled so one freak delay does not define the page. Your target is simple to state and harder to reach: at least 75 percent of real visits should record INP at or below 200 milliseconds.
Start from field data in Search Console and PageSpeed Insights, name the worst interaction with attribution, then fix by phase. Do not begin with a generic speed checklist. Our Core Web Vitals launch checklist covers launch readiness across all three vitals; this article stays inside responsiveness only.
The problem: your site loads fine and still feels slow to use
Owners describe this in human terms: the site looks finished, then ignores them. A mobile menu opens late. A filter panel updates after a second tap. A form hesitates between steps. Each pause is short alone, but together they make the site feel unreliable.
Load audits miss this because they end at first render. INP begins where the audit stops, at the first real attempt to use the page. That is why teams can celebrate a load project while Search Console still flags responsiveness. The fault is work scheduled at interaction time: handlers doing too much, third parties waking up, and a main thread already occupied when the visitor acts.
What changed: why INP replaced FID — and why sites that passed now fail
INP replaced First Input Delay as a Core Web Vital on 12 March 2024, per web.dev. First Input Delay measured only the wait before the browser began handling the first interaction. A site could pass it while every subsequent menu, filter and form interaction lagged unmeasured.
INP observes interactions throughout the visit and reports the latency that represents the visit's responsiveness, so it exposes the long tail FID hid. Sites that passed FID and now fail INP have not necessarily become slower. The measurement became honest. Treat a new INP failure as newly visible evidence about ordinary interactions, not as a penalty to argue with, and use it to prioritise the interactions visitors rely on most.
The three phases of every interaction: input delay, processing time, presentation delay
Input delay runs from the visitor's action until handlers begin. It grows when long tasks occupy the main thread, because the browser cannot start the new interaction until the current task yields. Processing time is the handlers running: validating, calculating and updating the document. Presentation delay runs from handlers finishing until the next frame is painted, and grows with large DOM updates and expensive layout or paint work.
This split is the diagnostic method. Input-delay dominance needs less competing work. Processing dominance needs a lighter handler. Presentation dominance needs a smaller, cheaper visual update. Guessing merges all three into vague slowness; attribution separates them.
Step 1 — Find your real INP: field data first (Search Console, PageSpeed, CrUX)
Begin with the Search Console Core Web Vitals report to see which URL groups fail INP on mobile and desktop. Follow with PageSpeed Insights on a failing template to compare its field data, drawn from the Chrome User Experience Report over a rolling 28-day window, with lab diagnostics on the same page. Field data decides priority; lab data supports reproduction.
Note the limits honestly. Low-traffic pages may have no page-level field data, in which case origin-level data and lab profiling must guide you until traffic builds. Record the baseline before changing code: the failing groups, the templates they share and the date. Without that record, later improvement cannot be attributed to your fix rather than to a change in traffic mix.
Step 2 — Name the guilty interaction: attribution with the web-vitals library and DevTools
Next, identify the exact interaction. The web-vitals library's attribution build reports the target element, interaction type and phase breakdown for real visits, letting you rank interactions by how often they are worst. Collect enough visits to see a pattern, not a single anecdote.
Then reproduce it in Chrome DevTools: record in the Performance panel, open the Interactions track, and inspect the long tasks beneath the slow bar. The goal is a sentence your developer can act on: this element, this handler, this phase, this script. Our technical SEO playbook on Core Web Vitals, crawl budget and indexing explains where this diagnosis sits inside a wider audit.
Step 3 — Fix by phase: long tasks, heavy handlers, third-party scripts, oversized DOM
For input delay, break up long tasks. Any task over 50 milliseconds can block a pending interaction, so split large jobs into smaller chunks and yield to the main thread between them, letting taps and paints interleave. For processing time, lighten handlers: give the immediate visual response first, defer analytics and other non-visual work until after the paint, and avoid reading and writing layout in alternating patterns that force repeated recalculation.
For presentation delay, shrink the update. Reduce DOM size on interaction-heavy templates, virtualise very long lists, and avoid restyling the whole page for a local change. Across all phases, audit third-party scripts and tag managers with the same suspicion as your own code. Complement these fixes with the build discipline on our SEO-friendly web development page, so new templates do not reintroduce the same handlers.
The usual suspects on business sites: menus, filters, forms, chat widgets and cookie banners
On business sites the same suspects recur. Mobile menus and accordions animate expensively or wait on framework work. Filters re-render large result sets for every change. Multi-step forms validate everything on each key press or step change, instead of validating the field in hand and painting progress immediately.
Chat widgets and cookie banners deserve special attention. A banner's accept action can release a queue of deferred tags at once, making that interaction the worst on the site, while tracking tools add work inside the clicks they observe. None must be removed by default; each must earn its place, be deferred past the visual response, or be replaced with a lighter pattern. Our overview of web development in the UAE shows how these choices belong in the build.
Verify the fix: why you wait for the next 28-day field-data cycle
Verify twice. Immediately, re-record the fixed interaction in DevTools and on a real phone: the dominant phase should be smaller and the interaction prompt. That confirms the change did what you intended.
Then wait for field confirmation. Because assessment uses the 75th percentile over a rolling 28-day window, Search Console status changes gradually as post-fix visits replace pre-fix ones. Monitor the same URL groups you baselined. If field INP does not move, attribution usually shows a different interaction has become worst: fix that one next, in order.
Common mistakes (chasing lab scores; optimising load when the interaction is the fault)
The most common mistake is chasing a lab score that cannot measure real interactions, then wondering why field INP is unchanged. The second is optimising load, compressing images and tuning the server, when the failing interaction was never load-bound. The third is fixing the interaction you enjoy testing instead of the one attribution names.
Teams also debounce clicks, which does nothing for a discrete action, when the real fix is reducing handler work; pile fixes together so none can be credited; and test only on a fast desktop. Each mistake shares one root: skipping attribution. Name the interaction and its dominant phase first, and most wrong fixes become obviously wrong before any code is written.
FAQ
What is INP in simple terms?
INP is how long a visitor waits for visible feedback after clicking, tapping or pressing a key. It covers the whole visit, not just the first interaction. Per web.dev, 200 milliseconds or less is good, and above 500 milliseconds is poor.
Why did my site pass FID but fail INP?
FID only timed the delay before the first interaction began. INP, which replaced FID on 12 March 2024, observes interactions across the visit and reflects the slowest ones. Your site likely always had slow later interactions; FID never measured them.
Can I measure INP with Lighthouse alone?
No. Lighthouse runs in a lab without your real visitors' interactions, so it cannot report field INP. Use Search Console, PageSpeed Insights field data or the web-vitals library for the value, and DevTools to profile the cause.
What is a long task and why does it matter?
A long task is a main-thread task longer than 50 milliseconds. While it runs, the browser cannot start a pending interaction or paint a result, so it inflates input delay. Breaking long tasks into chunks and yielding is a core INP fix.
How long does an INP fix take to show in Search Console?
The improvement appears gradually over the rolling 28-day field-data window as new visits replace old ones. Verify the interaction in DevTools straight away, then judge Search Console status after the cycle has substantially refreshed.
Failing INP and cannot find the interaction causing it? (CTA)
If field data says INP fails but nobody can name the interaction, the missing step is attribution, not more speed work. A technical SEO audit from WebStackRank identifies the guilty interactions, splits each into input delay, processing time and presentation delay, and traces them to the theme, plugin or third-party source responsible. Share your Search Console INP status and the templates affected, and we will give your developer fixes aimed at a named interaction, not a general warning.
