How much do third-party scripts slow down a website?

Each third-party script adds an average of 50 to 200 milliseconds of main-thread blocking, and the effect compounds because most sites run about ten of them at once. Chrome's research found the worst offenders block the main thread for up to 1.6 seconds on more than half of the sites analysed, and stacking five tracking pixels can add two to four seconds to every page load. Because all of that JavaScript competes on a single main thread, it delays both your content from rendering and every click from responding.

Do third-party scripts affect Core Web Vitals and SEO?

Yes, all three metrics. They hurt LCP by competing for bandwidth and CPU so your main content renders later, cause CLS when they inject banners or content that shifts the page, and — most importantly in 2026 — wreck INP by monopolising the main thread when a user interacts. INP is now a ranking signal and the most commonly failed Core Web Vital, with around 43% of sites below the 200-millisecond threshold, and third-party scripts are its single most common cause. Since Core Web Vitals feed Google rankings, this is an SEO issue as much as a speed one.

What's the difference between async and defer for scripts?

Both let a script download in parallel instead of blocking the HTML parser, but they differ in execution. A script with defer is fetched alongside parsing and runs only after the document is parsed, preserving the order of multiple deferred scripts — it's the sensible default for non-critical code. A script with async runs as soon as it finishes downloading, which can interrupt parsing and does not guarantee order. Any script tag without either attribute blocks HTML parsing entirely while it loads and runs.

What is Partytown and should I use it?

Partytown is a library that runs third-party scripts in a web worker — a separate background thread — instead of on the main thread, which frees the main thread to render your content and handle interactions. It's a strong option when you have third-party code you can't remove but that's hurting responsiveness, though the third-party script itself may run a little slower by design, since your own content is now prioritised. It's one tool on a ladder that also includes deferring, delaying until interaction, facades and self-hosting.

Should I remove Google Analytics to improve performance?

Usually not — Google Analytics 4 alone is relatively lightweight, around 30KB, and rarely causes a Core Web Vitals failure by itself. The performance problem is almost always the combined weight of many tags loaded through a tag manager: analytics plus several pixels, a chat widget, heatmaps and consent tools all competing at once. The productive move is to audit everything loading through your tag manager, remove tags nobody remembers adding, and delay the non-critical ones — not to single out analytics.

Third-party scripts and web performance: the tax you can choose not to pay

June 26, 2026 · 11 min read · Web Involved

How do third-party scripts affect web performance?

Every third-party script — an analytics tag, a chat widget, a marketing pixel, a video embed — is another domain your visitor’s browser must connect to, another payload to download, parse and execute, and another block of time on the single main thread that your own page and every user interaction have to share. About 94% of sites carry them, they average 50 to 200 milliseconds of main-thread blocking each, and collectively they are the number-one cause of poor INP — the most commonly failed Core Web Vital in 2026. The standard fix is a ladder of mitigations: audit what you actually load and delete anything that doesn’t earn its place; give the survivors defer so they stop blocking the parser; delay non-critical ones until the user interacts; wrap heavy chat widgets and video embeds in a lightweight facade; move stubborn scripts to a web worker with a tool like Partytown; self-host what you can; and preconnect to the domains you keep. All of that works — but notice the whole ladder is effort spent undoing damage you invited, which is why the cleanest fix is the one we start from: not adding the third party in the first place.

In short

All JavaScript shares one main thread. Every third-party script that runs makes your own code — and every user click — wait its turn, which is why ten small tags add up to a slow, unresponsive page.
They're the top INP killer. INP is now a ranking signal and the most-failed Core Web Vital (~43% of sites fail it), and third-party scripts are its single most common cause — each adds ~50-200ms of blocking.
The worst are chat widgets and embeds. A single chat widget can ship 500KB of JavaScript to draw a button; a YouTube embed can freeze the main thread for seconds. Facades and deferral tame them.
The whole mitigation ladder undoes self-inflicted damage. The cleanest version of 'defer it, facade it, self-host it' is 'don't add it' — which is why we build widget-free and embed-free by default.

Why one script becomes a performance problem

The root cause is a fact about browsers: nearly all JavaScript runs on a single main thread, so when a third-party script executes, your own code has to wait (PageSpeedFix, 2026). And a script is more than a download — it must be parsed, compiled and executed by the browser, work that delays rendering and pushes back the moment a user can interact (WebsiteSpeedy, 2026). By default that download and execution is synchronous, meaning a plain script tag blocks the HTML parser and DOM construction until it finishes (patterns.dev, 2026).

