Interaction to Next Paint (INP)

Interaction to Next Paint is the Core Web Vital for responsiveness. It asks a narrow question: when someone clicks, taps or types, how long until the browser paints a frame showing that something happened? It answers with one number for the whole visit.

The web.dev reference describes it as a stable Core Web Vital that uses the Event Timing API to observe the latency of every interaction a user made with the page, then reports a value that all, or nearly all, of them were beneath. It exists because load metrics miss most of the visit: Chrome usage data shows 90% of a user's time on a page is spent after it loads.

What are the INP thresholds?

Measured at the 75th percentile of field page loads, split by mobile and desktop:

Both halves of that sentence matter. It is the 75th percentile, so the typical visit passing is not enough: if a quarter of visits are slower than the threshold, the page fails. And it is field data, real visits on real devices, which is why a fast laptop on office wifi is not a measurement.

Which interactions does INP count?

Only three input types: a mouse click, a tap on a touchscreen, and a key press on a physical or onscreen keyboard. Hovering, zooming and scrolling are not observed, though a gesture that contains a click or tap can still be measured.

An interaction is the group of event handlers that fire during one gesture. A tap includes pointerdown, pointerup and click; a keystroke includes keydown, keypress and keyup. The longest event in the group sets that interaction's latency. Interactions inside iframes count too.

The final value is usually the worst interaction. On pages with many interactions one highest value is ignored for every 50, so a random hiccup does not define an otherwise responsive page. Most visits have fewer than 50 interactions, so in practice the worst one is what you see.

What makes an interaction slow?

An interaction's latency splits into three spans, and knowing which one is large is the whole of diagnosis:

• Input delay: from the input until any handler starts. Long tasks already running on the main thread show up here.
• Processing duration: the time all the handlers for that frame take to run. A handler doing too much shows up here.
• Presentation delay: from the end of the handlers until the frame is painted. Heavy layout, style recalculation or a very large DOM shows up here.

INP deliberately excludes the eventual effects of an interaction, such as network fetches and asynchronous updates. It measures how long the next paint is blocked. Showing immediate feedback and finishing the work afterwards is a legitimate fix, not a trick.

Do AI crawlers trigger INP?

No, and this is the mix-up worth clearing up. INP needs a person in a browser clicking, tapping or typing. An answer engine's crawler fetches your HTML over HTTP and leaves. Attensira's AI traffic documentation states the constraint plainly: AI crawlers do not execute JavaScript, so a browser script has never seen one.

The case that looks closest to a visit is a fetch a person triggered: someone asks Claude or ChatGPT a question and the assistant fetches your page to answer it. attensira.com counts crawler requests in its edge middleware, the only layer where a crawler is visible, and in the 30 days to 4 October 2026 35% of Anthropic's 104 requests and 3% of OpenAI's 7,536 were of that kind; the band below lists the pages ChatGPT-User reached. A person was waiting on every one of them, and still none ran a script, clicked a button or produced an INP value. The person got the assistant's answer, not your page. If attensira.com had a 900 ms INP, every one of those fetches would have read the page just the same.

So the two jobs are separate. Whether an answer engine can read and quote a page depends on access, server response time and text that exists in the HTML. Whether the person who clicks through from that answer has a good visit is where INP matters, because they land on the same page as everyone else.

How do you fix a poor INP?

Start from field data, not a lab run, and find which interactions are slow. Then match the fix to the span:

1. Input delay: break up long tasks, defer non-critical scripts, and move third-party work off the critical path.
2. Processing duration: do less in the handler; paint feedback first and schedule the rest.
3. Presentation delay: shrink the DOM the interaction touches and avoid layout thrashing.

Search Console's Core Web Vitals report groups URLs by status from field data, which is the usual starting point for finding which templates fail. See Core Web Vitals for the other two metrics in the set.

What goes wrong with INP work?

• Testing on a fast machine. p75 field data is what counts; a developer laptop is not a sample.
• Treating it as an AI visibility lever. Crawlers never interact, so INP work does not change what an answer engine can read.
• Fixing load speed for an interaction problem. A fast first paint and a slow click handler are different defects.
• Ignoring third-party scripts. Tag managers and widgets are a common source of input delay.

Does Attensira measure INP?

No. Attensira does not run a browser on your site or collect field interaction data, so it has no INP number to show you; use Search Console or your real-user monitoring for that. Its own page reads do not help either, and the docs say why: when a page is read for the agent, the fallback is a plain HTTP fetch with no JavaScript rendering, the same view a crawler gets. That is the useful split. INP tells you how the page behaves for the person who clicks through from an answer. Attensira tells you whether the answer exists: which engines name or cite the page, and, with crawler logs installed, whether their crawlers fetched it at all. Fix INP for the people who arrive; fix access and wording for the answers that send them.