What is INP? Interaction to Next Paint explained

What INP measures

For every tap, click or key press during a visit, the browser times how long it takes from the interaction until the next frame is drawn on screen. INP reports the longest of those interactions, ignoring outliers: on a visit with many interactions, one of the worst is left out for every 50 interactions, so one odd hiccup does not decide the score. Most visits have fewer than 50 interactions, so INP is usually simply the slowest one.

What counts is limited on purpose. A tap, a click and a key press count. Hovering and scrolling do not. A single gesture, such as a tap, fires several events (pointer down, pointer up, click), and the interaction's time is the longest of them. A page that nobody ever taps has no INP at all.

What counts as good

A page passes when at least 75% of its real visits meet the good mark. INP is one of the three Core Web Vitals. Most sites already pass: in the 2025 Web Almanac, 77% of websites had a good INP on mobile, up from 74% the year before.

Why FID is gone

First Input Delay was the responsiveness metric until March 12, 2024. It had two limits. It measured only the first interaction on a page, and only the wait before the browser started handling it, not the handling itself or the redraw. A page could have an excellent FID and still freeze on every tap after the first. INP covers every interaction and the whole response, from the tap to the next frame, so it replaced FID. If an article, plugin or report still lists FID as a Core Web Vital, it is out of date.

The three parts of an interaction

1. Input delay. The time from the tap until the browser can start running your event handlers. The delay is there because the main thread was busy with something else, usually a script.
2. Processing duration. The time your own handlers take to run, from the first one starting until the last one finishes.
3. Presentation delay. The time from the handlers finishing until the next frame is on screen. It includes the browser's own work: style and layout calculation, and the callbacks for animation and observers, and the drawing itself.

Lighthouse 13 and the Performance panel of Chrome DevTools show these three parts as an "INP breakdown" for an interaction you record. The longest part is the first place to look, because it tells you which kind of fix to use: a long input delay needs less work on the page at that moment, a long processing duration needs a lighter handler, and a long presentation delay needs a cheaper update of the page.

Find the slow interactions

INP is a field metric. A standard Lighthouse test loads the page and nobody taps anything, so it cannot measure INP; Lighthouse measures it only in its "timespan" mode, where you interact with the page during the recording. PageSpeed Insights shows whether INP passes for real visitors, but not which interaction is slow. To find it:

• Chrome DevTools. Open the Performance panel, use the live metrics view, and click through the page like a visitor. Each interaction is logged with its breakdown.
• Real-user data. Google's open-source web-vitals library has an attribution build that reports, for the interaction that set INP, the element that was touched, the three parts above, and the scripts involved.
• Long Animation Frames. The Long Animation Frames API, available in Chrome from version 123 and not in other browsers, lists the frames that took too long and the scripts that ran in them.
• Search Console. The Core Web Vitals report groups real URLs by INP status, so you know which pages to look at first.

Fix a long input delay: keep the page free

A script that is still running when a visitor taps delays the response, and the worst time is while the page is loading. Defer scripts the page does not need yet, remove JavaScript nobody uses, split large bundles, and load third-party scripts late. The Total Blocking Time guide covers the loading side of this.

Fix a long processing duration: do less in the handler

Update what the visitor sees first, then do the rest. Avoid looping over large lists, rebuilding big parts of the page, and reading layout values in the middle of an update, which forces the browser to recalculate layout again and again. Work that is not needed for the next frame can wait.

Give the browser a turn

The whole subject, with more techniques, is in the guide to breaking up long tasks. Heavy work that does not touch the page can move to a thread of its own: see web workers.

When a task has to be long, break it into pieces and let the browser draw between them. scheduler.yield() does this: it pauses your code, lets the browser handle input and painting, and then continues. It works in Chrome 129 and later and in Firefox 142 and later, but not yet in Safari, so use a fallback:

const yieldToMain = () => (globalThis.scheduler?.yield ? scheduler.yield() : new Promise((resolve) => setTimeout(resolve)));

async function onSave() {
  showSavingState();      // what the visitor sees first
  await yieldToMain();    // let the browser draw it
  saveEverything();       // the heavy work
}

Fix a long presentation delay: make the update cheaper

A very large page takes longer to recalculate and draw after every change. Keep the page structure small. On long pages, content-visibility: auto on sections below the first screen lets the browser skip the work of drawing them until they are needed; it works in Chrome 85, Firefox 125 and Safari 18 and later. Avoid changes that touch the whole page after a tap, such as toggling a class on the body of a large page.

Check third-party scripts and plugins

Chat widgets, tag managers, ad scripts, testing tools and consent banners all run code on your visitor's device. The "3rd parties" insight in PageSpeed Insights shows how much main-thread time each one uses. Remove the ones you do not need. On WordPress, remove plugins whose scripts you do not need on a page, and avoid heavy sliders, animation libraries and large menus. Some optimization tools delay all scripts until the first interaction. That can backfire: every delayed script then runs at the moment of the first tap, which is exactly when a slow response is felt.

INP in the lab

Because a normal lab test has no interaction, use the lab number that moves with it: Total Blocking Time. The 2025 Web Almanac notes that TBT and INP are correlated, so a page with a high TBT usually has trouble with INP too. It is a hint, not a guarantee, since INP also depends on what people tap and when.

Check your own page

Run the free audit to see whether real visitors get a good INP on your page. If the page is rated needs improvement or poor, record a few of the interactions people use most, such as opening the menu or adding an item to the cart, in DevTools. Start with the one that has the longest of the three parts.

Sources

• Interaction to Next Paint (INP) on web.dev: what is measured, how the score is formed and what is excluded.
• Optimize Interaction to Next Paint on web.dev: the three parts and how to improve each.
• The web-vitals library: the attribution build and its definitions of the three parts.
• Performance chapter of the 2025 Web Almanac: the INP and TBT figures above.
• Scheduler: yield() on MDN.