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 INP 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 INP.
Scripting falls hardest: from its fastest to its slowest bucket the INP pass rate drops -1 points, down to 91%. 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 INP. 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 INP. Of the 4 parts, loading time separates passing sites from failing sites the most. Where the loading time is low, 90% of sites pass the INP. Where it is high, 95% do. The rise is gradual.
Chrome field data from 94,910 sites, representing millions of real page loads. How we measured.