A Long Task is any task that occupies the browser's main thread for more than 50 milliseconds without yielding control. The browser uses the main thread to process JavaScript, handle user input, calculate styles, and paint. When a single task runs for over 50ms, it blocks the browser from responding to user interactions smoothly, causing noticeable delays. The Long Tasks API (PerformanceObserver with entryType: 'longtask') allows developers to detect these problematic tasks programmatically.

INP (Interaction to Next Paint) measures the latency from a user interaction (click, tap, key press) to the moment the browser actually renders the next visual frame. Long tasks are the primary cause of poor INP scores. Here's why: when a user interacts with the page, if a long task is already running or starts shortly after, the browser cannot process the interaction until that task completes. The total INP includes the time spent waiting for the long task to finish plus the actual event processing and rendering time. Google considers INP ≤200ms as "Good", 200–500ms as "Needs Improvement", and >500ms as "Poor".

Total Blocking Time (TBT) is a lab metric that quantifies how much the main thread was blocked during page load. For each long task, the blocking portion is duration - 50ms (the amount exceeding the 50ms threshold). TBT is the sum of all these blocking portions. For example, if you have two long tasks of 120ms and 80ms, the TBT is (120-50) + (80-50) = 70 + 30 = 100ms. TBT strongly correlates with INP and is a key metric in Lighthouse performance audits.

Common sources include:

• Heavy JavaScript execution: Large loops, complex calculations, or unoptimized algorithms.
• Large DOM manipulations: Inserting, removing, or modifying many DOM nodes at once.
• Third-party scripts: Analytics, ads, social media widgets, and chatbots.
• JSON parsing: Parsing large JSON payloads on the main thread.
• CSS recalculation: Complex stylesheets triggering expensive reflows.
• Garbage collection: Major GC cycles can block the main thread.
• iframe content: Scripts running inside iframes that share the main thread.

Effective strategies include:

• Code splitting: Break large JavaScript bundles into smaller chunks that load on demand.
• Use setTimeout or scheduler.postTask(): Yield control to the browser by breaking long operations into smaller tasks.
• Web Workers: Offload heavy computation to a background thread.
• Debounce and throttle: Limit the frequency of event handlers (scroll, resize, input).
• Lazy loading: Defer non-critical scripts using defer or dynamic imports.
• Optimize rendering: Use requestAnimationFrame for visual updates and batch DOM changes.
• Monitor third-party scripts: Audit and remove or defer unnecessary third-party code.

The Long Tasks API (PerformanceObserver observing 'longtask') is a specification that is currently only implemented in Chromium-based browsers (Google Chrome, Microsoft Edge, Opera, Brave, etc.). Firefox and Safari have not yet implemented this API. If you're using a non-Chromium browser, consider using Chrome or Edge to run this tool, or use the "Simulate Long Task" feature to test the tool's functionality with artificial long tasks.

Long Tasks are a diagnostic metric—they tell you when the main thread is blocked for >50ms. INP is a user-centric metric—it measures the actual experience of a user waiting for visual feedback after an interaction. Long tasks are the root cause of poor INP, but INP specifically requires a user interaction to be measured. This tool helps you detect long tasks so you can proactively identify potential INP bottlenecks before they affect real users.

The "Simulate INP" feature creates a controlled demonstration by recording a click timestamp, executing a synchronous long task, then capturing the next requestAnimationFrame callback to determine when the browser paints. While this accurately demonstrates the relationship between long tasks and interaction delays, real-world INP is measured over many interactions and uses a more sophisticated methodology. Use this simulation to understand the concept, but always verify with real user monitoring (RUM) data for production insights.