INP & Core Web Vitals Checker

What is INP?

Interaction to Next Paint measures how long the page takes to visually respond to a user action — a click, tap, or keypress. It replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024 because INP captures every interaction during the session, not just the first one. Good INP is under 200 ms at the 75th percentile; above 500 ms is Poor and counts against Google search ranking.

Also tested: LCP, CLS, TTFB, and FCP

This tool reports all three Core Web Vitals — INP, Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS) — along with Time to First Byte (TTFB) and First Contentful Paint (FCP) as supporting context. TTFB in particular compounds into every other metric: a 1.5-second TTFB already burns most of your INP budget before any user-visible work starts.

Why field data (CrUX) and not Lighthouse?

Google ranks sites based on real Chrome user data, not synthetic lab tests. The Chrome UX Report aggregates these metrics from opted-in Chrome browsers over a 28-day rolling window. Lighthouse can estimate INP in a lab run via Total Blocking Time correlation, but only field data reflects what real visitors experience and only field data drives ranking. If CrUX has no data for a URL, it usually means the site has too little Chrome traffic (a few hundred visits per month minimum).

What this tool measures

Interaction to Next Paint (INP) measures how long it takes for the browser to draw the next frame after a user interaction — a click, a tap, a key press. The metric comes from Chrome's User Experience Report (CrUX) field data, which means it reflects the actual experience of real Chrome users in the past 28 days, not a synthetic lab measurement. The reported value is the 75th-percentile INP across all interactions on the page, which is the threshold Google uses for the Core Web Vitals 'good / needs improvement / poor' classification: a 75p of 200ms or less is Good, 200-500ms is Needs Improvement, above 500ms is Poor. Mobile and desktop are graded separately because their interaction profiles are completely different — touch on mid-range Android is a far stricter test than mouse on a desktop with a 4090.

How INP differs from FID (and why it replaced it)

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024 because FID was misleadingly easy to pass. FID measured the delay before the browser could start processing the very first interaction — and only the first. A page could have a fast first interaction and grind through every subsequent click, and the FID score wouldn't reflect it. INP measures every interaction throughout the page lifetime and reports the (near-)worst case, which is much closer to what users actually feel. The practical consequence: many sites that passed FID handsomely fail INP because their second, third, or twentieth interaction is far slower than their first. The redesign also expanded the measurement window: INP captures the full event-handler-plus-render-to-frame cost, not just the queueing delay, so heavy JavaScript handlers and slow render passes both show up.

Common findings on real sites

The repeating patterns are predictable. First, heavy JavaScript main-thread tasks — a handler that runs 200ms of synchronous parsing or layout work blocks the next paint regardless of how the rest of the page is structured. Second, third-party scripts that hook into every click for analytics or chat / support widgets, adding their own handler time on top of yours. Third, hydration cost on partial-SSR frameworks where the user can interact before hydration completes, so the first interactions queue behind the hydration work itself. Fourth, expensive CSS animations triggered by interaction (e.g. heavy gradient-filter transitions) that block compositor frames. Fifth, missing debounce / throttle on rapid-fire inputs (typing, drag, scroll-coupled handlers) where the handler runs 60 times a second when it should run 4. A given site usually has two or three of these compounding rather than a single dominant bottleneck.

How to improve INP

Three families of fixes cover most cases. First, do less work synchronously: break long handler bodies with the yield-to-main pattern (await scheduler.yield() in modern Chrome, or setTimeout(fn, 0) for compatibility) so the browser can paint between chunks. Second, defer non-urgent work: requestIdleCallback for analytics calls and prefetching, web workers for any computation that doesn't directly touch the DOM, code-splitting + lazy loading for routes that aren't needed at first interaction. Third, debounce rapid inputs — set a 100ms debounce on typeahead, throttle scroll handlers to 16ms (one frame), use the Intersection Observer instead of scroll-coupled visibility logic. For third-party scripts the fix is usually to defer load until after first interaction, or replace heavy widgets (live-chat that mounts a 500KB React tree) with lightweight alternatives. After every change, re-measure: the metric is field-data so improvements take 7-28 days to fully appear in CrUX, but the trend is visible within a few days.

Why INP is the metric to watch

INP is the responsiveness component of Core Web Vitals — the bucket Google explicitly uses as a ranking signal. A page in the Good bucket is meaningfully favored over an otherwise-identical page in the Needs Improvement bucket, and the gap to Poor is larger still. Beyond ranking, INP correlates strongly with bounce and conversion on every dataset that has been measured: when interactions feel sluggish, users assume the site is broken regardless of any other quality signal. The metric is also unusually honest because it comes from real users' real interactions rather than from synthetic measurements — there's no way to optimize for the test without actually improving the experience. The flip side is that gaming-style optimizations don't help; the only path to a better INP is doing less work in the handler-to-paint window, which is exactly the work that makes the page feel fast to humans.