Main Thread & Long Tasks
Schedule expensive synchronous work and watch input latency, animation smoothness and long-task duration degrade.
What you'll learn
- Feel the difference between a 50ms and a 500ms task
- Break work into yielding chunks
Interactive laboratory
Controls
synchronous CPU work, boundedThe target is a deadline for a spin loop, not a guaranteed duration. Work is capped at 1000 ms; there is no unbounded loop.
Frame monitor
0 frames recordedIdle.
Observed frame intervals
0 ms ─ 1 ms · bar height = interval since previous frame (clipped at 120 ms). Solid bars are intervals over 50 ms.
- Frames observed
- -
- Longest frame interval
- -
- Average interval
- -
- Actual work duration
- -
| Target | Strategy | Longest frame | >32 ms | >50 ms | longtask API |
|---|---|---|---|---|---|
| No runs yet. | |||||
PerformanceObserver('longtask') is unavailable in this browser. Everything shown is observed frame/task blocking measured from requestAnimationFrame, not Long Task API entries.
What happened?
Run a workload to record frame intervals.
16.67 ms is the cadence of a 60 Hz display, not a hard correctness line. What matters is whether the thread is free when the user acts - a 40 ms task during idle time is usually invisible, the same task during a drag is not.
Why it happened
The main thread runs your JavaScript, style, layout, paint and event handling.
Blocking it is the single most common cause of an interface that feels broken.
Key takeaways
- Anything over ~50ms on the main thread is a long task
- Yielding to the event loop restores responsiveness without removing work
Tags
- main thread
- long tasks
- INP
- responsiveness