That single mechanism damages all three Core Web Vitals. Third-party code hurts LCP by competing for bandwidth and CPU so your hero image or heading arrives later, causes CLS when it injects an ad or banner that shifts the content below it, and drags down INP when it runs on the main thread as a user clicks (DebugBear, 2026). Because those vitals feed Google’s rankings, this stops being only a speed problem and becomes an SEO one (WP Rocket, 2026). Lighthouse makes the threshold concrete: it flags the third-party audit once that code blocks the main thread for more than 250 milliseconds in total (PageSpeedFix, 2026).

It’s never one script — it’s ten

The reason this matters so much in practice is that sites rarely stop at one. Over 94% of websites load third-party scripts, and most carry a crowd of them — analytics, tag manager, a social pixel, a heatmap tool, a chat widget, a consent banner — all fighting for the main thread at once (PageSpeedFix, 2026). Each one adds an average of 50 to 200 milliseconds of main-thread blocking, so the arithmetic turns ugly quickly (LeadsuiteNow, 2026).

The metric that suffers most is INP, and the numbers are stark: according to early-2026 field data, around 43% of websites still fail the 200-millisecond INP threshold, making it the most commonly failed Core Web Vital, and third-party scripts are its single most common cause (Pravin Kumar, 2026). There’s also a quieter, organisational reason the problem festers. As one analysis put it, the tags slowing a site down are often the part of the site not owned by any single person or team, so they fall between the cracks and nobody removes them (SearchX, 2026).

The worst offenders: chat widgets and embeds

Some third parties are far heavier than they look. A chat widget can download over 500KB of JavaScript — effectively a full React application — just to render a button with a speech-bubble icon (PageSpeedFix, 2026). Video embeds are similar: Chrome’s developer team found that YouTube embeds block the main thread for 4.5 seconds on 10% of mobile sites, and for at least 1.6 seconds on half of the sites studied (PageSpeedFix, 2026). Tracking pixels look tiny individually but stack fast — five of them can add two to four seconds to every page load (PageSpeedFix, 2026).

The good news is these have known fixes. For a chat widget or video embed, use a facade — a lightweight placeholder button that loads the real thing only when a user clicks it (Pravin Kumar, 2026). For a form-protection script like reCAPTCHA, load it only on the pages with forms and lazy-load it on form focus rather than on every page (patterns.dev, 2026). The pattern throughout is the same: don’t pay for the heavy thing until the moment it’s actually needed.

Step one: audit what you actually have

You cannot fix what you have not measured, so the first move is an inventory. PageSpeed Insights now shows a “3rd Parties” insight listing every external source with its transfer size and main-thread time — informational rather than pass/fail, but ideal for finding the biggest offenders (WP Rocket, 2026). Chrome DevTools’ Performance panel shows exactly when each script executes and how long it blocks, and WebPageTest reveals the request chain — which scripts load other scripts, exposing hidden costs (PageSpeedFix, 2026).

Then write it down. Document each script in a spreadsheet with its name, domain, file size, main-thread blocking time, the team responsible, and its business purpose, and group them into categories like analytics, advertising, social and support so you can decide what to keep, adjust or cut (SearchX, 2026). This is where the single most impactful optimisation shows up, because eliminating a third party entirely beats any amount of tuning — remove anything that does not directly contribute to user experience or revenue (DebugBear, 2026).

Then defer, delay and facade

For the scripts that survive the cut, control how they load. Add defer to non-critical scripts so they download in parallel and execute only after the document is parsed, keeping their order; defer should be the default choice, with async for independent scripts that needn’t run in sequence (patterns.dev, 2026). Better still, delay the non-essential ones until after the page is interactive — in a tag manager, switch triggers from “All Pages” to a window-loaded or interaction trigger so pixels and remarketing tags fire late (PageSpeedFix, 2026).

The common objection — that deferring scripts will distort analytics or ad revenue — has been tested and largely debunked. In a widely cited case, deferring all scripts did not skew any analytics or advertising metrics; instead the “first ad loaded” time improved by an average of four seconds (patterns.dev, 2026). You usually lose nothing measurable and gain a visibly faster page.

Web workers, self-hosting and preconnect

When a script can’t be removed or fully deferred, three more tools help. A web worker moves the script off the main thread into a background thread — this is what Partytown does, running third-party scripts in a worker so the main thread stays free to render and respond, at the cost of the third-party script itself running a little slower by design (DebugBear, 2026). Self-hosting a script that’s dragging performance gives you control over how it loads and lets you cache it, so you can defer or lazy-load it while keeping the functionality (SearchX, 2026) — the same reasoning behind our guide on self-hosting web fonts.

