Interactivity: INP and the Main Thread

A page can paint fast and still feel broken. You tap a button and nothing happens for half a second. Interaction to Next Paint puts a number on that lag, and behind it sits one busy main thread doing more work than it should.

What INP measures

Interaction to Next Paint, or INP, measures overall responsiveness. It watches the latency of nearly all clicks, taps, and keypresses over the page's whole life, and reports a value close to the worst one, not the average. That is deliberate: one bad interaction sours the whole experience, so INP reports near the worst rather than hiding it in a mean. Good is 200 ms or less at the 75th percentile of real loads.

INP replaced First Input Delay on March 12, 2024. FID only timed the delay before the first interaction, which flattered most pages. INP watches almost all interactions across the session, so it is a far truer read on how responsive a page feels. FID is gone; do not report it. Because INP needs real interactions to observe, it is inherently a field metric: lab tools can only estimate it. INP is field-only, TBT is the lab proxy →

The parts of an interaction

Every interaction breaks into three phases, and INP measures the full span end to end.

• Input delay: the time before the event handler can even start, usually because the main thread is busy with other work.
• Processing time: how long the event handler itself runs.
• Presentation delay: the time from the handler finishing until the browser paints the next frame the reader sees.

Reading the phases tells you where to look. A large input delay points at a blocked thread before your code runs. A large processing time points at a heavy handler. A large presentation delay points at expensive rendering work per frame.

The main thread bottleneck

The browser runs your page on one main thread. It parses HTML, runs JavaScript, computes layout, and paints, all in the same single lane. When one job runs too long it blocks that lane, and while it runs the page cannot respond to a click. A long task is any task that holds the main thread for more than 50 ms, and a page full of long tasks feels frozen even though it painted fine.

The usual cause is heavy JavaScript and third-party scripts that all want the thread at once. In the lab you cannot generate real interactions, so you use a proxy: Total Blocking Time, or TBT, sums the main-thread blocking after first paint and is the best lab stand-in for INP. Treat its band edges as approximate, since they shift across Lighthouse versions. Fix in the lab against TBT, then confirm INP in the field. CSR, SSR, and hydration tradeoffs →

The browser has one main thread. Any task over 50 ms blocks it, so a click lands on a page that cannot answer. Shorter tasks are the whole game for INP.

How to improve INP

The core move is to stop hogging the thread. Break up long tasks by yielding, with scheduler.yield() where supported, so the browser can slot in a pending interaction between chunks of work. Defer and code-split non-critical JavaScript so less of it competes for the thread during load; the same deferral also frees the thread for first and largest paint. Deferring JS helps FCP and LCP →

Keep event handlers light. Give the reader immediate feedback, then defer the heavy work to a later frame instead of blocking the paint. Batch your DOM reads and writes so you do not force repeated layout, and virtualize long lists so you render only what is on screen. Trim third-party scripts, since each one you add spends someone else's budget on your thread. Where you can, prefer CSS animations and content-visibility so rendering work stays off the main thread. Once the page loads, stays stable, and answers fast, the remaining wins live in how you deliver the bytes. Delivery next →