Interaction to Next Paint (INP)

TL;DR — INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. measures how quickly your page responds when someone clicks, taps, or types. The browser times the gap between the interaction and the next visual update, across the whole visit, and reports roughly the worst one. Under 200 ms is good; over 500 ms is poor. It’s one of the three Core Web Vitals, and it replaced an older metric called First Input DelayFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. in 2024.

What INP actually measures

When you click a button, tap a menu, or type in a box, you expect the page to react — a menu opens, a checkbox ticks, text appears. Interaction to Next Paint (INP) measures how long that takes: the time from your interaction until the browser paints the next frame showing something changed.

Here’s the part that matters. INP doesn’t just look at one interaction. It watches every click, tap, and keyboard press during your entire visit, then reports (close to) the slowest one. So a single janky interaction — a search box that freezes for half a second every time you type — can sink the whole score.

Scrolling, hovering, and zooming don’t count. Only clicks, taps, and keyboard interactions are measured.

The thresholds

INP is reported in milliseconds, and Google buckets it into three ratings:

• Good — 200 ms or less
• Needs improvement — more than 200 ms, up to 500 ms
• Poor — more than 500 ms

For context: 200 ms is fast, but it’s not a lot of headroom. Everything your code does in response to a click — plus the browser drawing the result — has to fit inside it.

Why it replaced FID

The old responsiveness metric was First Input Delay (FID). FID only measured the delay before the first interaction on a page started being handled — and it stopped timing the moment the work began. It didn’t count how long that work actually took, or how long the screen took to update.

INP fixed all of that. It measures the full time (start to visual update) for all interactions, not just the first one. Google made the switch official on March 12, 2024, and FID was gone from the tools entirely by September 2024.

What makes INP bad — in plain terms

Almost always, it’s JavaScript hogging the main thread. The browser can only do one thing at a time on that thread, so if a chunk of script is busy running, your click has to wait in line. Common culprits:

• Heavy work running inside the click/tap handler itself.
• Big “long tasksAny main-thread task over 50 ms — the primary cause of INP regressions.” of JavaScript blocking everything.
• Third-party scripts — analytics, cookie-consent banners, chat widgets, tag managers. These are some of the worst offenders, even on simple content sites.

The fix, broadly, is to do less work when someone interacts, and to break big jobs into small pieces so the browser can squeeze your interaction in between them.

Want the real mechanics — the three-part latency breakdown, the 75th-percentile math, exactly how to fix each cause, and the SEO angle? Switch to the Advanced tab.

TL;DR — INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. is the Core Web Vital for responsiveness. It observes the latency of all click, tap, and keyboard interactions across a visit and reports the value at the 75th percentile (one outlier dropped per 50 interactions) — not just the first input like FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. did. An interaction’s latency = input delay + processing duration + presentation delay. Good ≤ 200 ms, poor > 500 ms, judged on field dataPerformance metrics captured from real users, not lab tests. at p75. It replaced FID on March 12, 2024 (FID fully removed from tools September 2024). Fix it by breaking up long tasksAny main-thread task over 50 ms — the primary cause of INP regressions., yielding to the main thread with scheduler.yield(), doing less in event handlers, shrinking the DOM, and deferring third-party scripts. It’s a field metric — Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. is the lab proxy, and the two don’t always agree.

What INP measures — and how it differs from FID

Google’s definition is precise: INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.”

That “all interactions… throughout the lifespan” phrasing is the whole story. INP is a visit-level metric, not a load-time one — and Google’s reasoning is that the vast majority of a user’s time on a page happens after it loads, so responsiveness during use matters more than the first impression alone.

The contrast with First Input Delay is the cleanest way to understand it: “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” FID timed one thing about one interaction — the wait before its handler started — and ignored both how long the handler ran and how long the screen took to update. INP measures the full latency of every interaction.

