What Are Long Tasks? Complete Guide (2026)

Why Long Tasks Cost You Conversions and Rankings

Long tasks cause the most viscerally bad parts of a slow site:

• Dead clicks: A button is visible, but a long task is hogging the main thread when the user taps it. Nothing happens. They tap again. Now both clicks fire when the task ends — sometimes submitting the same form twice.
• Janky scrolling and animation: A frame must paint every ~16 ms to hold 60 fps. A 100 ms task drops 6 frames in a row — a clearly visible stutter.
• Failing INP, which is a ranking signal:INP became a Core Web Vital in March 2024. Pages that fail (75th-percentile interaction over 200 ms) lose ground in Google's Page Experience signal and tend to fall out of competitive results.
• Lower AI search visibility: AI answer engines (Google AI Overviews, Perplexity, ChatGPT) preferentially cite pages that already rank well. Pages that fail INP — almost always due to long tasks — get cited less.
• Bounce and rage: Industry analysis consistently links long tasks during interactions to higher bounce rates and lower conversion, especially on mobile, where CPUs are 4–6× slower than desktop.

How Long Tasks Are Measured (and Why 50 ms?)

The browser exposes long tasks through the Long Tasks API, which fires a PerformanceObserverentry for any task whose execution exceeds 50 ms. The 50 ms threshold is not arbitrary — it comes from Google's RAIL response-time model:

• Humans perceive a response as "instant" only if it lands within roughly 100 ms.
• The browser itself needs ~50 ms of headroom inside that window for event dispatch, hit testing, style recalc, and paint.
• That leaves ~50 ms as the largest single chunk of pure work the main thread can do without making the user feel a delay.

// Detect long tasks in any browser that supports the API
if ('PerformanceObserver' in window) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      console.warn(
        `Long task: ${entry.duration.toFixed(0)}ms`,
        entry.name,
        entry.attribution
      );
    }
  });
  observer.observe({ type: 'longtask', buffered: true });
}

How to Find Long Tasks on Your Site

• Greadme deep scan — runs a full audit, lists every long task on the page, attributes them to specific scripts, and pairs each issue with an AI-generated fix or a one-click GitHub PR. Start at greadme.com/deep-scan.
• Greadme crawler scan — scans every page on your site and flags templates whose long-task profile is dragging INP down.
• Greadme AI visibility analyzer — checks whether your pages are surfacing in AI answer engines, which is closely correlated with passing Core Web Vitals (and therefore with not having long tasks during interactions).
• Chrome DevTools → Performance tab — record an interaction; long tasks appear as red-tipped bars on the main-thread track. The flame chart shows exactly which function ran for how long.
• Long Tasks API in production — wire a PerformanceObserver to your real-user monitoring so you can see long tasks on real devices, not just simulated ones.
• Google Search Console → Core Web Vitals — surfaces pages failing INP at the 75th percentile, which is almost always a long-tasks problem.

8 Proven Ways to Eliminate Long Tasks

async function processItems(items) {
  for (const item of items) {
    doWork(item);

    // Yield so the browser can handle clicks and paint
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

// main.js
const worker = new Worker(
  new URL('./filter.worker.js', import.meta.url),
  { type: 'module' }
);

worker.postMessage({ query, dataset });
worker.onmessage = (e) => render(e.data);

requestIdleCallback(() => {
  flushAnalyticsQueue();
  prefetchNextRoute();
}, { timeout: 2000 });

Common Long-Task Issues and Fixes

How Long Tasks Relate to TBT, INP, and Other Metrics

Long tasks are the underlying primitive. TBT, INP, and TTI are aggregations of long-task behavior across different windows.

FAQ

Why is the long-task threshold exactly 50 ms?

It comes from Google's RAIL model. Humans perceive a response as "instant" only within ~100 ms; the browser needs about 50 ms of that for event dispatch and paint, so any single chunk of pure work over 50 ms eats into the budget the user can feel.

Are long tasks a Google ranking factor?

Indirectly, yes. Long tasks themselves aren't a ranking factor, but they directly determine INP, which became a Core Web Vital in March 2024 and is a confirmed input to Google's Page Experience ranking signal. Eliminating long tasks during interactions is the most reliable way to pass INP.

What's the difference between TBT and Long Tasks?

Long tasks are the underlying events; TBT is an aggregation. Specifically, TBT is the sum of (task_duration − 50 ms) for every long task between FCP and TTI. A page can have one 300 ms long task (TBT contribution: 250 ms) or six 100 ms long tasks (TBT: 300 ms) — different shapes, similar pain.

Will Web Workers fix every long task?

Only the ones that don't touch the DOM. Workers are perfect for parsing large JSON, search/filter over big datasets, image processing, and cryptography. Anything that mutates the DOM (rendering, layout, hydration) has to stay on the main thread — for those, the fix is yielding (scheduler.yield()), virtualization, or shipping less work.

How do I monitor long tasks in production?

Use a PerformanceObserver with type 'longtask'to capture them on real devices, send the data to your real-user monitoring, and alert when the 75th percentile of long-task duration crosses 100 ms on any high-traffic page. Greadme's crawler scan also surfaces this data per template.

Do AI search engines like ChatGPT and Perplexity care about long tasks?

Indirectly. AI answer engines preferentially cite pages that already rank well in traditional search. Long tasks degrade INP, which degrades Page Experience, which lowers rankings — and lower-ranking pages get cited less in Google AI Overviews, Perplexity, and ChatGPT browsing results.

Is setTimeout(fn, 0) still a valid yielding pattern?

It works, but scheduler.yield() is preferred when available. setTimeout(0) goes to the back of the task queue, which means other tasks (including unrelated ones) can run before yours resumes. scheduler.yield() is designed to resume your work next, with a single browser turn in between for input and paint.