Fixing Long Tasks on the Main Thread

What a long task is, and why 50 milliseconds

Browsers run almost everything a page does on one thread: parsing HTML, running JavaScript, working out styles and layout, and painting. Work is queued as tasks, and the browser can only check for new input and draw a new frame between tasks. The 50 millisecond threshold comes from the RAIL guidance: if every task is shorter than that, the browser can always respond to input within roughly 100 milliseconds, which people perceive as instant.

A task over 50 milliseconds is not a bug by itself. A single 60 millisecond task at page start-up is rarely noticed. Problems come from tasks of several hundred milliseconds, from many long tasks in a row, and from long tasks that land exactly when someone is trying to use the page.

Long tasks feed into several metrics. They are the raw material of Total Blocking Time in lab tests, they cause the input delay and processing time behind poor Interaction to Next Paint, and a long task that runs before the main image is added can hold back Largest Contentful Paint. This guide does not repeat how those metrics are calculated; the INP guide and the TBT guide cover that. Here the focus is on finding the tasks and changing the code inside them.

Finding the tasks real visitors hit

Lab traces on your own machine show the tasks that happen on your device, at your connection speed, on the pages you think to test. Real visitors on mid-range phones hit different ones. The Long Animation Frames API, available in Chromium-based browsers since 2024, reports slow frames from real visits together with the scripts that ran in them, which the older Long Tasks API never could.

// Report long animation frames with script attribution
if (PerformanceObserver.supportedEntryTypes?.includes('long-animation-frame')) {
  new PerformanceObserver((list) => {
    for (const frame of list.getEntries()) {
      if (frame.blockingDuration < 100) continue;   // keep only the painful ones
      const worst = [...frame.scripts].sort((a, b) => b.duration - a.duration)[0];
      navigator.sendBeacon('/log/loaf', JSON.stringify({
        page: location.pathname,
        blocking: Math.round(frame.blockingDuration),
        total: Math.round(frame.duration),
        script: worst?.sourceURL,
        fn: worst?.sourceFunctionName,
        invoker: worst?.invoker,        // e.g. an event listener or a timer
        kind: worst?.invokerType        // e.g. 'classic-script', 'event-listener'
      }));
    }
  }).observe({ type: 'long-animation-frame', buffered: true });
}

Collect this for a few days and group the results by script and fn. The same handful of functions usually account for most of the blocking time. The invokerType tells you how the work started: classic-script or module-script means the cost of evaluating a script file as it loads; event-listener means a handler; user-callback means a timer or animation frame callback; resolve-promise means code running after a promise settled, often after a fetch.

Firefox and Safari do not support this API yet, so treat the data as a sample from Chromium visitors. The code patterns it uncovers are the same in every browser.

The six kinds of long task and their fixes

Once you know which function is slow, look at what it is doing. Nearly every long task falls into one of these groups, and the right fix depends on the group.

Work that belongs to a third-party tag falls outside this list, because you cannot edit it. The third-party tags guide covers when and how to load it instead.

Slicing work by time rather than by count

A common way to break up a loop is to pause every so many items. The trouble is choosing the number: 200 items might take 5 milliseconds on a laptop and 80 on a budget phone. Slicing by elapsed time adapts to the device automatically. The loop works until it has used its budget, pauses so the browser can paint and handle input, then carries on.

const pause = () =>
  globalThis.scheduler?.yield
    ? scheduler.yield()
    : new Promise((r) => setTimeout(r, 0));

async function runInSlices(items, handleItem, budgetMs = 30) {
  let sliceEnds = performance.now() + budgetMs;
  for (const item of items) {
    handleItem(item);
    if (performance.now() >= sliceEnds) {
      await pause();
      sliceEnds = performance.now() + budgetMs;
    }
  }
}

// Usage: build 3,000 map markers without freezing the page
await runInSlices(branches, addMarker);

Keep the budget well under 50 milliseconds so that each slice, plus any rendering that follows it, stays short. Checking performance.now() on every item is cheap compared with almost any real work inside the loop.

Two cautions. First, slicing makes the total job take slightly longer, because the browser does other things in between; that is the point, but it means the result arrives later. Show progress or partial results where people are waiting. Second, if the data can change while the loop is paused, for example because the visitor typed a new search, check whether the job is still wanted after each pause and stop early if not.

Moving computation into a Web Worker

A Web Worker runs JavaScript on a separate thread. It cannot touch the page, but for pure computation, such as filtering a large product list, searching an index, parsing a big file or crunching numbers for a chart, it removes the work from the main thread completely rather than just breaking it up.

// search-worker.js
let products = [];
self.addEventListener('message', (e) => {
  if (e.data.type === 'load') {
    products = e.data.products;
  } else if (e.data.type === 'query') {
    const q = e.data.text.toLowerCase();
    const hits = products.filter((p) => p.name.toLowerCase().includes(q)).slice(0, 50);
    self.postMessage({ id: e.data.id, hits });
  }
});

// main.js
const worker = new Worker(new URL('./search-worker.js', import.meta.url), { type: 'module' });
let lastId = 0;

worker.postMessage({ type: 'load', products: catalogue });

searchInput.addEventListener('input', () => {
  worker.postMessage({ type: 'query', id: ++lastId, text: searchInput.value });
});

worker.addEventListener('message', (e) => {
  if (e.data.id === lastId) renderResults(e.data.hits);   // ignore stale answers
});

Data sent to a worker is copied, and copying a very large object costs main-thread time too. Send the big data once, as above, then send only small queries and small results. For large binary data such as image pixels or audio, transfer an ArrayBuffer instead of copying it.

The fix, step by step

Postponing start-up work safely

Much start-up work is not needed in the first second: analytics helpers, prefetching, restoring saved preferences for a widget further down the page. Deferring it spreads the cost into moments when the visitor is reading rather than tapping.

function whenIdle(job) {
  if ('requestIdleCallback' in window) {
    requestIdleCallback(job, { timeout: 3000 });   // run within 3 s even if never idle
  } else {
    setTimeout(job, 1500);
  }
}

// Initialise the reviews carousel only when it approaches the viewport
const reviews = document.querySelector('[data-reviews]');
if (reviews) {
  new IntersectionObserver(([entry], io) => {
    if (entry.isIntersecting) { io.disconnect(); initReviews(reviews); }
  }, { rootMargin: '400px' }).observe(reviews);
}

whenIdle(prefetchNextPage);

Idle callbacks run when the browser has nothing else to do, which on a busy page may be never, hence the timeout. They are also given a deadline, so long jobs inside them should still be sliced. Safari support for requestIdleCallback has lagged behind other browsers, which is why the fallback is there.

Edge cases and traps

• Garbage collection. Traces sometimes show long pauses labelled as garbage collection. They come from creating and throwing away lots of objects; reuse arrays and objects in hot loops rather than creating new ones each time.
• One big innerHTML. Assigning a huge HTML string is a single task that cannot be split. Build the content in parts, or render only the first screenful and add the rest later.
• Regular expressions. A badly written pattern run over long text can take seconds. If a trace points at a regex, test it with long inputs and simplify it.
• Tasks you cannot see locally. Personalisation, A/B tests and consent tools behave differently for first-time visitors. Test in a fresh private window with the cookie banner still showing.
• Splitting without shrinking. Slicing a job into twenty pieces keeps the page responsive but uses the same total CPU and battery. Always try deleting or postponing the work first.