Interaction to Next Paint (INP)

A near-worst delay between tapping something and the screen visibly changing. Under 200ms feels instant, past 500ms feels broken.

the page feels laggy when I clickbuttons don't respond right awayINPinput lag on the webclick delayinteraction to next paint scorethe UI freezes for a moment after I tapthe metric that replaced FID

See it

Live demo coming soon

What it is

INP watches every click, tap, and key press for the whole visit and reports a representative near-worst one: the gap between the input and the next frame the browser paints in response. Not literally the maximum, either. On a page with lots of interactions the metric discards one worst interaction for every 50 recorded, so a single freak stall does not define your score, but a habit of them does. Under 200ms feels instant, 200 to 500ms feels sluggish, past 500ms feels broken. It became a Core Web Vital in March 2024, replacing FID.

Split a slow interaction into three phases: input delay (the main thread was busy with something else when you tapped), processing time (your event handler running), and presentation delay (style, layout, paint before the pixels land). Big framework re-renders show up in processing time, third-party analytics and hydration show up in input delay, and giant DOM trees show up in presentation delay.

Gotcha: FID only measured the delay before the first handler started, so almost everyone passed it. INP measures until the screen actually changes, on every interaction, so plenty of sites that were green went red overnight. The cheapest fix is usually to paint a visual response first (disable the button, show the pending state), then yield with await scheduler.yield() and do the expensive work after.

Ask AI for it

Reduce this page's Interaction to Next Paint. For each slow handler: paint the visual acknowledgement first (pressed/disabled/loading state), then yield to the main thread with await scheduler.yield() (or a setTimeout fallback) before running the expensive work. Break any task over 50ms into chunks, mark non-urgent state updates as transitions, memoize the components that re-render on every keystroke, debounce input handlers, and move pure computation to a Web Worker. Load third-party scripts with defer or on idle. Target INP under 200ms on a 4x-throttled CPU and report the input delay, processing, and presentation split for the slowest interactions you can reproduce.

You might have meant

core web vitalslong taskmain thread blockingtotal blocking timejavascript execution cost

Go deeper