Performance

Main thread

Main thread is the one thread that parses HTML, runs most JavaScript, calculates styles and layout, and paints. Anything slow there delays everything the visitor sees or taps.

How it is measured

In the Performance panel, the Main track shows tasks over time. Look at the share of time spent in scripting, rendering, and painting, and for tasks over 50 ms.

The thread handles input events between tasks. A long task means the next click waits. Offloading to Web Workers, using `requestIdleCallback`, or yielding keeps it free.

Worked example

A WordPress site with five plugins has 1,400 ms of scripting on a mid-range phone. The trace shows a 380 ms task from a slider and a 300 ms task from an analytics bundle. Total Blocking Time is 880 ms. Removing the slider and loading analytics after idle brings TBT to 210 ms.

The paint is still delayed by a 90 ms layout from a large DOM of 4,200 nodes.

How it differs

The main thread is where work runs. A long task is a slow piece of that work. Render-blocking resources delay the first paint on that thread. Workers run elsewhere, but they cannot touch the DOM.

Common errors

Assuming desktop speed applies to phones. Adding libraries without a trace. Running animations in JavaScript instead of CSS. Having a large DOM. Doing heavy work on scroll handlers.

In practice

Profile your key page on a throttled CPU, list the biggest main-thread tasks, and remove or defer the top three. Retest TBT and INP.

See also

Long task, Render-blocking resource

Sources

Count this on a real site.

Watch my website