Long Tasks and Yielding

Break up long tasks so INP survives: chunking, scheduler.yield, isInputPending, and framework patterns.

intermediate3 min readUpdated Aug 4, 2026

performance
long-tasks
yielding
inp
scheduling

When the main thread runs continuously past ~50ms, input and paint wait — long tasks that destroy INP. Yielding returns control to the browser between chunks so handlers can run and frames can render.

Docs: Optimize long tasks, Optimize INP, Long Tasks API.

Detect

new PerformanceObserver((list) => {
  for (const e of list.getEntries()) console.log('longtask', e.duration);
}).observe({ type: 'longtask', buffered: true });

DevTools Performance: red/long task bars around the click you care about.

Yield patterns

async function processAll(items) {
  for (let i = 0; i < items.length; i++) {
    doWork(items[i]);
    if (i % 32 === 0) {
      if (globalThis.scheduler?.yield) {
        await scheduler.yield();
      } else {
        await new Promise((r) => setTimeout(r, 0));
      }
    }
  }
}

scheduler.yield() is designed to continue the task with good prioritization when available — scheduler yield.

isInputPending

async function work(items) {
  for (const item of items) {
    doWork(item);
    if (navigator.scheduling?.isInputPending?.()) {
      await scheduler.yield();
    }
  }
}

Yield sooner when input is pending (Chromium).

After click: paint first

button.onclick = async () => {
  button.disabled = true; // visual feedback
  await scheduler.yield?.();
  await runExpensiveSave();
};

User sees response before the heavy work finishes — INP cares about next paint, not full completion.

Framework notes

React: startTransition marks updates non-urgent; still avoid huge sync reducers.
Avoid JSON.parse of multi‑MB payloads on click.
Virtualize lists instead of rendering 5k rows — virtual lists.

Idle is not yield

requestIdleCallback waits for idle; during continuous interaction it may not run. Use yield inside urgent flows — idle work.

Interview out-loud

“Long tasks block input and paint past 50ms. I chunk work and await scheduler.yield or setTimeout(0), paint UI feedback first, and verify with longtask entries and INP field data.”

How this shows up in interviews

Be ready to define the metric or technique in one sentence, name one measurement approach (DevTools panel, web-vitals, or headers), and cite a concrete fix you would try first. Walk through a before/after: what the waterfall or flame chart showed, what you changed, and which percentile moved. Mention a tradeoff (complexity, caching correctness, or third-party business constraints) so the answer doesn’t sound like a blog checklist.

Production guardrails

Ship behind a flag when the change is risky, watch field p75 for the affected template for at least a few days, and keep a rollback path. Pair lab verification (throttled Performance/Network) with RUM so you don’t celebrate a Lighthouse-only win. Document the owner of any ongoing budget or third-party exception.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.