Walk me through what the browser actually does between a click handler running and the next frame appearing on screen.

The click handler runs to completion as a single task. Every microtask it queued, including resolved promise callbacks, drains next, before anything else happens. Only then, if a frame is due, does the browser run requestAnimationFrame callbacks and go through style, layout, paint and composite. A long task or an endless chain of microtasks delays that frame, and users read the delay as jank.

The handler itself is one task on the main thread, so it runs start to finish with nothing interrupting it. As soon as it returns, the browser drains the microtask queue, so any await continuation or promise then callback runs right there, and if those keep queuing more microtasks the browser never gets a chance to paint. Once that queue is empty, and only if a frame is actually due, the browser runs any requestAnimationFrame callbacks, recalculates style, does layout, paints and composites. That is why I treat long tasks as the real enemy. On a dashboard I worked on, a filter change did a synchronous sort of about forty thousand rows in the handler, and the click felt dead for roughly two hundred milliseconds. Splitting it so the handler only updated the input, then yielding with scheduler.yield before the expensive pass, kept the frame budget intact and the interaction started responding immediately even though the total work was identical.