In web performance, what counts as a "long task" on the browser's main thread, why is the threshold 50 ms rather than a frame's 16 ms, and what does a single long task cost the user?

## One thread, one queue A browser tab does nearly all of its visible work on a single thread — the main thread. It parses HTML, runs your JavaScript, recalculates styles, performs layout, paints, and dispatches events. The browser feeds that thread a queue of **tasks**: evaluating a `<script>`, running a `setTimeout` callback, delivering a network response to its handler, dispatching a click. A task runs to completion — nothing preempts it partway through. Between tasks the browser can handle pending input and produce a frame; during one, it can do neither. ## The definition The Long Tasks API defines a long task as a **single task whose execution takes more than 50 ms**. Notice what that is not. It is not "the page spent three seconds in scripting" — that is an aggregate. It is not a slow network request; downloads happen off the main thread and only their handlers run on it. It is one uninterrupted block of work that held the thread for over 50 ms. The distinction matters practically. Ten consecutive 30 ms tasks add up to 300 ms of CPU work and produce zero long tasks — and, more importantly, they give the browser ten openings to dispatch a click or paint a frame. One 300 ms task gives it none. ## Why 50 ms and not 16 ms The number is derived from the response budget popularised by Google's RAIL guidance: a user should get visible feedback within roughly 100 ms of an interaction, or the interface stops feeling instantaneous. Input can arrive at any moment, including immediately after a task begins. If every task finishes within 50 ms, then in the worst case the browser starts processing that input 50 ms late and still has about 50 ms left to run the handler and paint a response inside the 100 ms budget. So 50 ms is deliberately *half the response budget* — headroom for the interaction itself. It is not one animation frame (about 16.7 ms at 60 Hz); a task can sit well under the long-task threshold and still cost you frames. ## What one long task actually costs While it runs, everything waits: - queued input events are not dispatched, so clicks and keystrokes feel ignored; - timer and promise callbacks do not run; - the next frame is not produced, so animation and scroll-linked effects stall; - the browser's own style, layout and paint work cannot proceed. Concretely, a frame at 60 Hz is about 16.7 ms, so a 300 ms task means roughly eighteen frames that never happen — the screen holds its last painted image and the page reads as frozen. Any input that arrived during the task also pays the remaining wait as extra latency before its handler even starts, which is precisely the delay that responsiveness metrics such as INP capture. ## Where long tasks come from At load time: evaluating and compiling a large JavaScript bundle, framework bootstrap or hydration of server-rendered markup, parsing a large embedded JSON payload, and third-party tag initialisation. At interaction time: sorting or transforming a large array, building thousands of DOM nodes in one go, expensive synchronous work inside an event handler, a large synchronous serialization, or drawing a complex canvas scene. ## Seeing them In a performance trace, long tasks show up as blocks over 50 ms on the main-thread track. Page audits aggregate them into Total Blocking Time. In the field a `PerformanceObserver` can report them directly: ```js new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log('long task', entry.duration); } }).observe({ type: 'longtask', buffered: true }); ``` ## The three moves — and one trap There are only three real answers: do less work, do it later, or do it somewhere else. Ship and execute less JavaScript at that moment; postpone work the user does not need yet; move pure computation off the main thread. The trap is treating the count as the goal. Splitting a 300 ms task into seven 45 ms tasks drives the long-task count to zero while the user still waits roughly 300 ms for their frame. The browser does gain six chances to interleave input, which is real, but the count is a proxy — the user's wait is the thing being measured.