Identifying Long Tasks and Layout Thrashing

The 50ms Budget That Rules Everything

The browser's main thread handles JavaScript execution, style calculation, layout, painting, and responding to user input — all on a single thread. When your JavaScript occupies that thread for more than 50ms straight, the user's next click, tap, or keystroke has to wait. That wait is what makes apps feel sluggish.

50ms is not arbitrary. Research on human perception shows that responses under 50ms feel "instant." Between 50-100ms, users notice the delay. Above 100ms, it feels broken. A long task is any single block of work on the main thread exceeding 50ms.

What Causes Long Tasks?

The Impact on INP

Interaction to Next Paint (INP) measures the time from when a user interacts (click, tap, key press) to when the browser paints the next frame showing the result. It is a Core Web Vital as of March 2024.

INP thresholds:

• Good: under 200ms
• Needs improvement: 200-500ms
• Poor: over 500ms

Long tasks directly worsen INP because:

1. If the user interacts during a long task, the browser cannot process the event until the task finishes (input delay)
2. If the event handler itself is a long task, processing takes too long (processing time)
3. Both add up to the total interaction latency

Long Animation Frames API (LoAF)

The Long Animation Frames API (LoAF) is the successor to the Long Tasks API. Where the Long Tasks API only told you "a long task happened for X ms," LoAF gives you the full picture: which scripts contributed, which functions were called, and how much time each took.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Long animation frame:', {
      duration: entry.duration,
      blockingDuration: entry.blockingDuration,
      scripts: entry.scripts.map(s => ({
        sourceURL: s.sourceURL,
        sourceFunctionName: s.sourceFunctionName,
        duration: s.duration,
        invokerType: s.invokerType,
      })),
    });
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

LoAF entries fire for animation frames that take longer than 50ms. Each entry includes:

• duration — total frame duration
• blockingDuration — time over the 50ms threshold
• scripts — array of script entries with source URLs, function names, and timing

Yielding Strategies

The solution to long tasks is to break them into smaller chunks, yielding control back to the browser between chunks. This allows the browser to process pending user input, repaint, and handle other events.

Strategy 1: scheduler.yield()

The modern, purpose-built yielding API:

async function processLargeArray(items) {
  const results = [];

  for (let i = 0; i < items.length; i++) {
    results.push(expensiveTransform(items[i]));

    if (i % 100 === 0) {
      await scheduler.yield();
    }
  }

  return results;
}

scheduler.yield() pauses execution, lets the browser process pending events and paint, then resumes your task with the same priority. This is the key advantage — your task does not get deprioritized to the back of the queue.

Strategy 2: setTimeout(0)

The classic approach:

function processInChunks(items, chunkSize, callback) {
  let index = 0;

  function nextChunk() {
    const end = Math.min(index + chunkSize, items.length);

    for (; index < end; index++) {
      callback(items[index]);
    }

    if (index < items.length) {
      setTimeout(nextChunk, 0);
    }
  }

  nextChunk();
}

setTimeout(0) yields to the browser, but your continuation goes to the back of the task queue. If other tasks are queued, they run first. This can make the total processing time longer.

Strategy 3: requestIdleCallback

For truly non-urgent work:

function processWhenIdle(items) {
  let index = 0;

  function processChunk(deadline) {
    while (index < items.length && deadline.timeRemaining() > 1) {
      expensiveTransform(items[index]);
      index++;
    }

    if (index < items.length) {
      requestIdleCallback(processChunk);
    }
  }

  requestIdleCallback(processChunk);
}

This only runs when the browser is idle. Perfect for analytics, prefetching, or background computation that the user is not waiting for.

Layout Thrashing

Layout thrashing (also called forced synchronous layout or forced reflow) happens when you interleave DOM writes and reads in a way that forces the browser to recalculate layout synchronously — potentially hundreds of times in a single frame.

How the Browser Normally Works

The browser batches style and layout changes. When you set element.style.width = '100px', the browser marks the layout as "dirty" but does not recalculate immediately. It waits until the end of the frame (or until something forces it) to process all changes at once.

When It Goes Wrong

const boxes = document.querySelectorAll('.box');

for (const box of boxes) {
  box.style.width = box.offsetWidth + 10 + 'px';
}

This looks harmless but is devastating:

With 1,000 boxes, you get 1,000 forced layout recalculations instead of one. Each recalculation costs 5-50ms depending on DOM complexity. Total: seconds of main thread blocking.

The Fix: Batch Reads, Then Writes

const boxes = document.querySelectorAll('.box');

const widths = Array.from(boxes, box => box.offsetWidth);

boxes.forEach((box, i) => {
  box.style.width = widths[i] + 10 + 'px';
});

All reads happen first (one layout calculation). Then all writes happen (layout dirty, but no read forces recalculation). The browser does one final layout at frame end.

The Fastdom Pattern

For complex applications, the fastdom library (or the pattern it implements) provides a structured way to batch reads and writes:

function updateLayout() {
  fastdom.measure(() => {
    const width = element.offsetWidth;
    const height = element.offsetHeight;

    fastdom.mutate(() => {
      element.style.width = width * 2 + 'px';
      element.style.height = height * 2 + 'px';
    });
  });
}

fastdom.measure() schedules reads. fastdom.mutate() schedules writes. Fastdom ensures all reads run before any writes within a frame, eliminating thrashing.

Properties That Trigger Forced Layout

Reading any of these properties after a style change forces a synchronous layout:

• offsetTop, offsetLeft, offsetWidth, offsetHeight
• scrollTop, scrollLeft, scrollWidth, scrollHeight
• clientTop, clientLeft, clientWidth, clientHeight
• getComputedStyle() — for most properties
• getBoundingClientRect()
• innerText (requires layout to compute visible text)

How to Spot in the Performance Panel

Layout thrashing appears as many small purple "Layout" bars in rapid succession within a single task:

┌────────────── Task ──────────────────────────┐
│ ┌JS┐┌Layout┐┌JS┐┌Layout┐┌JS┐┌Layout┐┌JS┐...│
│ └──┘└──────┘└──┘└──────┘└──┘└──────┘└──┘    │
└──────────────────────────────────────────────┘

If you see this JS-Layout-JS-Layout pattern repeating rapidly, you have layout thrashing. Click on any of the Layout bars — Chrome will show a warning: "Forced reflow is a likely performance bottleneck" and highlight the JavaScript line that triggered it.