Why the Browser's Main Thread Is Your Most Expensive Resource

Frontend optimization discussions typically focus on reducing network requests, shrinking bundles, or minimizing re-renders. However, author kciter argues the real bottleneck in complex, interaction-heavy screens is the browser's main thread. The main thread handles nearly everything accessible from JavaScript: code execution, event handling, network response callbacks, framework internals, style calculation, layout (reflow), and paint. Only the final compositing step is offloaded to the compositor thread. On a standard 60Hz display, the browser must render a frame every 16.6ms. After subtracting browser overhead, the practical JavaScript budget is approximately 10ms per frame—halved on 120Hz devices. When the main thread is blocked beyond this budget, users experience jank: stuttering scrolls, delayed button responses, and lagging input. The article outlines strategies organized into two groups: using the main thread wisely (splitting tasks, batching DOM operations, prioritizing critical work, deferring non-urgent tasks) and avoiding it altogether (moving work to the compositor thread via CSS transforms, offloading computation to Web Workers, or eliminating unnecessary work entirely). The author emphasizes that slow code is rarely the root cause—rather, it is code that unnecessarily occupies the main thread.