Long Tasks: What is it & How it Impacts Core Web Vitals

What is Long Tasks?

In the context of web performance, a Long Task is defined as any continuous period of JavaScript execution that exceeds 50 milliseconds. Because the browser’s main thread is responsible for handling user input, rendering updates, and executing scripts, it can only perform one action at a time. When a script runs for an extended duration, it “monopolizes” the thread, causing the browser to become unresponsive to user interactions such as clicks, taps, or scrolls.

The 50ms threshold is based on the RAIL model, which suggests that to provide a response within 100ms (the threshold for perceived instantaneous response), the browser must finish processing the input and rendering the frame within that window. By limiting individual tasks to 50ms, the browser ensures it has enough remaining time to process the event loop and update the UI without perceptible lag.

The Real-World Analogy

Imagine a single-window post office with a long line of customers. Most people are there to buy a single stamp, which takes 10 seconds. However, one customer arrives with twenty large boxes that require individual weighing, labeling, and custom forms, taking 20 minutes to process. Because there is only one clerk (the main thread), everyone behind that customer must wait, even if their request is simple. In web performance, that 20-minute customer is a Long Task, and the frustrated people in line are the user interactions waiting to be processed.

Why is Long Tasks Critical for Website Performance and Speed Engineering?

Long Tasks are the primary contributors to Total Blocking Time (TBT) and Interaction to Next Paint (INP). When the main thread is blocked, the browser cannot acknowledge a user’s click or keypress until the task completes. This leads to a “frozen” UI experience, which is a major signal of poor quality to both users and search engines. In the era of Core Web Vitals, minimizing Long Tasks is essential for maintaining a high INP score, which measures the latency of all interactions throughout the page lifecycle.

Furthermore, Long Tasks delay the First Contentful Paint (FCP) and Largest Contentful Paint (LCP) if the main thread is too busy executing non-critical JavaScript to handle the rendering of DOM elements or the decoding of images. For enterprise-level applications, unoptimized Long Tasks result in higher bounce rates and lower conversion metrics due to the perceived sluggishness of the interface.

Best Practices & Implementation

• Yielding to the Main Thread: Break up large functions into smaller, asynchronous chunks using setTimeout() or the modern scheduler.yield() API to allow the browser to process pending high-priority tasks between script executions.
• Web Workers: Offload heavy computational logic, data processing, or complex algorithms to a background thread (Web Worker), keeping the main thread free for UI rendering and user input.
• Code Splitting and Tree Shaking: Reduce the initial payload of JavaScript by only loading the code necessary for the current view, thereby reducing the time spent parsing and executing scripts during page load.
• Audit Third-Party Scripts: Monitor and throttle third-party analytics, ads, and social widgets, as these are frequent sources of unoptimized Long Tasks that are outside the developer’s direct control.

Common Mistakes to Avoid

One frequent error is the use of synchronous XMLHttpRequest or heavy loops within the main execution context, which guarantees thread blockage. Another common mistake is failing to prioritize critical CSS and JS, leading to “hydration” bottlenecks in framework-heavy sites where the entire application attempts to become interactive at once, spawning multiple Long Tasks simultaneously.

Conclusion

Managing Long Tasks is a fundamental requirement for modern speed engineering, ensuring the main thread remains fluid and responsive to user input for optimal Core Web Vitals performance.