Stylesheet origin (1P/3P)
First-party vs third-party stylesheets - counts and bytes.
At a glance the headline numbers for Stylesheet origin (1P/3P)
First-party vs third-party stylesheets - counts and bytes.
7.8% of stylesheets load from servers their site does not control.
The stylesheet origin (1P/3P) mix who uses what, and how fast each group loads
Stylesheet origin (1P/3P). On the fleet: 92.2% first party, 7.8% third party. 97.9% of sites use at least one first_party.
First party leads by count (92.2%) and by bytes (92.2%). computed
Passing INP per bucket every category and count level at once - color is the pass rate
Each row is a category, each column its own count bucket (few on the left, many on the right); the cell is the share of those sites passing INP.
No category moves the INP pass rate much, however many a site ships. computed
Few vs many - does quantity cost INP? the pass rate with few vs many of each category
Per category: the pass rate among pages with FEW of it (hollow ring) against pages with MANY (solid dot), worst trend first. Thin buckets are excluded from the endpoints.
More Third party costs the most: the INP pass rate falls from 95% with few to 93% with many. computed
Why this matters for the Core Web Vitals, and where to start fixing it
A third-party stylesheet is render-blocking content on someone else's server. Your first paint waits on their TTFB and their availability. Font CSS is the classic case, widget styles the second.
CSS files are small and change rarely, so there is no good reason not to self-host them. This is the SPOF (single point of failure) case with the highest stakes: when that server is slow, it is not a feature that waits, it is rendering.
How does this affect the Core Web Vitals?
The choice barely moves the LCP: 83% pass at best, 81% at worst. This signal does not separate passing sites from failing ones.
Chrome field data from 94,910 sites, representing millions of real page loads. How we measured.