INP: answering every tap

Play this lesson

Sticky taps

Players on budget phones say planting in Shard Garden feels "sticky". Priya's field data agrees: INP is 420 ms.

Interaction to Next Paint (INP) is the time from a tap, click or key press until the screen next updates. Good is 200 ms or less, needs improvement is up to 500 ms, and poor is over 500 ms. It measures every interaction in the visit, not just the first.

Which interaction counts

INP watches mouse clicks, taps on a touchscreen and key presses. Hovering, scrolling and zooming are not measured.

It reports roughly the worst interaction of the whole visit. On busy pages it skips one of the slowest for every 50 interactions, so a single freak pause doesn't decide the score. A co-op match with hundreds of taps is judged by its slowest few.

Do the math

A player taps 400 times in one Shard Garden visit. Which tap's time becomes the visit's INP, roughly?

  1. The slowest tap
  2. About the 9th slowest tap
  3. The average of all 400 taps
Show the answer

About the 9th slowest tap

400 taps is 8 groups of 50, so INP skips the 8 slowest. The 9th slowest is reported. It is still a bad moment, not an average.

Three parts of every tap

The main thread and long tasks

A web page has one main thread. It runs our JavaScript, works out the layout and paints, and it can only do one task at a time.

Any task over 50 ms is a long task. If Shard Garden starts a 260 ms autosave just before a player taps "Plant", the tap waits in line for the rest of it. That wait is input delay, and the player feels all of it.

Read the numbers

One tap on "Plant", budget phone
input delay     260 ms  (the autosave)processing       40 mspresentation     30 ms----------------------total           330 ms

Which change targets the biggest part?

  1. Split the autosave into small pieces that give the main thread back between them
  2. Make the Plant handler 10 ms faster
  3. Use a smaller font on the Plant button
Show the answer

Split the autosave into small pieces that give the main thread back between them

Input delay is 260 of the 330 ms, and it comes from the autosave blocking the main thread. Shaving the 40 ms handler or the drawing barely helps.

Yielding: give the thread back

Yielding means pausing a long job so the browser can handle taps and draw frames in between.

await scheduler.yield() returns a promise that resolves in a future task, so everything after it runs later, as a new task. The pattern: do the visible work first (show the sprout), yield, then save and send analytics.

scheduler.yield() isn't in every browser yet, so we need a fallback: setTimeout with a delay of 0 also starts a new task, but at the back of the queue.

Bug hunt

plant.js
async function onTap(s) {  saveToCloud(); // 180 ms  sendAnalytics('plant');  drawSprout(s);  await scheduler.yield();}

The sprout appears late after every tap. What should Remy change?

  1. Draw the sprout first, then yield, then save and send analytics
  2. Delete line 5
  3. Call scheduler.yield() twice at the end
Show the answer

Draw the sprout first, then yield, then save and send analytics

The player waits for the 180 ms save before the sprout is drawn. Drawing first and yielding lets the browser paint the sprout, then the save runs as its own task.

Quick check

Hovering the mouse over a seed packet counts toward INP.

Show the answer

False

INP measures clicks, taps and key presses. Hovering, scrolling and zooming are not measured.

Measure it in the field

Lab tools can't measure INP, because no one taps during a test. Lighthouse reports Total Blocking Time (TBT) instead, which adds up how much long tasks block the main thread during load. A better TBT often means a better INP, but only real players' taps prove it.

Bolt says: Next: CLS, when things jump just as you tap them.

Fact-checked 11 October 2026