INP: the three parts of a click

React chapter 145 · Web Perf · ch.5, 11 · input delay, processing, presentation · source: Nadia Makarevich, Web Performance Fundamentals, Chapters 5 and 11 (INP, long tasks); web.dev/articles/inp

The problem

“Add to cart” feels broken: you click and nothing happens for a third of a second. The handler recomputes recommendations before it updates the button, and an analytics script keeps the main thread busy, so the click waits even before your code runs.

The pattern that fixes it

Measure the three parts separately, then fix the one that is big. Input delay → break up other long tasks. Processing → update the visible feedback first, await the next paint, then do the heavy work. Presentation → render less DOM.

In plain words

INP (Interaction to Next Paint) is how long it takes from your click until the screen shows that something happened. The browser cannot draw while JavaScript is running, so any long piece of JS — yours or someone else’s — delays that first visible change.

A waiter (the main thread) can only do one thing at a time. If he is busy with another table, you wait (input delay). If he insists on cooking your whole meal before saying “got it”, you wait again (processing). A quick nod first, then cooking, feels instant.

Terms

input delay
Click happened → your handler starts. Caused by other tasks already running.
processing
Your event handlers, plus the synchronous React render and commit they trigger.
presentation
Style, layout and paint of the next frame. Bigger DOM changes, longer presentation.
INP
Roughly the worst interaction on the page (p98). Good ≤ 200 ms, poor > 500 ms.

Going deeper

Why `setTimeout(0)` alone is not enough here

Chapter 102 yields to keep a long loop interruptible. For INP you specifically want the *paint* to happen before the heavy work. A setTimeout(0) task can run before the browser’s next rendering opportunity. requestAnimationFrame(() => setTimeout(resolve)) waits until a frame is being produced, then resumes right after it — “after next paint”. scheduler.yield() is the modern primitive for chunking; pair it with rAF when the paint must come first.

Where React fits

A setState inside a click is a discrete event: React renders and commits it synchronously before the handler’s task ends, so its cost lands in “processing”. Wrapping the expensive part in startTransition (chapter 16) lets React render it in yielding slices after the urgent update paints. For non-React work (sorting, parsing, analytics) use the after-next-paint pattern or a Web Worker.

Finding it in DevTools

Performance panel → the Interactions track shows each interaction as a bar with input delay / processing / presentation whiskers. Set CPU throttling to 4–6× to simulate a mid-range phone. React DevTools → “Highlight updates” shows whether a keystroke re-renders the whole page (that is a processing problem, fixed by moving state down — chapter 89).

Keep learning

More courses

  • Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
  • Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
  • Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
  • System Design — Eight interview case studies, from a flash sale and Tatkal to a live final and a chat model, plus JWT in separate chapters.
  • Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
  • Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
  • Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
  • CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
  • Accessibility — HTML labs first, then a full pass of WAI-ARIA 1.3: naming, every state, widget and structure roles, live regions, ariaNotify, and relationships.
  • Docker — What an image is, why layers cache, and how containers find each other on a network.
  • Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.