Diagnosing INP: Input Delay, Processing Time, Presentation Delay

The plain-language idea

You already know INP measures how long the page takes to visibly respond to an interaction. What you can't tell from the single number is where the time went — and that matters, because the fix for "the handler itself is slow" is completely different from the fix for "something unrelated was blocking the thread when the click happened." Chrome's tooling splits every interaction into three sequential parts:

• Input Delay — time from the user's physical click/tap/keypress to the browser actually starting to run the event handler. This is almost never the handler's own fault; it's usually the main thread being busy with something unrelated at that exact moment.
• Processing Time — how long the event handler itself takes to run. This is the actual JS work: state updates, computations, whatever the handler does.
• Presentation Delay — time from the handler finishing to the next frame actually being painted. Often caused by expensive style recalculation or layout triggered by the DOM changes the handler made.

The diagnostic value is specific: a high Input Delay means you should be hunting for other long tasks on the page, not optimizing this handler. A high Processing Time means the handler itself genuinely needs to do less work, or defer some of it.

See it in a real thing: a click that looks slow but isn't the click's fault

// Somewhere else on the page, unrelated to the button:
function ProductList({ items }) {
  // A large, expensive re-render or a long synchronous computation
  // running on every parent re-render — not triggered by the click below,
  // but occupying the main thread whenever it happens to run.
  const sorted = expensiveSort(items);
  return <ul>{sorted.map(renderItem)}</ul>;
}

function AddToCartButton() {
  // This handler is fast — a couple of milliseconds of actual work.
  function handleClick() {
    addToCart(productId);
  }
  return <button onClick={handleClick}>Add to cart</button>;
}

A click happens. The next frame paint is the finish line for INP.

BackNext

If AddToCartButton's click feels sluggish, it's tempting to assume handleClick is slow and start optimizing it — but if expensiveSort happens to be running (triggered by an unrelated state update) at the exact moment the user clicks, the browser can't start handleClick until that unrelated work finishes. That shows up entirely as Input Delay, not Processing Time. Optimizing handleClick further would do nothing; the actual fix is breaking up or deferring expensiveSort so the main thread is free more often.

What people usually miss

Watch out

• High Input Delay is a main-thread scheduling problem, not a handler problem. The fix is finding and breaking up whatever long task was occupying the thread, which might be completely unrelated code elsewhere on the page.
• High Processing Time is the only one of the three that's actually about the handler's own code. This is where breaking up long synchronous work (chunking, requestIdleCallback-style deferral, or moving pure computation to a Web Worker) genuinely helps.
• High Presentation Delay is usually a layout/style cost, not a JS cost — a handler that changes many DOM properties at once can trigger expensive recalculation even if the handler's own JS ran quickly.
• A slow interaction rarely has just one cause. Real pages often show some Input Delay from background work and some Processing Time from the handler itself — the segment breakdown is what tells you how much effort to spend on each.

Why this matters in interviews

"This button feels laggy — how do you find out why?" tests whether a candidate defaults to reading the handler's code (easy to get wrong) or actually measures where the delay lands across Input Delay, Processing Time, and Presentation Delay first.