Long Tasks API

Slap yourself if

You think a long task just means ‘some slow JavaScript’ and not a UI starvation event.

Why this exists

The Long Tasks API exists because frame drops, input lag, and jank are caused by main-thread monopolization, not average execution time. Without explicit signals, teams optimize the wrong metrics and miss the real cause of poor responsiveness.

Mental model

A long task is a period where the main thread is unavailable to do anything else. It’s not about how long code runs in isolation — it’s about everything else that gets blocked because of it.

  • The browser executes a task on the main thread.
  • If execution exceeds a threshold, it is classified as a long task.
  • Rendering, input, and timers are delayed until the task completes.
  • A performance entry is recorded after the task finishes.
  • Optimizing total JS time instead of task chunking.
  • Assuming async code can’t cause long tasks.
  • Blaming rendering when the main thread is blocked.
  • Ignoring user input delay in favor of FPS metrics.

The Long Tasks API exposes periods where the main thread is blocked for too long, directly correlating to input delay and jank rather than raw execution speed.

  • Single functions doing multiple phases of work
  • Large synchronous loops on the main thread
  • Work scheduled without yielding
  • Profiling that ignores task boundaries

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

What the browser actually flags as a long task

How long tasks turn into UX failures

Why eliminating long tasks isn’t free

Debugging with long task data

When long task metrics are insufficient