Image source mix
Where images come from: same origin, third party, or inline data URIs.
At a glance the headline numbers for Image source mix
Where images come from: same origin, third party, or inline data URIs.
31.1% of images come from third-party domains.
The image source mix mix who uses what, and how stable each group is
Image source mix. On the fleet: 60.4% self, 31.1% third party, 8.5% inline. 84.1% of sites use at least one self.
Self leads by count (60.4%) and by bytes (80.3%). computed
Passing CLS 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 CLS.
Inline swings the hardest: 88% of sites pass CLS with few, 81% with many. computed
Few vs many - does quantity cost CLS? 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 Inline costs the most: the CLS pass rate falls from 88% with few to 81% with many. computed
Why this matters for the Core Web Vitals, and where to start fixing it
Third-party images pay the connection tax: DNS, TCP and TLS before the first byte, on a domain your page has not warmed up. Data URIs are the opposite trap. The image bytes hide inside the HTML or CSS, bloat the document everything else waits for, and cannot be cached on their own.
Keep important images on a domain the browser has already connected to. Inline only icons too small to be worth a request. For everything else, a real URL on a warm connection wins.
How does this affect the Core Web Vitals?
The choice barely moves the LCP: 82% pass at best, 79% 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.