Interaction to Next Paint

For years, web performance meant measuring how fast a screen appeared. Under two seconds to first paint and the page was considered good. But a page being visible and a page being usable turned out to be different things. Behind the visible text and buttons sat a stretch where pressing something produced nothing at all.

That stretch surfaced through incidents. Tap a payment button, watch the screen sit unchanged for 0.7 seconds, and people assume they missed and press again. The same request goes in twice: two charges, or two identical comments. Support queues filled with duplicate-charge tickets while every number in the performance report stayed green, because the metric in use wasn't looking at that stretch at all.

The first fix was half a fix. The metric in this slot measured only how late the browser got around to handling the very first interaction on a page. Measuring the first one meant nothing from the following ten minutes was recorded — and the sluggishness people actually complained about lived in those ten minutes, filtering lists and opening items. Interaction to Next Paint (INP) widens the window to the whole visit, and moves the endpoint from the moment handling starts to the moment the screen visibly changes.

Every interaction gets timed from the press to the repaint, and the slowest of those times collected during the visit becomes that visit's INP.

A single interaction splits into three segments.

1. Input delay — from the finger landing until the browser starts handling the interaction. If the browser is busy with something else, the wait accumulates here.
2. Processing time — the stretch where the code attached to that interaction actually runs, including re-sorting a list or working out what to draw.
3. Presentation delay — from the end of that work until the changed screen is painted.

Add the three and you have that interaction's latency. Input delay of 40 milliseconds, processing time of 320, presentation delay of 30 comes to 390.

Clicks, taps, and keystrokes qualify. Scrolling and mouse movement aren't counted.

Choosing the representative value for one visit takes two steps.

1. With 50 interactions or fewer, take the slowest one as it stands.
2. Above 50, discard the slowest value for each 50 interactions and take the slowest of what remains. It keeps one freak result from standing in for the whole visit.

The site-level number collects those per-visit values and reads the 75th percentile. Reading one visitor in four from the slow end rather than an average means a page that's fine for most people and slow for some still shows up as slow.

At or under 200 milliseconds is good, 200 to 500 needs improvement, above 500 is poor. The 75th-percentile figure above is what gets held against those lines.

The 200 line comes from the limit at which a response still feels immediate. Inside it, the press and the screen change bind into one event. Past it they come apart into two, and waiting enters the picture. Somewhere around 500 that feeling turns into pressing again, which is where the duplicate charges and doubled comments come from. The thresholds are drawn from what people do at each delay rather than from taste.

The verdict has to come from real users. Measured on a developer's laptop the number usually looks fine — fast machine, small dataset. The same screen on a three-year-old budget phone holding a 2,000-row list stretches the same interaction to 600 milliseconds. So the number that counts is gathered across actual visits, not produced on one device.

When the number is bad, processing time is where to look first. It's usually the longest of the three segments, and the cause is usually code written to do too much at once. If the problem is shipping code the screen doesn't need yet, code splitting breaks it up so it arrives only when required. Where the work genuinely can't be reduced, an optimistic UI updates the screen on the assumption of success instead of waiting for the result, which cuts the felt delay even though the work is unchanged.

"INP is 480. Every filter click redraws the entire list."

The delay is concentrated in the processing time of one specific interaction.

"It doesn't reproduce locally. We have to look at field data."

A measurement from a development environment can't settle this.

"Let's take INP before LCP this sprint. Duplicate submission tickets are up."

The support volume points at responsiveness rather than loading.

At Pagedeck the number reached a meeting because of the document list screen. On teams with more than 500 documents, clicking a tag filter froze the screen briefly, and support started getting tickets saying the filter didn't work. It did work. It just took about 600 milliseconds to show, so people were clicking two or three more times.

Theo measured the three segments and found 520 milliseconds sitting in processing. Every filter click recalculated and redrew the whole list. Rewriting it to redraw only the changed rows brought processing down to 90 milliseconds, and Noa added a pressed state so the button acknowledged the click in the meantime. The next month's field data showed the 75th percentile down from 610 to 170, and the filter tickets stopped arriving.

The common misreading is that a slow number means a slow server. Slow response sounds like a request coming back late, so the assumption is easy to make. But this metric covers what happens inside the browser, so a faster server leaves the number untouched as long as the drawing code is heavy. Diagnose it as a server problem and you spend a quarter's budget on capacity with nothing to show for it, because none of the three segments being measured runs on the server.

Judging by the average is nearly as common. Most interactions finish inside 50 milliseconds, so an average always comes out looking healthy. The metric is built around the slowest interaction on purpose, and memory works the same way — people remember the moment the page felt stuck, not the mean. Report the average and a 500-millisecond interaction can appear in every single visit while the report says nothing is wrong.