Script origin (1P/3P)
First-party vs third-party scripts - counts and bytes.
At a glance the headline numbers for Script origin (1P/3P)
First-party vs third-party scripts - counts and bytes.
21.2% of scripts come from third parties.
The script origin (1P/3P) mix who uses what, and how fast each group loads
Script origin (1P/3P). On the fleet: 78.8% first party, 21.2% third party. 97.4% of sites use at least one first_party.
By count first party leads (78.8%); by bytes it is third party (56.1%). computed
Passing LCP 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 LCP.
First party swings the hardest: 85% of sites pass LCP with few, 61% with many. computed
Few vs many - does quantity cost LCP? 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 First party costs the most: the LCP pass rate falls from 85% with few to 61% with many. computed
Why this matters for the Core Web Vitals, and where to start fixing it
First-party script is in your bundle, your build, your deploy. Third-party script arrives from someone else's server at whatever size and shape it has today. Both run on the same main thread. Only one of them is yours to fix.
A high third-party share is a ceiling on your INP work: optimize your own code all you want, the tags still run between your visitor's clicks. Past that ceiling the fix list changes. Fewer vendors, deferred loading, facades instead of always-on embeds.
How does this affect the Core Web Vitals?
The choice barely moves the INP: 93% pass at best, 92% 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.