Loading third-party JavaScript efficiently (web.dev)

Google web.dev’s guide to taming third-party-resources — specifically the script slice, which is the dominant third-party request type. Where the Almanac chapter measures how much third-party weight there is, this page gives the levers to blunt its cost.

How third-party scripts hurt

• Too many network requests to multiple servers — “the more requests a site has to make, the longer it can take to load.”
• Main-thread blocking — “too much JavaScript can block DOM construction, which delays page rendering.”
• Render-blocking — they can block content display until they finish, “also true for async A/B testing scripts.”

The levers

• async / defer — “always use async or defer for third-party scripts, unless the script is necessary for the critical rendering path.” async runs as soon as it downloads (blocking parse while it executes); defer waits until parsing is complete.
• Resource hints — <link rel=preconnect> or <link rel=dns-prefetch> to pay the DNS / connection cost early for third-party hosts.
• Lazy-load embeds — defer footer ads, below-the-fold widgets until the user scrolls to them.
• Avoid document.write() — Chrome flags “problematic use of document.write()”; it “behaves inconsistently, and its failures are difficult to debug.”

Why this matters here

third-party-resources are the part of page-weight the author uses but doesn’t author, and a performance-budget can cap their count but not their behavior. This guide supplies the runtime mitigations — async/defer, preconnect, lazy-load, no document.write — that reduce the inp / main-thread cost of scripts a team can’t simply remove. It’s the tactical layer under the synthesis’s “third parties are a separate governance problem” point.