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, 460ms 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 692ms. The biggest piece is Scripting at 460ms. computed
Passing LCP 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 LCP.
Rendering falls hardest: from its fastest to its slowest bucket the LCP pass rate drops 13 points, down to 62%. 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 LCP. Rendering 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 LCP. Of the 4 parts, rendering time separates passing sites from failing sites the most. Where the rendering time is low, 75% of sites pass the LCP. Where it is high, 62% do. The decline is gradual. There is no point where sites suddenly start failing.
Chrome field data from 94,910 sites, representing millions of real page loads. How we measured.