One nuance worth getting right, because it’s a common myth: INP is not literally the worst interaction. To avoid punishing a page for a single random spike, the browser drops one outlier for every 50 interactions, then reports the value at the 75th percentile of page views. On a low-interaction visit, that lands on the slowest interaction; on a heavy one, a couple of outliers get excluded first.

What counts as an interaction is also narrower than people assume. Only clicks, taps, and keyboard presses are measured. Scrolling, hovering, and zooming are explicitly excluded. And a single gesture can fire several events — a tap produces pointerdown, pointerup, and click — which INP groups as one interaction, not three. Within that group, INP takes the longest individual event duration, not the sum of all of them — so a fast pointerdown next to a slow click still reports as one interaction sized by the slow event. If a page has no qualifying interactions during a visit, INP simply isn’t reported for it.

The three parts of an interaction’s latency

Every interaction’s latency breaks into three sequential pieces. This is the model to keep in your head, because each part points at a different fix:

Interaction latency = Input delay + Processing duration + Presentation delay

1. Input delay — the time before your event handlers can even start running, usually because the main thread is busy finishing a long task.
2. Processing duration — the time it takes all of your event handler callbacks to execute.
3. Presentation delay — the time from when your handlers finish until the browser paints the next frame on screen.

The web-vitals attribution build exposes all three (inputDelay, processingDuration, presentationDelay) so you can see which part dominates on a real interaction. Per the Web Almanac’s 2024 data, presentation delay is often the largest single piece at the median — but processing duration is where the optimization leverage usually lives, because it’s the part that balloons on poorly-built pages.

The thresholds — and the p75 field caveat

Google Search Central states the target plainly — “an INP of less than 200 milliseconds” — and frames the whole program as: “We highly recommend site owners achieve good Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. for success with Search.” The 200 ms budget is genuinely tight when you remember the browser wants a frame every ~16.7 ms at 60 fps; all of your handler work plus renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. has to fit.

Why INP is a field metric (and lab data isn’t enough)

This is the trap that catches a lot of SEOs: a green Lighthouse scoreLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. does not mean good INP. But “LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. can’t measure INP” needs three separate cases, not one, or you’ll misread your own tooling:

1. A standard, noninteractive Lighthouse run reports no INP at all. It only observes the page loading — it never clicks, taps, or types anything — so there’s no interaction to time. Lighthouse falls back on Total Blocking Time (TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital.) as a load-time proxy instead. Google’s own framing: “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” The key words are “during load.” TBT says nothing about an interaction that goes bad ten seconds later when a lazy-loaded widget runs — it’s a proxy, never a substitute or a conversion formula.
2. A manually or synthetically exercised interaction — clicking a real button in DevTools, or scripting a click in a lab tool — does produce a real INP-style latency number for that one interaction. That’s useful for reproducing a specific bug. But it’s still one scripted path on one device: it can’t stand in for the field’s mix of real devices, real users, real interaction targets, and a full visit’s worth of page lifetime. As Google puts it, the resulting value “will be dependent on what interactions are performed during the measurement period,” and real user behavior is too variable for a single lab run to represent it.
3. The field distribution is the only thing INP actually is. That’s why the authoritative source is field data: the Chrome User Experience ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.), surfaced through PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and the Search Console Core Web VitalsThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. report. “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.”

Use the lab (cases 1 and 2) to find and reproduce a slow interaction; use the field (case 3) to confirm whether it’s actually dragging down real visitors’ scores.

Why your INP score is poor

Almost every INP problem traces back to the main thread being blocked when a user interacts. The usual suspects:

• Long tasks. Any main-thread task over 50 ms is a long task; the amount over 50 ms is its “blocking period.” While one runs, your interaction can’t be handled. This is the single biggest cause.
• Heavy event handlers. Doing too much synchronously inside a click/input handler inflates processing duration directly.
• Large DOM size. Bigger DOMs cost more to render, which inflates both input and presentation delay.
• Third-party scripts. Per the Web Almanac, consent providers, tag managers, analytics, and chat widgets are top offenders — and they hit even simple content sites. They’re the first place I look on a page I didn’t build.
• Post-load JavaScript. Just because a page rendered doesn’t mean it finished loading — scripts evaluating after first paint can block early interactions.