For the domains you do keep, establish the connection early. A preconnect resource hint completes the DNS lookup, TCP handshake and TLS negotiation ahead of time, which can shave up to 800 milliseconds off loading a third-party resource; dns-prefetch does the lighter DNS-only version and suits important-but-non-critical origins (WP Rocket, 2026). These are small wins next to deletion, but for a script you’ve decided is worth keeping, they’re worth applying.

The honest caveat: sometimes it’s you, not them

Before blaming a vendor, check your own integration, because the fault is often in how a third party was set up rather than the third party itself — running two hundred A/B tests and marketing experiments at once will be slow no matter whose logo is on the tool (DebugBear, 2026). Analytics draws more blame than it deserves for the same reason: Google Analytics 4 alone is lightweight and rarely the cause of a failing score, and much of the confusion comes from misreading PageSpeed’s lab data as if it were real-user field data (NitroPack, 2026). Diagnose before you cut, so you remove the tag that’s actually costing you rather than the one that’s easiest to name.

The cleanest fix is the one we start from

Read back over that ladder — audit, delete, defer, delay, facade, web-worker, self-host, preconnect — and a pattern emerges: almost every rung is work spent undoing damage you chose to invite. That framing is why our default is different. We build sites that are widget-free, embed-free and analytics-light from the start, so there is no main-thread tax to claw back later and no drawer of forgotten tags that “falls between the cracks” because nobody owns it. Zero third-party requests is not an aesthetic preference; it is the arithmetic in this guide run in reverse — every block of main-thread time in the takeaways above is time we simply never spend.

None of this means a third party is never worth it. When one genuinely earns its place, the same toolkit applies — defer it, facade it, self-host it, preconnect to it — and you pay the cost deliberately, with eyes open. But the honest default for a fast, responsive, private site is fewer of them, which also removes a whole class of privacy and consent obligations that arrive the moment someone else’s script runs on your page. This is the same single decision behind our pillar on Core Web Vitals and site speed and our guide on JavaScript and web performance: the fastest and safest script is the one you never send.

Frequently asked

How much do third-party scripts slow down a website?: Each third-party script adds an average of 50 to 200 milliseconds of main-thread blocking, and the effect compounds because most sites run about ten of them at once. Chrome's research found the worst offenders block the main thread for up to 1.6 seconds on more than half of the sites analysed, and stacking five tracking pixels can add two to four seconds to every page load. Because all of that JavaScript competes on a single main thread, it delays both your content from rendering and every click from responding.
Do third-party scripts affect Core Web Vitals and SEO?: Yes, all three metrics. They hurt LCP by competing for bandwidth and CPU so your main content renders later, cause CLS when they inject banners or content that shifts the page, and — most importantly in 2026 — wreck INP by monopolising the main thread when a user interacts. INP is now a ranking signal and the most commonly failed Core Web Vital, with around 43% of sites below the 200-millisecond threshold, and third-party scripts are its single most common cause. Since Core Web Vitals feed Google rankings, this is an SEO issue as much as a speed one.
What's the difference between async and defer for scripts?: Both let a script download in parallel instead of blocking the HTML parser, but they differ in execution. A script with defer is fetched alongside parsing and runs only after the document is parsed, preserving the order of multiple deferred scripts — it's the sensible default for non-critical code. A script with async runs as soon as it finishes downloading, which can interrupt parsing and does not guarantee order. Any script tag without either attribute blocks HTML parsing entirely while it loads and runs.
What is Partytown and should I use it?: Partytown is a library that runs third-party scripts in a web worker — a separate background thread — instead of on the main thread, which frees the main thread to render your content and handle interactions. It's a strong option when you have third-party code you can't remove but that's hurting responsiveness, though the third-party script itself may run a little slower by design, since your own content is now prioritised. It's one tool on a ladder that also includes deferring, delaying until interaction, facades and self-hosting.
Should I remove Google Analytics to improve performance?: Usually not — Google Analytics 4 alone is relatively lightweight, around 30KB, and rarely causes a Core Web Vitals failure by itself. The performance problem is almost always the combined weight of many tags loaded through a tag manager: analytics plus several pixels, a chat widget, heatmaps and consent tools all competing at once. The productive move is to audit everything loading through your tag manager, remove tags nobody remembers adding, and delay the non-critical ones — not to single out analytics.