The page is slow to respond when real visitors interact with it

MediumConfirmedperf.crux.inp-poor

What this check looks for

When real visitors tapped, clicked or typed on ‹scope›, the page took ‹value› to show a visible response for a quarter of those interactions. Google's threshold for a good experience is 200 milliseconds.

Why it matters

This is the metric that makes a site feel broken rather than merely slow: the visitor taps a button and nothing happens, so they tap again. It is a Core Web Vital and it feeds Google's page experience signals.

When the check passes, your report says: “The page answers real visitors' taps within Google's threshold”.

What it costs your score

When this check fails it removes 12 points from your Performance score, before the status, confidence and repeat multipliers are applied. Performance carries a weight of 8 in the overall score.

It shares the performance.field family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from Performance. One underlying problem showing up in several places is still one problem.

Severity: medium
Default confidence: confirmed
Status when triggered: fail
Deduction: 12 points
Family cap: performance.field · 35
Category: Performance
Module: Perf crux
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Keep the time from a user interaction to the next painted frame under 200 ms for three interactions in four.

Visitors currently wait ‹value› for the page to acknowledge a quarter of their taps and clicks, which reads as an unresponsive or broken interface.

Find the long tasks. In Chrome DevTools, Performance → record an interaction → look for tasks over 50 ms on the main thread; those are what the user's tap is queued behind.
Break long work into smaller pieces and yield to the main thread between them (await scheduler.yield(), or setTimeout(…, 0) as a fallback) so the browser can paint.
Do the visible part of the work first. Update the UI in response to the interaction, then do the expensive bookkeeping after the next frame.
Remove or defer third-party scripts — analytics, tag managers, chat widgets and consent banners are disproportionately represented in long-task traces.
Cut the amount of JavaScript that has to be parsed and executed at all; the lab section of this report measures how much is shipped and how much of it goes unused.

How to confirm it worked

Re-run this scan after the change has been live for several weeks — field data uses a trailing 28-day window.
In Chrome DevTools, record a Performance trace of the slowest interaction and confirm no task exceeds 50 ms.

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Page HTML

// Paint the response first, then do the expensive work.
button.addEventListener('click', async () => {
	renderImmediateFeedback();          // cheap, visible, this frame
	await scheduler.yield();            // let the browser paint
	await doTheExpensiveWork();         // now the user is not waiting on it
});

scheduler.yield() is available in Chromium-based browsers; fall back to new Promise(r => setTimeout(r, 0)) elsewhere. The pattern matters more than the API: paint before you compute.

Technical detail

Interaction to Next Paint at the 75th percentile: **‹value›** (‹band›).

This is **field data**: the experience of real Chrome users who visited ‹scope› over the trailing 28-day collection window, not a measurement we took ourselves. The number quoted is the **75th percentile** — Google's own choice of statistic, meaning three visits in four were at least this good. A site with a fast median can still fail here, and that is the point: the quarter of visits that are worst are real people on real networks and devices.

Field data also lags. A fix you deployed yesterday will not move this number until it has been in front of users for most of the window, so use the lab measurements alongside it to confirm the change landed.

Google's published thresholds: **good at or below 200 ms**, needs improvement up to 500 ms, **poor above 500 ms**. INP replaced First Input Delay as a Core Web Vital in March 2024, and it is a much harder metric: FID measured only the delay before the *first* interaction was processed, while INP measures the full time from any interaction to the next frame painted, across the whole visit.

INP has three parts — input delay (the main thread was busy when the user acted), processing time (your event handler ran long), and presentation delay (rendering the result was expensive). Long JavaScript tasks are the usual cause of all three. ‹detail›