Twelve is the median, and the tail is long
Half the sites we audited reach for twelve hosts or fewer. That number alone is unremarkable until you look at where the distribution goes: the 75th percentile is 20 hosts, the 90th is 33, and the heaviest site in the sample opens connections to 120 separate hosts to render one page.
| Hosts | Registrable domains | |
|---|---|---|
| 10th percentile | 3 | 2 |
| 25th percentile | 7 | 4 |
| Median | 12 | 8 |
| 75th percentile | 20 | 13 |
| 90th percentile | 33 | 22 |
| Maximum | 120 | 73 |
The second column is the conservative version of the same count, with every host collapsed to
the domain someone registered: fonts.googleapis.com and fonts.gstatic.com become one
entry, not two. It halves the headline but changes nothing about the shape. Fifteen sites in
the whole sample load from no outside host at all.
Each of those entries is a connection the browser has to set up before the first byte of whatever it wants arrives, and connection setup is not free: web.dev puts it at up to three round trips on a secure connection. On a phone on mobile data, three round trips is not a rounding error.
The count sorts the sample by score
We put every site into a band by host count and took the median mobile PageSpeed score of each band. We expected a slope. We did not expect it to be this clean:
| Hosts the site doesn’t own | Sites | Median mobile score |
|---|---|---|
| 0–4 | 74 | 81 |
| 5–9 | 97 | 65 |
| 10–19 | 165 | 56 |
| 20–29 | 59 | 49 |
| 30 or more | 57 | 37 |
Forty-four points from one end to the other, monotonic, with no band breaking the pattern. Repeating it on the registrable-domain cut gives the same shape at a lower resolution: 72 for sites under five domains, 38 for sites over twenty.
Six of the ten most common domains are one company’s
Counting how many sites load each domain produces a list that is less varied than the distribution above would suggest:
| Domain | Sites | Share |
|---|---|---|
| googletagmanager.com | 286 | 63% |
| googleapis.com | 179 | 39% |
| google.com | 178 | 39% |
| gstatic.com | 172 | 38% |
| google-analytics.com | 163 | 36% |
| doubleclick.net | 162 | 35% |
| cloudfront.net | 98 | 21% |
| facebook.net | 84 | 18% |
| facebook.com | 81 | 18% |
| cloudflare.com | 64 | 14% |
Tag Manager on nearly two thirds of the sample is the single most consistent fact in this study. It is also the entry that misrepresents itself most: one host in the list, one script in the markup, and an unknown number of further hosts loaded by whatever the marketing team has configured inside it. Our count sees the container. It does not see the decision.
The Google fonts pair (googleapis.com for the stylesheet, gstatic.com for the files)
appears on roughly four sites in ten, and it is the cheapest entry on this list to fix: the
files can be served from the site’s own origin, which removes two connection setups from the
critical path without removing anything a visitor would notice.
Platforms differ, and not the way the marketing does
| Platform | Sites | Median hosts |
|---|---|---|
| Webflow | 30 | 20 |
| Duda | 49 | 15 |
| Tilda | 39 | 14 |
| WooCommerce | 55 | 14 |
| WordPress | 60 | 13 |
| Squarespace | 37 | 12 |
| Wix | 30 | 11 |
| Next.js | 23 | 9 |
| Bitrix | 24 | 8 |
| Elementor | 30 | 5 |
Read this one carefully, because it is the table most likely to be misused. The platform does not choose the marketing stack; the owner does. What the platform contributes is a floor — the vendor’s own runtime, fonts and asset domains — and the visible spread across these ten is mostly what got installed on top. Elementor’s median of 5 is not evidence that Elementor is disciplined. It is evidence that the 30 Elementor sites in our sample are smaller businesses running less marketing.
What the number is good for
It is a triage signal, not a diagnosis. If you want one measurement that tells you whether a slow page is slow because of what the site is or because of what was added to it, this is the cheapest one available: open the network panel, sort by domain, count the distinct ones.
Under five, the page is mostly yours and the fixes are structural — render-blocking CSS, unprioritised images, layout that paints below the fold. Past twenty, the largest single lever is a conversation with whoever added the twentieth, and no amount of asset optimization substitutes for it. That conversation is also the one part of this that a proxy in front of the site cannot have for you: we can defer third-party scripts until the page is usable and we do, but a request the owner wants made will still be made.
The floors matter here too. Every count above stops at 300 requests and never interacts with the page, so the real numbers are higher than these — most of all on the sites that already look worst.
Method and limits
457 audited sites, each measured once in Lighthouse's mobile configuration. We take the network log of that run — the original site, before any of our own optimizations — and reduce every request to the host that served it. Counting distinct hosts other than the one that served the document gives the headline figure; collapsing those hosts to their registrable domain (so cdn.example-vendor.com and js.example-vendor.com count once) gives the second, more conservative one. Scores are the PageSpeed performance score from the same run, so host count and score describe one page load rather than two separate visits.
Measured on 4 Aug 2026 across 457 sites. These figures are frozen at that date — we don't quietly restate a published study when the audit base grows.
What this doesn't show
- These are not a random sample of the web. They are 457 sites we chose to audit — competitors, publishers, and platform batches assembled to study particular site builders — and the mix skews toward sites someone suspected were slow. Read every figure as "of these 457 sites".
- "A host the site doesn't own" is a structural test, not an editorial one. A site serving its own images from its own CDN subdomain on a vendor domain is counted as reaching outside, because the browser has to open a connection either way. That is why we report the registrable-domain cut alongside it, and why we do not present the byte share as a third-party content figure: on hosted builders nearly the whole page is served from the vendor's own CDN domain, which pushes that share toward 100% without a single tracker being involved.
- Our resource log stops at 300 requests per page. 24 of the 457 sites hit that ceiling, so their host counts are floors rather than counts. Every figure here is therefore an understatement at the heavy end, including the maximum of 120.
- Lighthouse loads the page and waits. It does not click, scroll to the bottom, accept a consent banner or open a chat widget, so hosts that only appear after an interaction are missing from every count. This is a second reason the numbers are floors.
- The score gradient is an association, not a mechanism. A site that reaches for 30 hosts usually has more of everything — more scripts, more images, more markup — and any of those could be doing the damage. What the gradient rules out is the comfortable reading that a long connection list is cosmetic.
Sources
- Establish network connections early to improve perceived page speed — web.dev, Google
The connection setup process might involve up to three round trips—and more in unoptimized cases.
- Reduce the impact of third-party code — Chrome for Developers, Google
Lighthouse flags pages that have third-party code that blocks the main thread for 250 ms or longer