How to fix it

The strategies, roughly in order of impact:

1. Break up long tasks. Google’s core advice on handlers is to “do as little work as possible in them.” Split a big job into smaller tasks so the browser can interleave a user interaction. When tasks are broken up, “the browser can respond to higher-priority work much sooner — including user interactions.”

2. Yield to the main thread. The modern, recommended way is scheduler.yield() (Chrome 129+, Firefox 142+): await scheduler.yield() pauses your code, lets the browser handle pending work, and resumes with priority — so other tasks won’t cut the line ahead of your continuation. The classic fallback is setTimeout(..., 0), which still works but sends your code to the back of the task queue (and browsers enforce a 5 ms floor after several nested calls). One thing to stop doing: isInputPending() — Google now says “we no longer recommend using this API.” See the Scripts tab for the pattern.

3. Do less in event handlers — defer the non-critical work. Run only the visual update the next frame needs synchronously; push everything else (saving, spell-check, analytics, word counts) behind requestAnimationFrame + setTimeout or a yield. The user sees the response immediately; the bookkeeping happens after.

4. Avoid layout thrashing. Reading layout properties right after writing styles in the same task forces the browser into synchronous layout it could otherwise have batched. Batch reads, then writes.

5. Reduce DOM size. Smaller trees render faster. content-visibility can lazily render off-screen elements so they don’t cost you during load or interaction.

6. Audit and defer third-party scripts. This is the highest-leverage SEO fix on real sites. Load consent/tag/analytics scripts lazily, gate them on interaction, or move them off the critical path. A “lightweight” content page can fail INP purely because of a heavy embedded widget.

Does INP affect rankings?

Yes — INP is one of the three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., and Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. are part of Google’s page-experience signals. But it’s a lightweight signal: a tiebreaker between comparably relevant results, not a primary ranking factor. Don’t chase a perfect INP score at the expense of content and relevance.

Two practical SEO points. First, mobile is the hard number. In the 2024 Web Almanac, ~74% of mobile sites passed INP versus ~97% on desktop — and because Google indexes mobile-first, the mobile figure is the one that counts. Second, complex sites do worse: only ~53% of the top 1,000 sites passed, because feature-rich pages ship more JavaScript to block the main thread. Heavy feature development is an INP risk, and high-interaction pages — product pages, checkout, search results, forms — are far more exposed than static content.

INP vs FID — the full picture

FID is gone — removed from Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. on the day INP launched and from CrUX’s BigQuery/API by September 2024. If a tool or audit still references FID, it’s stale.

Edge cases that make INP data disagree

A handful of lifecycle quirks explain most “why doesn’t my RUM match CrUX” questions:

• No interactions, no INP. If a visit never gets a click, tap, or key press — or only gets excluded gestures like scrolling and hovering — there’s no INP value for that page view. This is normal on read-only content pages and isn’t a bug in your monitoring.
• IframesHTML element that displays one webpage inside another — how embeds work. count toward the metric, but your own JavaScript can’t see inside them. An interaction inside an embedded iframe (an ad, a widget, an embedded form) contributes to the page’s INP. But a first-party RUM script can’t read events from a cross-origin iframe the way the browser’s own metric can — so CrUX and a same-origin RUM setup can legitimately disagree on pages with third-party embeds. Document this gap rather than treating a RUM/field mismatch as a bug.
• Back/forward cache restores reset INP to zero. A page pulled from bfcache (the back button, for instance) starts a fresh INP count — interactions from before the navigation away don’t carry over.
• Long-lived and backgrounded tabs still need to report. Because a tab can sit open for hours without ever formally unloading — especially on mobile, where the OS may just kill it — INP should be captured when the page becomes hidden, not only on unload. RUM setups that only flush on unload will silently lose data from these visits.

