Interaction to Next Paint (INP)

Quick definition

Interaction to Next Paint, or INP, measures how quickly a page responds visibly when someone clicks, taps, or presses a key. For each interaction, the browser measures the time from the input until the next frame is painted on screen. At the end of the visit, INP reports one of the slowest of these interactions.

INP is one of the three Core Web Vitals, next to Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS). Where LCP asks "when did the main content appear?", INP asks "when I used the page, did it react?"

The thresholds that count

The published ranges for INP are:

• Good: 200 milliseconds or less
• Needs improvement: more than 200 and up to 500 milliseconds
• Poor: more than 500 milliseconds

As with the other Core Web Vitals, the assessment uses the 75th percentile of page visits, separately for mobile and desktop. A page passes when at least three out of four visits stay at or below 200 milliseconds.

The numbers are not arbitrary. Research on perceived responsiveness suggests that feedback within roughly 100 milliseconds feels immediate, and the 200 millisecond threshold leaves room for real devices. Once a response takes half a second, most people notice the lag and start tapping again.

Which interactions count

INP observes three types of input:

• clicks with a mouse
• taps on a touchscreen
• key presses on a physical or on-screen keyboard

Hovering and scrolling do not count. Scrolling with the keyboard is a special case: the key press is an interaction, the scrolling it triggers is not.

One interaction often fires several events. A tap can produce pointerdown, pointerup, and click. The browser groups them and uses the longest event duration as the latency of that interaction.

If a visit has no interactions at all, it produces no INP value. That is why pages that people mostly read, such as long articles, often have little INP data, while shops, configurators, and web apps generate a lot of it.

How the value is chosen

INP is not the average. For most pages it is the slowest interaction of the visit. On pages with many interactions, the browser ignores one of the highest values for every 50 interactions, so a single unlucky outlier on a busy page does not define the result. In practice, the reported value sits close to the worst interactions users actually experienced.

This design is intentional. A page that responds instantly to nine clicks and freezes on the tenth still feels broken to the person who made that tenth click.

The three phases of an interaction

Every interaction latency breaks down into three consecutive phases. Knowing which one is slow tells you where to look.

1. Input delay: the time from the user's input until the event handlers start running. It grows when the main thread is busy with something else, for example a script that is still running from page load, hydration of a JavaScript framework, or a timer.
2. Processing duration: the time the event handlers themselves need. Heavy handlers that filter data, re-render large parts of the page, or send analytics synchronously make this phase long.
3. Presentation delay: the time from the end of the handlers until the browser paints the next frame. A large DOM, expensive style and layout calculations, and big rendering updates all slow this down.

The browser's main thread does most of this work in sequence. Any task that blocks it for more than 50 milliseconds is called a long task, and long tasks are the most common reason for poor INP.

Why INP replaced First Input Delay

Google made INP a Core Web Vital on March 12, 2024, replacing First Input Delay (FID). FID had two weaknesses. It only looked at the first interaction of a visit, and it only measured the input delay, not the time the handler needed or the time until the screen updated.

Many sites had near-perfect FID values while their users still experienced sluggish menus and filters later in the visit. INP closes that gap by covering all interactions and the complete path to the next paint. If an audit or dashboard still reports FID as the responsiveness metric, it is out of date.

What usually causes poor INP

• Busy main thread during load. Users often interact while the page is still running scripts. Large bundles, framework hydration, and third-party tags create input delay exactly when people first tap.
• Expensive event handlers. A click that triggers data processing, a full re-render of a component tree, and several tracking calls in one synchronous block keeps the user waiting.
• Large DOM and costly layout. Pages with thousands of elements, deeply nested structures, or code that reads layout values right after changing styles force the browser into expensive recalculation.
• Third-party scripts. Chat widgets, A/B testing tools, tag managers, and ad scripts compete for the same main thread. Each might be fine alone, and together they create long tasks.
• Slow devices. A handler that takes 40 milliseconds on a developer laptop can take several times longer on a mid-range Android phone. That is why mobile INP is usually worse than desktop INP.

How to improve INP

Fix the phase that is slow, and start with the interactions that matter most to users and the business.

For input delay, reduce the amount of JavaScript that runs during and right after load. Split bundles, defer scripts that are not needed immediately, and load third-party tags later or only where they are used. Frameworks that support partial or progressive hydration can reduce the work that blocks early interactions. JavaScript rendering for SEO covers the rendering side of these trade-offs.

