What this usually means
A long task is any chunk of JavaScript that executes on the main thread for more than 50 milliseconds (as defined by the Long Tasks API). The main thread is a single-threaded event loop — when it's busy, it cannot process user input, paint frames, or run other scripts. This often happens due to synchronous heavy computation (e.g., parsing large JSON, complex DOM manipulation), poorly chunked loops, or third-party scripts that block the thread. The browser cannot interrupt a running task, so all user interactions are queued until the task completes. In modern web apps, common culprits include React reconciliation with huge component trees, unoptimized data processing in event handlers, or synchronous XHR requests.
The first ten minutes — establish facts before touching code.
- 1Open Chrome DevTools > Performance tab, record activity while reproducing the jank. Look for red/orange bars in the Main thread timeline — those are long tasks.
- 2Click on a long task bar; check the 'Bottom-Up' call tree. Identify the function taking the most self-time (e.g., `JSON.parse`, `render`, `computeFib`).
- 3Enable 'Long Tasks' in the Rendering tab (DevTools > Rendering > Paint flashing) and observe which elements repaint during long tasks.
- 4Run `performance.getEntriesByType('longtask')` in the console to programmatically list long tasks — note their duration and attribution.
- 5In Chrome, check chrome://tracing or use the Performance Observer API: `new PerformanceObserver((list) => { list.getEntries().forEach(e => console.log(e)); }).observe({entryTypes: ['longtask']});`
The specific files, logs, configs, and dashboards that usually own this bug.
- searchChrome DevTools Performance tab: Main thread flame chart and Bottom-Up/Call Tree views
- searchChrome DevTools > Rendering > Paint flashing and 'Layer borders' to correlate long tasks with repaints
- searchWeb Vitals library output in console: `webVitals.getFID()` and `webVitals.getTTFB()`
- searchApplication code: event handlers (onclick, onscroll, etc.), `setTimeout`/`setInterval` callbacks, and requestAnimationFrame callbacks
- searchThird-party scripts loaded via `<script>` tags (especially sync scripts in <head>)
- searchLarge loops in `for`, `forEach`, `map` over big arrays (10k+ items) without breaking into chunks
- searchReact DevTools: 'Profiler' tab to identify expensive component renders and commit phases
Practical causes, not theory. These are the things you will actually find.
- warningSynchronous parsing of large JSON responses (e.g., a 5MB JSON file parsed on main thread)
- warningHeavy DOM manipulation inside a loop (e.g., appending 1000 list items one by one)
- warningReact/Vue/Angular re-rendering a large list or deeply nested component tree on every state change
- warningThird-party analytics or tracking scripts that block the main thread (e.g., unoptimized Google Analytics)
- warningExpensive computations in scroll/resize event handlers without debouncing/throttling
- warningUsing `Promise.all` with CPU-intensive synchronous tasks that still run on main thread
- warningImage decoding or canvas operations that happen synchronously on the main thread
Concrete fix directions. Pick the one that matches your root cause.
- buildChunk heavy loops using `requestAnimationFrame` or `setTimeout(0)` to yield to the browser between iterations
- buildOffload heavy computations to Web Workers — they run on a separate thread and don't block the UI
- buildUse `debounce` or `throttle` for scroll/resize/input handlers to reduce frequency of execution
- buildVirtualize long lists with libraries like react-window or IntersectionObserver to render only visible items
- buildDefer non-critical third-party scripts with `async` or `defer` attributes, or lazy-load them after page load
- buildUse `JSON.parse` streaming (e.g., `JSON.parse` with a ReadableStream) for large payloads, or parse incrementally
- buildBreak React renders by using `React.memo`, `useMemo`, `useCallback`, or splitting components into smaller chunks
A fix you cannot prove is a guess. Close the loop.
- verifiedRe-run the Performance record — confirm no red bars exceed 50ms for the same interaction
- verifiedCheck First Input Delay (FID) in Chrome DevTools > Performance > Summary — should be < 100ms
- verifiedRun Lighthouse audit — 'Avoid long main-thread tasks' warning should disappear or significantly reduce total blocking time
- verifiedTest on a mid-range mobile device (e.g., Moto G4) using Chrome DevTools device emulation to verify smoothness
- verifiedUse the Performance Observer API to confirm no new long tasks appear after the fix
- verifiedMonitor Real User Monitoring (RUM) data for FID and Long Tasks in production (e.g., via web-vitals library)
Things that make this bug worse or harder to find.
- warningAssuming all long tasks are due to your own code — profile before blaming; third-party scripts often cause more harm
- warningUsing `setTimeout(0)` inside a loop that still runs synchronously — it only delays but doesn't chunk work
- warningDebouncing without a leading edge — users may perceive delay if the function always waits
- warningOverusing Web Workers for trivial tasks — worker creation overhead can outweigh benefits for small computations
- warningIgnoring layout thrashing — accessing offsetTop or getBoundingClientRect inside a loop forces synchronous layout
- warningNot testing on actual low-end hardware — emulators don't fully replicate CPU throttling
The 3-Second Freeze on Checkout Click
Timeline
- 09:15Customer reports that clicking 'Place Order' freezes the page for 3 seconds on mobile
- 09:20I reproduce on a Moto G4 emulator in Chrome DevTools; the freeze is consistent
- 09:25Open Performance tab, record a click. See a 2.8s long task in the main thread
- 09:30Click on the long task — bottom-up shows `computeOrderSummary` taking 2.5s self-time
- 09:35Inspect code: `computeOrderSummary` iterates over a list of 5000 items, calculates discounts, taxes, and applies coupon logic — all synchronous
- 09:45I refactor to chunk the work using requestAnimationFrame, updating the UI progressively with a loading state
- 09:55Re-run performance — longest task is now 80ms, FID drops from 300ms to 45ms
- 10:00Deploy to staging, verify on real devices, then push to production
The alert came from our customer support channel: users on older Android phones were complaining that the checkout button 'just hangs' after tapping. I immediately grabbed my test device — a Chrome DevTools emulation of a Moto G4. Reproduced in one tap. The page froze for about three seconds before showing an order confirmation. That's a guaranteed bounce.
I recorded a performance profile. The main thread showed a massive red bar: 2.8 seconds of solid blocking. The call tree pointed straight to `computeOrderSummary` — a function I wrote months ago. It was doing all the heavy lifting synchronously: calculating discounts for each of 5000 items, applying coupon logic, summing totals. I never expected the cart to have that many items.
The fix was straightforward: chunk the computation into batches of 100 items using `requestAnimationFrame`. Each chunk updates a progress indicator and yields to the UI. The final total is assembled after all chunks. After the change, the longest task was under 80ms, and the user saw a spinner instead of a dead screen. FID dropped from 300ms to 45ms. We shipped it that afternoon.
Root cause
Synchronous computation over 5000 items in the main thread without yielding, blocking all UI updates for 2.8 seconds.
The fix
Chunked the work using requestAnimationFrame, processing 100 items per frame and updating the UI incrementally.
The lesson
Always assume your data can grow. Any loop over an unbounded collection should be chunked or offloaded to a Web Worker if the computation is heavy.
The Long Tasks API (PerformanceLongTaskTiming) exposes tasks that take >50ms on the main thread. You can observe them via PerformanceObserver. This is critical for RUM — you can instrument your app to collect long tasks in production and correlate them with user interactions.
Each long task entry includes attribution pointing to the container (e.g., 'iframe' or 'script') and the culprit function if source maps are available. Use this data to prioritize optimizations based on real user impact, not just lab tests.
requestAnimationFrame (rAF) is preferred for UI-related work because it runs just before the browser paints. A typical pattern: create a generator function that yields after each chunk, and schedule the next chunk via rAF. This ensures the UI stays responsive and the user sees incremental updates.
setTimeout(fn, 0) can cause the callback to be delayed if other tasks are queued, and it may run at lower priority than rAF. For pure computation, consider using scheduler.postTask() (if available) or a Web Worker. The key is to break the work into pieces < 50ms each.
Often, long tasks are caused by third-party scripts. Chrome's Performance panel shows the 'Attribution' tab for a long task, indicating which iframe or script URL is responsible. Use this to identify problematic third parties.
Mitigations: load third-party scripts with `async` or `defer`, use resource hints like `<link rel="preconnect">`, or lazy-load them after the user interacts. Consider using a service like Partytown to run third-party scripts in a Web Worker.
React's reconciliation can cause long tasks when re-rendering large component trees. Use React DevTools Profiler to record a flame graph of component renders. Look for components that re-render too often or take too long to render.
Fix with `React.memo`, `useMemo`, `useCallback`, and breaking lists into virtualized components. Also consider using `useDeferredValue` (React 18) to defer non-urgent updates. If a component's render function is doing heavy computation, move that computation outside the render phase.
Frequently asked questions
What exactly is a 'long task' in the browser?
A long task is any JavaScript execution that occupies the main thread for more than 50 milliseconds. The browser cannot process user input, paint, or run other scripts during that time, leading to jank.
How do I find which function is causing a long task?
Record a performance profile in Chrome DevTools, click on the long task bar, and examine the 'Bottom-Up' or 'Call Tree' tab. The function with the highest self-time is the main culprit. You can also use the Long Tasks API to log them programmatically.
Should I always use Web Workers for heavy computations?
Web Workers are great for CPU-intensive tasks that don't need DOM access, like data processing or encryption. But for UI-related work (e.g., rendering), chunking with requestAnimationFrame is simpler. For small tasks, the overhead of creating a worker may not be worth it.
Can long tasks be caused by CSS or layout?
Yes, but the Long Tasks API specifically measures JavaScript execution. However, layout thrashing (forcing synchronous layout by reading/writing DOM) can cause style recalculations that appear as long tasks. Use DevTools to check 'Rendering > Layout Shift' and avoid reading layout properties inside loops.
What tools exist for monitoring long tasks in production?
You can use the PerformanceObserver API to capture long tasks and send them to your analytics (e.g., Google Analytics, Datadog). The web-vitals library also tracks FID which correlates with long tasks. Tools like Lightrun or Sentry can provide real-time visibility.