Why the Browser's Main Thread Is the Real Bottleneck in UI Performance

Frontend performance work usually fixates on network requests, bundle size, caching, and re-renders, but none of that matters once the browser’s single main thread stalls. That one thread handles JavaScript execution, event handling, network callbacks, framework internals, and most of the rendering pipeline—style calculation, layout, and paint. Because JavaScript runs on a single-threaded event loop, only one task executes at a time, so a function that runs for 200ms freezes repaints and blocks user input for that entire stretch. Against a per-frame budget of roughly 10ms on a 60Hz display (halved at 120Hz), any task over 50ms counts as a ‘long task’ and shows up as jank: stuttering scroll, laggy typing, delayed button responses. This is precisely what the INP and TBT performance metrics quantify.

The article frames optimization as spending one expensive resource wisely, splitting the techniques into two families. The first keeps work on the main thread but manages its time through four moves: splitting long tasks into chunks, batching frequent work, prioritizing what runs first, and deferring what can wait. Splitting is foundational—the author’s live-stream chat demo shows that rendering a flood of messages in one shot tanks FPS and freezes input, while yielding control back to the browser after every 20 messages restores smoothness. Crucially, yielding doesn’t make the work faster; the total computation is unchanged. It just interleaves rendering and input handling into the gaps so the UI stays responsive.

The second family, only introduced here, moves work off the main thread entirely (e.g., to web workers or the compositor). The piece also flags a telling detail worth understanding: during a blocked main thread, JS-driven animations freeze while CSS animations keep running, because the latter can be handled by the compositor thread. The practical takeaway for engineers building interaction-heavy interfaces is that slow code is rarely the culprit—it’s code that happens to be holding a scarce, shared thread at the wrong moment.