Interaction to Next Paint (INP) explained

Interaction to Next Paint (INP) measures how long a page takes to visibly respond when someone touches it. Not how long the whole operation takes to complete, and not how long the server takes to reply — how long before the screen changes in a way that tells the person their tap registered.

Google publishes 200 milliseconds as the threshold, from web.dev, checked on 3 August 2026. The internal target used on this site’s own builds is 150 milliseconds. Both numbers sound absurdly small until you remember what is being measured: the gap between pressing a button and seeing anything happen. People notice that gap well before a fifth of a second. And what they conclude is not “this page is slow”. It is “this is broken” — followed by a second tap, then a third, and then leaving.

What Interaction to Next Paint (INP) replaced — First Input Delay, and why that mattered

Interaction to Next Paint replaced a metric called First Input Delay. The change was not cosmetic.

First Input Delay measured only the delay before the browser could begin processing the first interaction on the page. Two limits followed. First, it looked only at the first interaction, so a page could pass on a harmless initial tap and be miserable for every interaction after it. Second, it stopped measuring at the point the browser started work, not the point anything appeared on screen. So a page that acknowledged a tap instantly, then froze for a second while it did the actual work, scored perfectly.

Interaction to Next Paint fixes both problems. It considers interactions across the whole visit. And it measures through to the next frame the browser paints — the moment a person can see that something happened. It is a harder metric to pass, which is the point. It describes the experience, not an internal milestone.

What makes INP poor across interactions: main thread contention from long tasks and event handlers

Almost everything here comes back to one idea: the browser runs your page’s JavaScript on a single main thread, and while that thread is busy it cannot respond to anything. Not a tap, not a scroll, not a keystroke. The work queues up behind whatever is already running.

INP’s three phases: input delay, processing time from event listeners, and presentation delay

INP is technically measured across three phases, added together for the total delay. Input delay is the time before the browser can start processing the interaction, often stretched by a busy main thread. Processing time is how long the event handlers and listeners that run in response take to finish. Presentation delay is the time between that work finishing and the browser painting the next frame the person can see.

A page can be slow in any one of the three. Working out which phase is at fault decides which fix helps. Deferring scripts reduces input delay. Breaking up long tasks reduces processing time. Simplifying what happens on interaction reduces presentation delay.

Long tasks. Any single piece of JavaScript that runs for a long stretch without yielding holds the thread. The classic offenders are large frameworks initialising, a page builder wiring up its interactive components after load, and an analytics or personalisation script doing setup work at the worst possible moment.

Too many third-party scripts. Chat widgets, tag managers, heat-map recorders, consent banners, review carousels, remarketing pixels and multiple analytics tools. Each is code from someone else’s server, running on your main thread, that you did not write and cannot profile easily. A tag manager is particularly deceptive because it looks like one script and is a container for however many the marketing team has added since.

Work done at the wrong time. Expensive handlers attached to events that fire constantly, layout recalculated inside a scroll handler, large lists rendered on interaction rather than prepared in advance.

Heavy hydration. On sites built with a JavaScript framework, the server can send a page that looks finished while the browser is still attaching interactivity to every element on it. During that window the page is a photograph of an application. Buttons are visible and do nothing. This is a specific and common failure mode, and it is invisible in a screenshot.

Why cheap Android phones are the real test (and what Chrome DevTools shows you)

Every one of the causes above is a computation problem, and computation is where device budgets differ enormously.

A current flagship phone will chew through a badly built page and hide the problem from you. A budget Android handset is the phone a large share of Australian consumers actually carry. It is also the phone most likely to be in the hand of a customer looking up a tradesperson from a job site. It has a slower processor, fewer and weaker cores, less memory, and aggressive thermal throttling that gets worse the longer the device is working. The same JavaScript that takes a moment on a developer’s laptop takes much longer there — and slower again if the phone is warm.

This is why testing on the phone in your pocket proves nothing if the phone in your pocket is expensive. The site is not being judged on your device. It is being judged on the device of the person who nearly rang you.

The practical instruction is short. Test on a low-end Android handset, on mobile data, or use the CPU throttling setting in Chrome DevTools to simulate one. Then tap the menu, tap the phone number, submit the form, and notice whether anything hesitates.

The fixes, in the order they usually pay

Remove scripts before optimising them. Every third-party tool on the page should have a named person who says what it is for and what decision it informs; the ones that fail that test are the cheapest performance win available, because deleting code is free and always works.

After that, four things help. Defer what can be deferred, so non-essential scripts run after the page is interactive rather than during. Break long tasks, so the thread yields and the browser can respond between chunks. Do work at build time rather than in the browser, wherever the content is the same for everyone. And load interactive components only where interactivity is actually needed, rather than across the whole page.

The accessibility overlap

Poor responsiveness is not only a speed problem. A page that ignores input for a moment, then processes a queue of repeated taps at once, is unpredictable. And unpredictable interfaces are hardest on the people who already have the most difficulty with them, including anyone using a keyboard, a switch device or assistive technology. Responsiveness and operability are the same property, looked at from two directions. That is why this belongs in the same conversation as website accessibility in Australia, and why the questions in the accessibility self-assessment are worth running on the same pages you are testing for speed.

Which scripts end up on a site, and who decides, is a build-time decision. That decision-making is covered on the Brisbane build page.