Third-party resources

Third-party resources are scripts, styles, fonts, images, and frames served from a domain other than the site’s own — analytics, tag managers, ads, consent banners, video embeds, chat widgets, A/B-testing and personalization tools. They are the part of page-weight the site author uses but does not author, and the answer to the wiki’s open question: a large, near-universal share of typical bloat is third-party.

The data

Per web-almanac-third-parties-2024 (HTTP Archive 2024):

• 92% of pages load ≥1 third party; popular sites carry more (median 66 for the top 1,000 vs. 27 for the top million).
• Third-party requests are mostly scripts (30.5%) and images (26.0%).
• Google owns 5 of the top-10 third-party domains (googletagmanager.com, google-analytics.com, googleapis.com, google.com, youtube.com); Meta’s facebook.com is the only other in the top five.

Why they resist minimalism

Third parties pull in more third parties: median inclusion-chain depth 3.4, with 14% of chains deeper than 5. So much third-party weight is indirect — never directly chosen by the author. This is why first-party tactics like hand-authoring less (landing-page-14kb) or smaller bundles (bundle-size, squint) don’t touch it: third-party weight is a separate governance problem (consent, tag managers, vendor contracts) with “privacy, security, and performance implications.”

A performance-budget can cap the number of third parties, but enforcing it means organizational discipline, not just a build flag. See synthesis for how this splits the minimalism thesis into a first-party layer and a third-party layer.

When you can’t remove them: mitigate the cost

A budget caps the count; for the scripts you can’t drop, web.dev gives runtime levers to blunt the cost (web-dev-third-party-js). Third-party scripts hurt three ways: too many requests, main-thread blocking (“too much JavaScript can block DOM construction, which delays page rendering”), and outright render-blocking (“also true for async A/B testing scripts”). The mitigations:

• async / defer always — “unless the script is necessary for the critical rendering path.” async runs the moment it downloads; defer waits for parse to finish.
• preconnect / dns-prefetch — pay the DNS and connection cost for third-party hosts up front.
• Lazy-load embeds — hold footer ads and below-the-fold widgets until the user scrolls.
• Avoid document.write() — Chrome flags it; it “behaves inconsistently, and its failures are difficult to debug.”

This is why third-party weight reads through inp as much as page-weight: the bytes land on the main thread, so the cost is felt in responsiveness, not only transfer size.

Related

page-weight · web-almanac-third-parties-2024 · web-dev-third-party-js · performance-budget · bundle-size · inp · core-web-vitals · synthesis