Where this sits

INP is one piece of the Core Web Vitals picture, alongside Largest Contentful Paint (loading) and Cumulative Layout Shift (visual stability). Check it in PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and the Search Console report (field), and debug it in Lighthouse / Chrome DevTools (lab, via the TBT proxy). The data behind all of it comes from CrUX.

AI summary

A condensed take on the Advanced version:

• INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. = the Core Web Vital for responsiveness. It observes the latency of all click, tap, and keyboard interactions across a whole visit and reports the value at the 75th percentile (one outlier dropped per 50 interactions) — not just the first input the way FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. did.
• Latency = input delay + processing duration + presentation delay. Each part points at a different fix; processing duration is usually where the leverage is.
• Thresholds (field, p75): good ≤ 200 ms, needs improvement ≤ 500 ms, poor

  500 ms.

• Only clicks, taps, and keyboard count — scroll, hover, and zoom are excluded; a single gesture’s multiple events are grouped as one interaction.
• It replaced FID on March 12, 2024 (FID fully removed from tools September 2024). FID only timed the first interaction’s input delay.
• It’s a field metric, and “LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. can’t measure it” has three cases: a standard noninteractive LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. run reports no INP and falls back to Total Blocking Time as a load-time proxy; a manually exercised lab interaction does produce a real single-interaction latency but can’t stand in for the field population; only CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. / PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. field dataPerformance metrics captured from real users, not lab tests. is authoritative.
• Causes: long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. (>50 ms), heavy event handlers, large DOM, and especially third-party scripts (consent, tag managers, analytics, chat).
• Fixes: break up long tasks, yield with scheduler.yield() (setTimeout fallback; isInputPending() is no longer recommended), do less in handlers, avoid layout thrashing, shrink the DOM, defer third-party scripts.
• Edge cases: no qualifying interaction means no INP value; iframeHTML element that displays one webpage inside another — how embeds work. interactions count toward the metric but a same-origin RUM script can’t see inside them; bfcacheThe back/forward cache (bfcache) is a browser feature that freezes a whole page in memory when you navigate away, so pressing Back or Forward can restore it instantly — no reload, no re-render, no network requests — as long as the browser hasn't evicted that frozen page first. It's a browser optimization, not a search ranking factor. restores reset INP; long-lived/backgrounded tabs should report on hidden, not just on unload.
• SEO: a lightweight ranking signal. Mobile (~74% pass vs ~97% desktop) is the number that matters under mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost.; high-interaction pages are most exposed.

Official documentation

Primary-source documentation from Google / the Chrome team.

web.dev — the INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. references

• Interaction to Next Paint (INP) — the definitive definition: what it measures, the three-part latency breakdown, interaction types, and thresholds.
• Optimize Interaction to Next Paint — the optimization playbook: doing less in handlers, deferring non-critical work, layout thrashing, DOM size, content-visibility.
• Interaction to Next Paint officially becomes a Core Web Vital — the March 12, 2024 launch post (Jeremy Wagner & Rick Viscomi); the FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. deprecation timeline.
• First Input Delay (FID) — the deprecated metric; what it measured and why it was replaced.
• A new responsive metric: seeking your feedback — FID’s design limitations and INP’s improvements.
• Optimize long tasks — the 50 ms long-task definition, scheduler.yield(), the setTimeout fallback, and why isInputPending() is no longer recommended.
• Script evaluation and long tasks — TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. as an INP proxy and script-size guidance.
• Find slow interactions in the field — the web-vitals attribution build and the Long Animation Frames (LoAFLong Animation Frames API — browser API for diagnosing the long tasks behind slow interactions.) API.

Chrome / Google Search

• Performance features reference (Chrome DevTools) — the Interactions track, Live Metrics, and the 200 ms warning.
• CrUX release notes — confirms FID’s removal from BigQuery/API in September 2024.
• Core Web Vitals & Google Search results — INP as part of the page-experience signal; the ≤ 200 ms target.