For processing duration, give the user visible feedback first and do the heavy work afterward. Break long tasks into smaller ones and yield to the main thread between them, so the browser can paint in between. In Chromium-based browsers, scheduler.yield() is the cleanest way to do that; a setTimeout fallback works elsewhere. Move expensive calculations into a Web Worker, debounce handlers that fire on every keystroke, and send analytics without blocking the update.

jsasync function onFilterChange(event) {
  updateCheckboxState(event.target);   // visible feedback first
  await scheduler.yield();             // let the browser paint
  renderFilteredProducts();            // heavier work afterward
  queueAnalytics("filter_change");     // non-critical work last
}

For presentation delay, keep the DOM lean, avoid rendering large lists all at once, and avoid reading layout properties right after writing styles. CSS content-visibility can let the browser skip rendering work for content that is off screen.

Measuring INP correctly

Field data

INP is a field metric at its core. The Chrome User Experience Report collects it from opted-in Chrome users over a rolling 28-day window. PageSpeed Insights shows the URL or origin value when enough data exists, and the Core Web Vitals report in Google Search Console groups affected URLs.

CrUX tells you that a problem exists, not which interaction causes it. For that, real user monitoring helps. The open-source web-vitals JavaScript library has an attribution build that reports the interaction target, the interaction type, and the duration of each of the three phases. Combined with the Long Animation Frames API, it can point to the script responsible for a slow frame.

Lab data

A normal Lighthouse navigation test loads the page and stops. Nobody clicks, so it cannot measure INP. Lighthouse reports Total Blocking Time (TBT) instead, which sums up how much the main thread was blocked during load. TBT correlates with input delay problems, but a page can have low TBT and still have one slow handler that ruins INP.

To reproduce an interaction in the lab, use the Performance panel in Chrome DevTools. Its live metrics view shows the INP of your own interactions as you use the page. Turn on CPU throttling to simulate a slower phone, record a trace while repeating the slow interaction, and look for long tasks in the main thread track. Lighthouse also offers a timespan mode that records INP while you interact.

A worked example

An online shop sees poor mobile INP for its category pages. The team uses the web-vitals attribution build and finds that most slow interactions are taps on the size filter, with a processing duration of around 400 milliseconds on mid-range phones.

The trace shows one long task: the click handler updates the filter state, re-renders all 120 product cards, rewrites the URL, and fires two tracking calls, all in one block. The fix is to update the checkbox immediately, yield to the main thread, render the product list in smaller chunks, and send tracking afterward. The user now sees the checked box within one frame, and the list follows shortly after. The lab traces confirm that the long task is gone. The field INP improves over the following weeks as new visits replace the old data.

INP and SEO

Google uses Core Web Vitals in its ranking systems as part of page experience and recommends good values. Google is just as clear that relevance comes first. Improving INP will not make an irrelevant page rank.

The stronger argument is what INP measures: whether people can actually use your page. Slow responses on filters, forms, menus, and checkout steps hit the visitors who are trying to do something. On many sites, the templates with the worst INP are exactly the ones closest to revenue. Responsiveness also matters most on phones, where mobile SEO and mobile-first indexing already put the focus.

Common mistakes

• optimizing Lighthouse TBT and assuming INP is fixed
• testing interactions only on a fast desktop machine
• still reporting FID as the interaction metric
• loading every third-party script on every template, including pages that do not need it
• optimizing the first click and ignoring interactions later in the visit
• re-rendering a whole page section when only one element changed
• expecting field data to improve the day after a deployment

The Crawl Foundry perspective

Crawl Foundry's Site Audit uses the official Lighthouse runner (Lighthouse 13) on our own servers, with each measurement running as an isolated task. The Site Audit is a paid data action with the price shown before you start, and the Lighthouse measurement itself costs you nothing extra on top.

We want to be precise about what that can and cannot show for INP. A Lighthouse page load does not click anything, so it does not produce an INP value. It does show how heavily the main thread is blocked during load, which is a common cause of input delay. Use that as a lead, then confirm the slow interaction with field data, real user monitoring, or a DevTools trace. Because the Crawl Foundry Site Audit also records status codes, indexability, and internal links, you can focus that work on indexable templates that matter for search.

Related terms

• Page speed
• Server-side rendering
• Page experience metrics
• Web performance optimization
• User signals in SEO

Review sources

• web.dev: Interaction to Next Paint (INP)
• web.dev: Optimize Interaction to Next Paint
• web.dev: Optimize long tasks
• Google Search Central Blog: Introducing INP to Core Web Vitals
• Google Search Central: Understanding Core Web Vitals and Google search results
• Chrome for Developers: Long Animation Frames API
• W3C: Event Timing API