Long Task Observer
The Long Task API reports tasks that block the main thread beyond 50ms, so a performance monitor can find the jank source without instrumenting every function.
Definition
The Long Task API is a browser performance interface that reports every task that runs on the main thread for longer than 50ms, with its start time and duration, so that a performance monitor can identify the long tasks that cause jank and INP degradation without instrumenting every function on the critical path.
Context and scope
Applied in real user monitoring, performance regression detection, and any instrumentation that needs to find the source of main-thread blocking.
Common misconceptions
- The 50ms threshold is arbitrary — it is the threshold above which a task delays input processing enough to be user-visible; it is grounded in the RAIL model
- Long tasks are the only source of jank — they are the main-thread source; compositor and GPU thread jank also exist and the Long Task API does not see them
Anti-patterns
- Treating every long task as a problem, when some (initial parse, hydration) are expected and the budget is for the unexpected ones
- Sampling long tasks only in development, missing the long tasks that real users with slow devices and large data hit
Related concepts
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming
What it is
The Long Task API is a browser performance interface that reports every task that runs on the main thread for longer than 50ms, with its start time and duration, so that a performance monitor can identify the long tasks that cause jank and INP degradation without instrumenting every function on the critical path. Applied in real user monitoring, performance regression detection, and any instrumentation that needs to find the source of main-thread blocking. The browser is a hostile, shared, single-threaded (for JS) environment where every millisecond of main-thread work is a millisecond the user cannot interact.
How it works
The rendering pipeline — style, layout, paint, composite — is incremental and can be invalidated by any DOM change. Performance work targets avoiding the expensive phases (layout, paint) and scheduling the rest in idle callbacks or off the main thread. Loading work orders resources by their impact on the critical path: render-blocking scripts are deferred, images get fetch priority, and the server pushes what the client will need next.
When to apply and pitfalls
Apply when user interaction latency or load performance has a measured business impact. The pitfall is micro-optimizing a function while the page ships a megabyte of render-blocking JavaScript — the dominant cost is structural, not algorithmic. Another is measuring in the ideal lab profile and missing the long-tail devices and networks where most users actually live.