Third-party scripts are dragging down your page load
When a third-party script hurts performance, there are only two real fixes: remove it, or make it load more efficiently. This article covers the practical techniques for the second option, using the async and defer attributes, early connection hints, lazy loading, and smarter serving strategies.
Let the browser parse while scripts download
Synchronous scripts block DOM construction and rendering. Unless a script must run before the page can be painted, it should never load that way. The async and defer attributes let the browser continue parsing HTML while the script downloads in the background, so the user sees content sooner.
<script defer src="..."> <script async src="...">
The two attributes differ in when the downloaded script executes.
async for earlier execution
An async script executes at the first opportunity after it finishes downloading, before the window's load event. Because execution timing depends on download speed, async scripts can run out of order relative to their position in the HTML. They may also interrupt the parser mid-build if the download completes while parsing is still underway.
Use async when you need the script running as early as possible in the loading process.
defer for ordered, non-blocking execution
A defer script waits until HTML parsing is completely finished, then runs before the DOMContentLoaded event. Scripts with defer execute in the order they appear in the HTML and never block the parser.
Use defer for less critical resources, like a video player below the fold. The performance impact is measurable: Telegraph deferred all its scripts, including ads and analytics, and improved ad loading time by an average of four seconds.
Open connections to third-party origins ahead of time
Establishing early connections to important third-party origins can save 100–500 ms per request. Two <link> types handle this: preconnect and dns-prefetch.
<link rel="preconnect"> tells the browser to start the connection process immediately. When the browser later requests a resource from that origin, the download begins without waiting for the DNS lookup, TCP handshake, and TLS negotiation.
<link rel="preconnect" href="https://example.com">
<link rel="dns-prefetch"> handles just the DNS lookup portion of the connection. It's a lighter hint, best reserved for less important third-party domains. The more complete preconnect should be used only for the most critical connections.
<link rel="dns-prefetch" href="https://example.com">
Browser support for dns-prefetch differs slightly from preconnect. To cover both cases safely, use separate link tags — dns-prefetch acts as a fallback where preconnect isn't supported.
<link rel="preconnect" href="https://example.com">
<link rel="dns-prefetch" href="https://example.com">
Lazy-load what isn't immediately needed
Third-party embeds below the fold are prime candidates for lazy loading. Loading them after the main content is parsed gives users the page faster, and for ad-supported sites, a faster main content load can also raise viewability. MediaVine switched to lazy-loading ads and saw a 200% improvement in page load speed. Google Ad Manager's documentation describes how to lazy load ads through its publisher tag.
The Intersection Observer API detects when an element enters or leaves the browser viewport, making it the native way to trigger content at the right scroll position. The lazysizes library uses this approach for images and iframes, with support for YouTube embeds and widgets. For a simpler path, the loading attribute on images and iframes provides a browser-level alternative to JavaScript-based methods.
Choose the right way to serve the script
Third-party CDN: easy but costly
Vendors commonly provide hosted URLs on their own content delivery networks. The setup is fast and maintenance-free — the vendor handles server config and updates. The tradeoff is network overhead: each request from a third-party origin requires a DNS lookup, a new HTTP connection, and an SSL handshake on secure origins. You also inherit the vendor's caching policies, which may re-fetch scripts from the network more often than necessary.
Self-hosting: more control, more responsibility
Serving third-party scripts from your own origin cuts DNS lookups and round-trip times, and lets you set HTTP caching headers and use HTTP/2 or HTTP/3. Casper shaved 1.7 seconds off load times by self-hosting its A/B testing script. The catch is that you stop getting automatic updates — scripts can drift out of date and miss security fixes or API changes.
Service workers as a middle ground
Service workers can cache scripts from third-party servers without self-hosting. That gives you control over how often scripts are re-fetched and lets you throttle non-essential resources until the user reaches a key interaction. Combined with preconnect for early connection establishment, this approach mitigates much of the network cost of third-party CDNs.
