Keeping the main thread responsive

The responsive thread

The browser main thread is where most page JavaScript runs. It is also where the page coordinates input events, style recalculation, layout, paint, and DOM updates. While one JavaScript task is running, the thread cannot handle another click, accept typing into an input, recalculate layout, or paint the next frame.

Plain definition: keeping the main thread responsive means making every user-visible task short enough that input and rendering get frequent turns. When work is too large for one turn, split it into chunks, schedule it for idle time, or move CPU-heavy data work to a Web Worker.

This lesson builds on The event loop, Microtasks in depth, Timers, and Web Workers. It also links to Animation, Typed arrays, Measuring performance, and the next Debounce & throttle lesson.

A long task is a main-thread task that runs for more than 50 ms. The threshold is intentionally larger than one animation frame: it marks work that is likely to be noticed or to block input on slower devices. The RAIL mental model is practical here: users expect input feedback quickly, animation frames have tiny budgets, idle work should be opportunistic, and loading should not steal interaction time.

Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. A good INP is 200 ms or less at the 75th percentile of real user visits. That percentile matters: one fast development laptop does not prove field users are safe.

1const observer = new PerformanceObserver((list) => {2  for (const entry of list.getEntries()) {3    console.log(entry.entryType, Math.round(entry.duration));4  }5});6 7observer.observe({ type: "longtask", buffered: true });8observer.observe({ type: "long-animation-frame", buffered: true });

PerformanceObserver can report longtask entries, and Chromium browsers also expose Long Animation Frame entries as long-animation-frame. Use these signals with DevTools and real-user monitoring from the Measuring performance lesson.

Yielding means stopping your current slice of work and letting the browser take other work before you continue. A task boundary can let input and paint happen; a microtask boundary usually cannot. The exact API you choose controls support, priority, and how quickly your continuation resumes.

1async function yieldToMainThread() {2  if (globalThis.scheduler?.yield) {3    await globalThis.scheduler.yield();4    return "scheduler.yield";5  }6  await new Promise((resolve) => setTimeout(resolve, 0));7  return "setTimeout fallback";8}9 10yieldToMainThread().then((mode) => {11  console.log("yielded with " + mode);12});

scheduler.yield() is the modern shape for pausing an async function and continuing soon with its priority. Chrome added it in version 129, newer Firefox versions support it, and stable Safari does not support it at the time of writing. That is why production code feature-detects and keeps a setTimeout fallback.

1const schedulerApi = globalThis.scheduler;2 3if (schedulerApi?.postTask) {4  schedulerApi.postTask(5    () => console.log("background task"),6    { priority: "background" },7  );8} else {9  setTimeout(() => console.log("fallback task"), 0);10}

setTimeout(fn, 0) is the universal fallback because it queues a later task. The Timers lesson covers the catch: after several nested timers, browsers clamp the minimum delay to about 4 ms. Some schedulers use MessageChannel to avoid timer clamping, and the Scheduler API adds priorities where it is available.

Chunking is the practical pattern for large arrays: do a small slice, yield, then continue. The helper below is a real function from this lesson. It accepts a time budget, a clock, and a yield function. The clock and yield are injectable so tests and the step-through can be deterministic.

1async function processInChunks(items, work, options = {}) {2  const budgetMs = Math.max(1, options.budgetMs ?? 8);3  const clock = options.clock ?? performance;4  const yieldFn = options.yieldFn ?? yieldToMainThread;5  let index = 0;6 7  while (index < items.length) {8    const started = clock.now();9    do {10      work(items[index], index);11      index += 1;12    } while (index < items.length && clock.now() - started < budgetMs);13 14    if (index < items.length) {15      await yieldFn();16    }17  }18}

1const jobs = [Run2  { label: "A", cost: 2 },3  { label: "B", cost: 3 },4  { label: "C", cost: 2 },5  { label: "D", cost: 4 },6  { label: "E", cost: 1 },7];8 9await processInChunks(jobs, (job) => {10  doWork(job.label);11  clock.advance(job.cost);12}, {13  budgetMs: 5,14  clock,15  yieldFn: () => yieldToBrowser(),16});

