The State of Web Vitals

Third-party domains

How many distinct third-party domains the page contacts.

Field data PhoneDesktopAll Scope All sites Q2 2026 edition · Phone field outcomes
Metric LCP INP CLS
1

At a glance the headline numbers for Third-party domains

How many distinct third-party domains the page contacts.

7
on the typical site
half of sites sit at or below
11
1 in 4 sites exceed this
the top quarter
35
the heaviest 1%
the long tail
185,486
sites measured
phone field data

The typical site contacts 7 third-party domains. The heaviest 1% contact 35 or more.

The State of Web Vitals · Q2 2026 · 189,915 sites · phone field datacorewebvitals.io/state-of-cwv
2

Distribution & median INP site count and median INP at each level of third-party domains

0ms 63ms 125ms 188ms 250ms
200ms
0 10744 21487
2–2 3–3 4–4 5–5 6–6 7–7 8–8 9–9 10–10 11–11 12–12 13–13 14–14 15–15 16+
Good (≤200ms) Needs improvement Poor (>500ms) Site count
The State of Web Vitals · Q2 2026 · 189,915 sites · phone field datacorewebvitals.io/state-of-cwv
3

Passing INP by third-party domains which level passes the INP most often

Third-party domainsSitesPassing INPINP
2–2 14,735 85% 91ms
3–3 14,643 94% 93ms
4–4 14,511 93% 94ms
5–5 13,612 95% 93ms
6–6 13,499 94% 95ms
7–7 13,033 93% 95ms
8–8 11,899 94% 96ms
9–9 11,134 93% 96ms
10–10 9,381 93% 98ms
11–11 8,090 93% 99ms
12–12 6,705 93% 102ms
13–13 5,603 93% 104ms
14–14 4,574 92% 104ms
15–15 3,730 92% 109ms
16+ 21,487 88% 123ms
Good Needs Improvement Poor Faded rows: under 100 sites

Third-party domains 7. p75 11. p99 35. At the low end (2–2): INP 91ms. At the high end (16+): INP 123ms. computed

The State of Web Vitals · Q2 2026 · 189,915 sites · phone field datacorewebvitals.io/state-of-cwv
4

Why this matters for the Core Web Vitals, and where to start fixing it

Third-party domains are a common Core Web Vitals issue. First of all, each third-party domain needs a new connection. That means time is lost on a DNS lookup, a TCP handshake and a TLS negotiation. If you had served those resources from your main domain, the browser could have re-used the connection that is already open (that is why you want HTTP/3: one fast, re-usable connection for everything you control). When that domain serves a font or a stylesheet, the browser cannot render before the connection is ready. The connection setup delays the LCP.

Also, third-party resources are usually out of your control. They can become a SPOF (single point of failure) when their server is slow or down. They can also change in size or behaviour without your knowledge, and your Core Web Vitals change with them. Self-hosting fixes both problems at once. Preconnect only hides part of the connection cost.

Go fix it Self-host Google Fonts → The case for limiting analytics and tracking scripts → Guide to resource prioritization →
Related signals Responsive image markup → Stylesheet loading mix → Image format mix → Images per page → Chrome field data from 189,915 sites, representing millions of real page loads · How we measured