Quotes from the source

On-the-record statements from Google / the Chrome team. Each link is a deep link that jumps to the quoted passage on the source page.

What INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. measures, and how it differs from FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024.

• “INP is a Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” — web.dev, Interaction to Next Paint (INP). Jump to quote
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” Jump to quote
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” — web.dev, First Input Delay (FID). Jump to quote

The FID → INP switch

• “FID will be deprecated.” — Jeremy Wagner & Rick Viscomi, web.dev blog, Interaction to Next Paint officially becomes a Core Web Vital. Jump to quote
• “FID will be removed from Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. as soon as INP becomes a Core Web Vital on March 12.” Jump to quote

Long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. — the primary cause

• “Any task that takes longer than 50 milliseconds is a long task.” — web.dev, Optimize long tasks. Jump to quote

Field dataPerformance metrics captured from real users, not lab tests. is primary

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” — web.dev, Find slow interactions in the field. Jump to quote

Google Search

• “We highly recommend site owners achieve good Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. for success with Search.” — Google Search Central, Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. & Google Search results. Source

INP fix checklist

Work top to bottom — the items near the top tend to move the number most:

• Pull field INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report), not just a lab score — and check mobile separately.
• Identify the slow interaction(s) with the web-vitals attribution build or Chrome DevTools’ Interactions track (it flags anything over 200 ms).
• Find and break up long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. (anything over 50 ms on the main thread).
• Yield to the main thread inside long-running loops — scheduler.yield(), with a setTimeout(..., 0) fallback. (Stop using isInputPending().)
• Inside each handler, run only the render-critical update synchronously; defer saving, validation, spell-check, analytics behind rAF + setTimeout.
• Check for layout thrashing — reading layout right after writing styles in the same task. Batch reads, then writes.
• Audit third-party scripts (consent, tag manager, analytics, chat). Defer, lazy-load, or gate them on interaction — usually the biggest single win.
• Reduce DOM size; apply content-visibility to off-screen sections.
• Defer / code-split non-critical JS so post-load scripts don’t block early interactions.
• Re-measure in the field after deploy — CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. is a rolling 28-day window, so the score moves slowly.

INP vs FID — cheat sheet

Fast facts

• Thresholds (field, p75): Good ≤ 200 ms · Needs improvement ≤ 500 ms · Poor > 500 ms.
• Counts: clicks, taps, keyboard. Excludes: scroll, hover, zoom.
• Latency = input delay + processing duration + presentation delay.
• Long taskAny main-thread task over 50 ms — the primary cause of INP regressions. = any main-thread task > 50 ms.
• Lab proxy: Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. — correlates, but only reflects load-time blocking. Authoritative source is field dataPerformance metrics captured from real users, not lab tests. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.).
• Mobile pass rate (~74%) is far below desktop (~97%) — and mobile is what counts.

Yield to the main thread

When you have a long-running loop (renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. a big list, processing data on click), periodically hand control back to the browser so it can service a pending user interaction. The modern API is scheduler.yield(); fall back to setTimeout where it isn’t supported.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

A few notes:

• scheduler.yield() returns a promise that resolves in a future task, and its continuation is prioritized — other queued tasks won’t jump ahead of your resumed code.
• setTimeout(..., 0) works everywhere but pushes your continuation to the back of the queue (and browsers enforce a ~5 ms floor after several nested calls).
• Don’t reach for isInputPending() — Google “no longer recommend[s] using this API.”

Defer non-critical work in a handler

Run only what the next frame needs; push the rest behind a paint.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Tools for measuring and fixing INP

Field (authoritative — this is what Google scores)

• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. for the URL/origin, split by mobile and desktop, plus a lab diagnostic pass.
• Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. — INP status across your URLs, grouped by issue, on field dataPerformance metrics captured from real users, not lab tests..
• CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. — the underlying Chrome User Experience Report dataset (also queryable via the CrUX API / BigQuery).

