What is going on here
Event listeners feel special — they seem to fire "when the user does something" — but the event loop treats them like everything else. The browser detects the click, then queues your listener as a task. It waits in the same queue as setTimeout callbacks, behind whatever is already there.
That single fact explains most perceived UI jank. A click cannot interrupt running JavaScript, because JavaScript is single-threaded and tasks never preempt each other. If a function is grinding through a 300ms loop when the user clicks, the handler simply waits 300ms. The click was registered instantly; the response was not.
It also explains why rendering is part of the same competition. The browser can only repaint between loop turns, once the stack is empty and microtasks have drained. Long tasks therefore delay both your handlers and the pixels, which is why the practical advice is always the same: break long work into smaller tasks, or move it to a worker.
Common questions
Are DOM event handlers macrotasks or microtasks?
Dispatched events queue tasks, so handlers are macrotasks and run one per event loop turn. The exception is an event dispatched synchronously from code — for example element.click() — which runs its listeners immediately on the current stack.
Why does my page ignore clicks during a long function?
The clicks are not ignored, they are queued. Handlers are tasks and a task can only start when the call stack is empty, so every click waits for the long function to return.
Do rapid clicks get merged into one event?
No. Each click queues its own task and each handler runs separately. If you want to collapse them, debounce or throttle in your own code.
Every question on one page →·Run your own code →
Embed this figure in your own post →Embed this figure
Drop this into any article or course page. It stays interactive — readers can step through it without leaving your site.