Interaction to Next Paint (INP) diagnosis
Interaction to Next Paint (INP) measures overall page responsiveness by observing the latency of user interactions throughout a visit and reporting a representative worst case. It became a Core Web Vital in March 2024, replacing First Input Delay. A good INP is 200ms or less; long tasks and heavy JavaScript on the main thread are the usual causes. This page covers the metric and its diagnosis.
What INP measures
INP measures the latency from a user interaction (click, tap, key press) to the next frame the browser paints in response. Rather than only the first interaction, it observes interactions across the whole visit and reports a single representative value close to the worst experienced.
Thresholds: a good INP is 200ms or less at the 75th percentile; 200 to 500ms needs improvement; above 500ms is poor. INP replaced First Input Delay as a Core Web Vital on 12 March 2024 because FID measured only input delay of the first interaction, missing processing and rendering latency.
- Measures interaction-to-paint latency across the visit
- Good: ≤ 200ms; Needs improvement: 200–500ms; Poor: > 500ms
- Replaced First Input Delay (FID) in March 2024
- Captures input delay, processing, and presentation delay
Common causes
Slow INP almost always comes from main-thread congestion: long JavaScript tasks block the browser from handling input and painting the response. Heavy event handlers, large hydration work, third-party scripts, and excessive DOM size all contribute.
An interaction has three parts — input delay (waiting for the main thread to be free), processing time (the event handlers), and presentation delay (rendering the next frame). Diagnose by finding which part dominates, often using long-task and interaction breakdowns in field-aware tooling.
Fixing INP
Break up long tasks by yielding to the main thread, defer or remove non-essential JavaScript, and minimize work inside event handlers (do the visual update first, defer heavy work). Reduce hydration cost and third-party script impact.
Keep the DOM reasonably sized so rendering the next frame is cheap. Because INP depends on real interactions, it cannot be measured by a single lab load alone — rely on field data to confirm improvements for real users.
How it appears in analytics and logs
A poor INP means the page is slow to visually respond to user input. It is a page experience ranking input, not a crawl or index gate. INP problems are a responsiveness and ranking-refinement concern; they do not stop a page from being crawled or indexed.
Diagnostic use case
Diagnose sluggish responses to clicks, taps, and key presses, attribute slow INP to main-thread work, and confirm the impact with real-user field data.
What WebmasterID can help detect
INP is a client-side responsiveness metric outside WebmasterID's crawl-side scope. WebmasterID helps confirm crawl and index health first; interaction responsiveness is then tuned with field and lab vitals tooling.
Common mistakes
- Still treating First Input Delay as the responsiveness Core Web Vital after INP replaced it.
- Running heavy synchronous work inside click/tap handlers, blocking the next paint.
- Loading large third-party scripts that congest the main thread.
- Assuming a single lab load fully captures INP, which depends on real interactions.
Privacy and accuracy notes
Field INP is aggregated from anonymized real Chrome users via CrUX, since it depends on actual interactions. WebmasterID does not capture per-user interaction traces or fingerprint visitors; it records crawler events only.
Frequently asked questions
- What is a good INP score?
- 200ms or less at the 75th percentile of interactions is good. Between 200 and 500ms needs improvement, and above 500ms is poor.
- Why did INP replace First Input Delay?
- FID only measured the input delay of the first interaction. INP captures full interaction latency — delay, processing, and rendering — across the whole visit, giving a more complete view of responsiveness. It became a Core Web Vital in March 2024.
Related pages
- Core Web Vitals and crawling
Core Web Vitals are Google's three user-centric performance metrics — Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. They are a page experience signal used in ranking, but they do not gate crawling or indexing: a slow page can still be crawled and indexed. This page explains how vitals are measured in the field versus the lab and where they fit in the crawl-to-rank pipeline.
- Cumulative Layout Shift (CLS) diagnosis
Cumulative Layout Shift (CLS) measures visual stability — how much page content unexpectedly moves while loading. It is one of the three Core Web Vitals. A good CLS is 0.1 or less; the usual causes are images and ads without reserved space, late-loading fonts, and content injected above existing elements. This page explains the metric, its thresholds, and the diagnosis-and-fix workflow.
- Hydration and crawling
Hydration is the process of attaching client-side JavaScript behavior to HTML that was already rendered on the server or statically. For crawling, the key point is that the content is in the initial HTML, so it is visible to crawlers regardless of hydration; hydration mainly affects interactivity and responsiveness. This page explains hydration, its crawl implications, and the INP trade-offs of heavy hydration.
- Website observability
Confirm crawl and index health before tuning client-side responsiveness.
Sources and verification notes
- web.dev — Interaction to Next Paint (INP)Definition, interaction phases, and thresholds.
- web.dev — INP becomes a Core Web Vital on March 12
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.