Main-thread CPU (lab)
DevTools-style main-thread CPU split on the lab crawl: loading, scripting, rendering, painting.
At a glance the headline numbers for Main-thread CPU (lab)
DevTools-style main-thread CPU split on the lab crawl: loading, scripting, rendering, painting.
On the typical lab load, 434ms of main-thread time goes to JavaScript.
Where the milliseconds go the phases at the median, against the budget
At the median the whole stack uses 651ms. The biggest piece is Scripting at 434ms, 67% of the total. computed
Passing CLS per phase the share of sites passing, by how long each phase takes
Each line is one phase: left = sites where it is quick, right = sites where it drags (buckets, short to long). The steeper the fall, the more that phase decides CLS.
Loading falls hardest: from its fastest to its slowest bucket the CLS pass rate drops -2 points, down to 83%. computed
The 4 distributions how each phase spreads across sites - color is the share passing in that range
Loading stays green across its whole range: it never decides CLS. Loading turns red in its tail - the failing sites live there. computed
Why this matters for the Core Web Vitals, and where to start fixing it
The main thread's time on the lab load, split four ways. Loading is parsing bytes. Scripting is JavaScript. Rendering is style and layout. Painting is pixels. The shape tells you what kind of page it is: a script-dominated profile points at INP risk, a rendering-heavy profile points at DOM and style cost.
On most modern pages scripting is the biggest slice by far. That is the same thread the visitor's first click has to share.
How does this affect the Core Web Vitals?
Main-thread CPU (lab) correlates with the CLS. Of the 4 parts, painting time separates passing sites from failing sites the most. Where the painting time is low, 79% of sites pass the CLS. Where it is high, 87% do. The rise is gradual.
Chrome field data from 189,915 sites, representing millions of real page loads. How we measured.