Lab / debugging

• Chrome DevTools — Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it. — the Interactions track times each interaction’s input delay, processing, and presentation, and flags anything over 200 ms; Live Metrics updates as you click around.
• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — can’t measure INP directly; reports Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. as the lab proxy.

Real-user monitoring (RUM)

• web-vitals JS library — onINP() for the value; the attribution build (web-vitals/attribution) exposes inputDelay / processingDuration / presentationDelay, the interactionTarget selector, and LoAFLong Animation Frames API — browser API for diagnosing the long tasks behind slow interactions. entries so you can see exactly which script and element caused the slow interaction. Whatever RUM setup you use, document its sampling rate and attribution coverage — a RUM figure quoted without that context isn’t comparable to CrUX’s field p75, and it can’t see inside cross-origin iframesHTML element that displays one webpage inside another — how embeds work. the way the aggregate metric can (see Edge cases, in the Advanced tab).

How the tools themselves score

A live example of the metric this page describes — well-known page-speed and monitoring services ranked on their own real-user mobile INP (Chrome UX Report field data):

INP fixes that usually miss the point

Optimizing only the first interaction

INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. evaluates interactions across the visit, not just the first input. Exercise menus, search, filters, forms, and other repeated controls before deciding the page is responsive.

Treating Total Blocking Time as the result

TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. is a useful lab proxy because it exposes long main-thread tasks, but it is not field INP. Use it to find candidates, then verify actual interactions with field dataPerformance metrics captured from real users, not lab tests. or an interaction trace.

Moving all work into one delayed callback

Deferring a large block can simply move the freeze. Break work into smaller tasks and yield so the browser can paint between them.

Removing visual feedback to shorten the handler

A control that performs work without showing a response still feels broken. Render the immediate state change first, then defer non-critical follow-up work.

Diagnose INP with the three-part latency model

Every slow interaction has three places to look:

1. Input delay: the event waited because earlier main-thread work was still running. Audit long tasksAny main-thread task over 50 ms — the primary cause of INP regressions. and third-party JavaScript before the handler began.
2. Processing duration: the event handler itself did too much. Reduce synchronous work, split loops, and postpone anything the next frame does not need.
3. Presentation delay: style, layout, or paint took too long after the handler. Reduce DOM complexity and avoid forcing repeated layout calculations.

Start with the largest phase in the trace. Re-record the same interaction after each change so a faster handler does not hide a new presentation bottleneck.

Prove an INP change improved the interaction

Handler-yield test

Test to run: record the target interaction in the Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it. before and after splitting or yielding long work. Expected result: the interaction’s processing span shrinks or is split by a paint. Failure interpretation: the expensive work is elsewhere or still runs synchronously. Monitoring window: immediate in repeated traces. Rollback trigger: the control updates out of order, loses state, or produces new input errors.

Presentation test

Test to run: inspect the same trace’s style, layout, and paint work after the event handler. Expected result: the next paint arrives sooner without a larger layout task. Failure interpretation: DOM size or forced layout remains the bottleneck. Monitoring window: immediate in lab traces. Rollback trigger: the visual response becomes incomplete or unstable.

Field confirmation

Test to run: compare post-release onINP() attribution for the changed interaction and template with its baseline. Expected result: p75 INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. improves and the targeted element no longer dominates slow events. Failure interpretation: the lab case did not represent real devices or journeys. Monitoring window: RUM as visits arrive; CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. over its rolling 28-day window. Rollback trigger: responsiveness or interaction completion worsens consistently after deployment.

INP metrics worth tracking

Real-user INP at p75

Metric: the 75th-percentile INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. by template and device class. What it tells you: whether typical real visits are responsive across their full journey. How to pull it: CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., or web-vitals RUM. Benchmark / realistic range: 200 ms or less is good; above 500 ms is poor. Cadence: monitor after JavaScript releases and review the rolling field trend monthly.

Slow-interaction rate

