When an audit of a major news site surfaces a 49MB page weight, the instinct is to think about transfer size: optimize images, tree-shake JavaScript, defer the video. That framing is not wrong, but it misses the more persistent problem. A heavily instrumented news page might contact 60 to 100 distinct third-party origins before it finishes loading, and each of those origins carries connection overhead that exists entirely independent of how many bytes eventually transfer.
The byte count is visible. The connection overhead tends to hide in waterfall charts unless you know where to look.
What Each New Origin Actually Costs
For a browser loading a resource from a domain it has not seen before in the current session, three things happen before a single byte of response body arrives:
-
DNS resolution. A lookup against the configured resolver, which typically means a recursive query chain: browser cache miss, OS cache miss, resolver cache miss, authoritative lookup. On a warm connection this resolves in 20-40ms. On a cold mobile connection in a congested area, 100-200ms is normal.
-
TCP handshake. A round trip to establish the connection: SYN from client, SYN-ACK from server, ACK from client. At 50ms of round-trip time, this is another 50ms before the TLS negotiation can even begin.
-
TLS negotiation. TLS 1.3 requires one round trip for the handshake. TLS 1.2, which many ad servers still speak, requires two. At 50ms RTT, that is 50-100ms of pure key exchange overhead.
Add those up for a single origin: 20-40ms DNS + 50ms TCP + 50-100ms TLS = 120-190ms before any content. For 80 distinct origins, that theoretical minimum is 9,600 to 15,200 milliseconds of connection overhead, not counting the actual resource transfers.
In practice, modern browsers parallelize aggressively and TCP connection pools allow reuse, so you do not pay full serial cost for every origin. But you do pay for every origin that fires before the connection pool is warm, and on a news page, that window is large because third-party scripts trigger their own dependencies.
HTTP/2 and HTTP/3 Solve a Different Problem
A common response to this analysis is that HTTP/2 multiplexing removes per-request overhead by sending multiple requests over a single connection. That is correct, but it only applies within a single origin. HTTP/2 does not reduce the cost of connecting to 80 different domains; it reduces the cost of making multiple requests to the same domain once the connection is established.
HTTP/3, running over QUIC, does help at the margins. QUIC combines the TCP handshake and TLS negotiation into a single round trip, and subsequent connections to the same origin can use 0-RTT resumption from the previous session’s ticket. Google’s adoption data suggests QUIC reduces connection latency by 15-20% in practice.
But the fundamental arithmetic does not change. If your page requires connections to 80 distinct origins, you are paying connection setup cost 80 times. HTTP Archive data shows that third-party requests consistently account for 40-50% of total requests on news and media pages, spread across dozens of origins that each need their own connection.
The Script Cascade Problem
The browser cannot prefetch connection costs it does not know about. Resource hints like dns-prefetch and preconnect exist precisely because browsers need to be told which origins to warm connections for:
<!-- Warm the connection before the script tag appears -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="dns-prefetch" href="https://tracker.thirdparty.com">preconnect performs DNS, TCP, and TLS upfront. dns-prefetch is the lighter option that only resolves the domain name. The problem for news sites is that many of their third-party origins are not known at document parse time. A tag management container like Google Tag Manager loads dozens of vendor scripts at runtime based on trigger logic that executes after page load. Those origins cannot be hinted in HTML because the page’s HTML was authored without knowledge of what the tag manager will fire.
Beyond tag managers, the cascade goes deeper. One ad tech script loads another. A header bidding library like Prebid.js dynamically adds bid adapters that connect to exchanges the publisher’s own engineering team may not have a complete list of. A session replay tool makes calls to its own CDN. A social sharing widget phones home. Every layer adds origins, and the connection costs compound.
Chrome DevTools’ Network tab, sorted by domain, makes this visible. Reload a major news homepage and watch the domain column. You will see a core cluster of first-party requests in the first second, then a sprawling fan of third-party domains lighting up as scripts execute and spawn their own requests. The waterfall often continues for 10-15 seconds after the page appears to have loaded.
WebPageTest provides a cleaner view with its Connection View, which groups requests by server IP and makes it easy to count distinct origins and see their timing relative to the main document load.
What Developers Embedded in These Systems Can Actually Push For
Individual developers working at large media companies do not set editorial policy or sign contracts with data brokers. But there is a range of technical work that moves the needle without requiring top-level business decisions.
Tag manager hygiene. Google Tag Manager containers at large publishers frequently contain tags added for campaigns that ended two years ago, analytics experiments that never shipped, and vendor pixels for partnerships that lapsed. A quarterly tag audit, removing anything that cannot be justified, has direct impact on origin count and JavaScript execution time. This requires political will more than technical complexity.
Partytown. Partytown is a runtime that moves third-party scripts off the main thread by proxying their execution into a Web Worker. Scripts that would normally block the main thread’s event loop run in parallel with it instead. The trade-off is that some scripts assume synchronous access to document and window and break under the proxy layer, so it requires per-script testing. But for analytics and tracking scripts that just need to fire and forget, it works well.
Lighthouse CI with a performance budget. Lighthouse CI can be integrated into deployment pipelines to fail builds that exceed defined thresholds on metrics like Total Blocking Time, Largest Contentful Paint, or total JavaScript bytes. The value is not in blocking individual deployments, which creates friction, but in making the performance trend visible over time. A chart that shows Total Blocking Time growing 20ms per sprint tends to prompt conversations that abstract discussions do not.
// lighthouserc.json
{
"ci": {
"assert": {
"assertions": {
"total-blocking-time": ["warn", { "maxNumericValue": 300 }],
"resource-summary:script:size": ["error", { "maxNumericValue": 500000 }],
"total-byte-weight": ["warn", { "maxNumericValue": 5000000 }]
}
}
}
}Self-hosting fonts and critical third-party resources. Fonts loaded from Google Fonts or Adobe Typekit require a separate origin connection. Self-hosting eliminates that origin entirely, which is one fewer DNS lookup, TCP handshake, and TLS negotiation. The same logic applies to any resource where the publisher controls the relationship: icon libraries, polyfills, and static SDKs are all candidates for consolidation onto first-party CDN.
Facade patterns for embeds. YouTube embeds, Twitter widgets, and similar third-party components load their full JavaScript runtimes on page load, connecting to multiple origins before the user has interacted with them. The facade pattern replaces these embeds with lightweight static previews, deferring the real embed load until the user clicks. A YouTube thumbnail with a play button is a few kilobytes; the actual YouTube player connects to half a dozen Google domains.
The Asymmetry of Cost
The reader pays the connection overhead on every page load, every visit, on whatever hardware they happen to own. Alex Russell’s analysis of the performance inequality gap remains relevant: a device that costs $200 and runs on a mobile connection is where a large fraction of the world reads news. On that hardware, 80 origin connections and 50ms of JavaScript execution per script are not engineering abstractions. They are seconds of waiting for a page that mostly serves someone else’s interests to become usable.
Core Web Vitals metrics like Interaction to Next Paint (INP), which replaced First Input Delay as a ranking signal in March 2024, are direct measurements of the main thread contention that third-party scripts create. A news site with 80 third-party origins loading JavaScript will typically fail INP not because any single script is slow, but because the aggregate execution blocks the main thread for the duration of the load.
The 49MB number from the audit is striking, and it should be. But the origin count is the structural problem. Transfer size can be improved by compression and optimization while the underlying architecture stays the same. Reducing origins requires renegotiating vendor relationships and exercising discipline over what gets added to tag management containers. That is harder work, which is probably why the connection cost rarely makes it into the headline figure.