Optimizing INP: Practical Patterns

The plain-language idea

This track's earlier INP-diagnosis lesson covered splitting a slow interaction into Input Delay, Processing Time, and Presentation Delay. The long-tasks lesson covered how to spot a long task occupying the main thread. Put together: once you know which part of an interaction is slow and what is occupying the thread when it shouldn't be, three concrete patterns are what actually close that gap.

Yield between chunks of work. A handler that does a large amount of synchronous work — say, processing a big array and updating state from it — runs as one uninterruptible block by default: nothing else, including the browser's own paint, can happen until it finishes. Breaking that work into smaller chunks and yielding to the main thread between them lets the browser paint or handle other input in the gaps, instead of the whole thing running as one long task.

Defer genuinely non-urgent work. Not everything triggered by an interaction needs to happen before the visible UI updates. An analytics call, a non-visual side effect, a background sync — none of these need to block the frame the user is waiting to see. Running the visible update first and pushing the non-urgent work to after it keeps the interaction itself fast.

Mark low-priority updates as low-priority. Some frameworks expose an API (conceptually similar to React's startTransition) that lets you tell the renderer "this state update can wait" so that urgent updates, like the visible feedback for the keystroke or click that just happened, aren't stuck behind it in the same render pass.

See it in a real thing: a handler that blocks a paint, and one that doesn't

// Blocks the main thread for the whole loop — no paint can happen until it's done.
function handleFilterChange(items, query) {
  const results = items.filter((item) => matches(item, query)); // expensive over a big list
  renderResults(results);
}

// Yields between chunks so the browser can paint (and handle other input) in the gaps.
async function handleFilterChangeChunked(items, query) {
  const results = [];
  const CHUNK = 500;

  for (let i = 0; i < items.length; i += CHUNK) {
    const chunk = items.slice(i, i + CHUNK);
    results.push(...chunk.filter((item) => matches(item, query)));

    // scheduler.yield() where available; setTimeout(fn, 0) as the fallback for
    // browsers that don't yet support it.
    if ("scheduler" in window && "yield" in window.scheduler) {
      await window.scheduler.yield();
    } else {
      await new Promise((resolve) => setTimeout(resolve, 0));
    }
  }

  renderResults(results);

  // Genuinely non-urgent — runs after the visible update, not before or blocking it.
  logFilterUsage(query);
}

A handler runs as one long, uninterruptible block. Nothing else -- including a pending paint -- can happen until it finishes.

BackNext

The chunked version does the exact same total amount of work. The difference is that it hands control back to the browser between chunks, so a paint the user is waiting on (or another input event) gets a chance to happen instead of queueing up behind the entire filter operation.

What people usually miss

Watch out

• Yielding doesn't reduce the total work — it redistributes when it happens. The chunked handler above does the same filtering, just interruptibly. The win is in not blocking, not in doing less.
• Deferred work still has to actually run. "Defer the analytics call" means run it after the paint, not skip it — a common mistake is deferring something and then forgetting to schedule it at all.
• Yielding has a real cost per yield point, not just a benefit. Each yield is a trip back through the event loop; yielding after every single array element instead of in reasonable chunks adds overhead without a meaningful responsiveness gain.
• startTransition-style APIs mark updates as low-priority, not the whole handler. The urgent part (the input reflecting what the user just typed) still needs to update immediately — only the more expensive downstream re-render gets deprioritized.

Why this matters in interviews

"You've diagnosed a bad INP down to a long-running click handler — what do you actually do about it?" is where this track's diagnosis lessons meet real engineering judgment: naming yielding, deferral, and priority-marking as concrete, applicable techniques (not just "make it faster") is what separates a candidate who's actually shipped this fix from one who's only read about the metric.