The replay uses jobs A through E with fake costs. A and B exactly fill the first 5 ms budget. C and D overrun the next budget slightly because a chunk finishes the current item before yielding. E finishes the final chunk, so no last yield is necessary.

1setTimeout(() => console.log("timer task"), 0);Run2let count = 0;3function scheduleNext() {4  count += 1;5  console.log("microtask " + count);6  if (count < 3) {7    Promise.resolve().then(scheduleNext);8  }9}10Promise.resolve().then(scheduleNext);11console.log("script done");

The bounded promise loop proves an important misconception from the Microtasks lesson: a promise chain is not a paint break. Microtasks drain before rendering, so long work must yield with a task-like boundary or leave the main thread.

requestIdleCallback asks the browser to run work when it has spare time. Its callback receives a deadline object, and deadline.timeRemaining() tells you how much idle time is left. Always pass a timeout for work that eventually matters, and always feature-detect because stable Safari does not support it by default.

1function scheduleIdleFlush(queue) {2  const run = (deadline) => {3    while (deadline.timeRemaining() > 0 && queue.length > 0) {4      sendAnalytics(queue.shift());5    }6    if (queue.length > 0) scheduleIdleFlush(queue);7  };8 9  if ("requestIdleCallback" in window) {10    return requestIdleCallback(run, { timeout: 2000 });11  }12 13  return setTimeout(() => run({ timeRemaining: () => 3 }), 1);14}

requestAnimationFrame has a different job. It runs before a paint, so it is for visual work such as reading animation state, writing transforms, or drawing a canvas frame. The Animation lesson covers that frame loop in depth.

Chunking still uses the main thread. If the job is CPU-heavy and can be described as input data plus output data, a worker may be the better home. Workers cannot read layout or update DOM, but they can parse, search, sort, compress, and process bytes while the UI thread keeps responding.

1// main thread2const worker = new Worker(workerUrl);3worker.postMessage({ type: "filter", query: "Ada", rows });4worker.onmessage = (event) => {5  renderRows(event.data.matches);6};7 8// worker.js9self.onmessage = (event) => {10  const { query, rows } = event.data;11  const matches = rows.filter((row) => row.name.includes(query));12  self.postMessage({ matches });13};

The Web Workers lesson covers lifecycle, structured clone, transferables, module workers, and errors. The Typed arrays lesson explains the byte buffers that often make worker transfers worthwhile.

The lab below keeps the CPU work bounded to about half a second per run. Watch the spinner and counter while typing in the input. Blocking mode runs one long task. Chunked mode does the same total work in slices with yields. Worker mode runs the CPU loop in a real Blob URL worker and sends a reply back.

1const modes = ["blocking", "chunked", "worker"];2 3// Blocking: one long task. Input, paint, and timers wait.4runButton.onclick = () => doCpuWork(450);5 6// Chunked: same total work, but yield between slices.7await processInChunks(items, work, {8  budgetMs: 24,9  yieldFn: yieldToMainThread,10});11 12// Worker: CPU work happens on another thread.13worker.postMessage({ ms: 450 });

Practical use

Main-thread responsiveness work is common in production. Search pages filter large lists, admin tools parse export files, image editors process pixels, dashboards batch analytics, and code editors highlight many lines. The right tool depends on urgency, DOM access, data size, and whether the work is already asynchronous.

Misconceptions

1button.addEventListener("click", () => {2  spinner.hidden = false;3  Promise.resolve().then(() => {4    expensiveLoop();5  });6});

The code changes the spinner state, but the expensive loop is placed in a microtask. The browser still drains that microtask before painting, so the spinner may not become visible until after the work is done.

Key takeaways

• The main thread runs JavaScript, input handlers, style, layout, and paint coordination.
• Long tasks over 50 ms can delay input and hurt INP; good INP is at most 200 ms at p75.
• Microtasks do not yield to rendering; promise loops can still freeze the page.
• Chunk arrays with a real budget and a feature-detected yield strategy.
• Use requestIdleCallback only for non-urgent work, with a timeout and fallback.
• Move CPU-heavy data work to workers when clone, transfer, and startup costs are worth it.

Up next: Debounce & throttle, where you will stop expensive handlers from starting too often in the first place.