Metric: the share of measured interactions above 200 ms, grouped by target. What it tells you: which controls create the most user-visible delay even when the page-level p75 passes. How to pull it: the attribution build of web-vitals or Event Timing data in RUM. Benchmark / realistic range: establish a baseline per journey and reduce the highest-volume offenders. Cadence: weekly for application-like templates.

Latency phase share

Metric: input delay, processing duration, and presentation delay for slow interactions. What it tells you: whether scheduling, handler code, or renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. is the main constraint. How to pull it: DevTools traces and INP attribution. Benchmark / realistic range: no universal split is healthy; compare each phase against its own baseline and the total 200 ms good threshold. Cadence: during every focused performance investigation.

Resources worth your time

Google / Chrome (the canon)

• Interaction to Next Paint (INP) — start here.
• Optimize Interaction to Next Paint — the fixes.
• Optimize long tasks — yielding, scheduler.yield().
• Find slow interactions in the field — LoAFLong Animation Frames API — browser API for diagnosing the long tasks behind slow interactions. + attribution debugging.
• INP becomes a Core Web Vital — the March 12, 2024 launch.

Data

• Web Almanac 2024 — Performance — the real-world INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. pass-rate numbers and sub-part medians.

From around the industry

• INP — MDN Web Docs — MDN’s reference entry; good for cross-checking browser support and the metric definition outside Google’s own docs.
• Scheduler API: scheduler.yield() — MDN — browser support table and spec details for the main yield primitive.
• PerformanceEventTiming — MDN — the underlying browser API that INP reads; useful when digging into raw event timing data.
• Long Animation Frames API — Chrome Platform Status — LoAF browser-support tracking, the API that powers INP attribution in the web-vitals library.
• INP topic — Search Engine Land — industry news coverage of INP updates, test results, and the FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024.-to-INP transition from practitioners.

Stats worth citing

• ~74% mobile vs ~97% desktop pass INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (2024). Mobile is dramatically harder — and because Google indexes mobile-first, it’s the number that matters for SEO. Web Almanac 2024
• Only ~53% of the top 1,000 sites pass INP — feature-rich sites ship more JavaScript to block the main thread, so the biggest sites often do worse. Web Almanac 2024
• Long taskAny main-thread task over 50 ms — the primary cause of INP regressions. = > 50 ms. Anything past 50 ms on the main thread blocks the browser from responding to interactions — the direct mechanism behind poor INP. web.dev — Optimize long tasks
• Sub-part medians (2024): presentation delay ~36 ms is often the largest single contributor at the median, with input delay and processing time close behind at p75 — useful for knowing which third to attack. Web Almanac 2024

Videos

• Google Chrome Developers (YouTube) — the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. explainers from the Chrome team, including walkthroughs of diagnosing slow interactions in DevTools. Channel

Test yourself: Interaction to Next Paint

Five quick questions on responsiveness and INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. diagnosis. Pick an answer for each, then check.

INP

Interaction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.

Related: Core Web Vitals, TBT, LCP

INP

Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (INP) is the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. metric for responsiveness. It measures the latency of all click, tap, and keyboard interactions across a user’s whole visit — from the moment they act until the browser paints the next frame — and reports a single value that (close to) all interactions came in under.

INP is assessed at the 75th percentile of a page’s interactions in the field (with one outlier dropped for every 50 interactions), not the absolute worst one. The “good” target is ≤ 200 ms; 200–500 ms is “needs improvement,” and anything over 500 ms is “poor.”

INP replaced First Input DelayFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. (FID) as a Core Web Vital on March 12, 2024, and FID was fully removed from Chrome’s tools and CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. in September 2024. Unlike FID — which only timed the input delay of the first interaction — INP captures the full latency (input delay + processing + renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.) of every interaction. It’s a field metric; Total Blocking TimeTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. (TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital.) is its lab proxy.

Related: Core Web Vitals, TBT, LCP

Changelog