How to minimize third-party impact. 

What is third-party impact, and why does it matter?

Third-party impact is the performance and security cost that external scripts, analytics, ads, social widgets, chat tools, and fonts, add to your website. Each one is code loaded from someone else’s server, so it adds network requests, main-thread work, and a dependency you don’t control. These services add real value, but left unmanaged they’re one of the biggest drags on site speed, and the fix is to load only what you need, as efficiently as possible.

Key Takeaways

• 92% of pages load at least one third party, and the median page makes 79 third-party requests on mobile (HTTP Archive Web Almanac, 2025).
• Third-party scripts are a leading cause of poor responsiveness: pages with heavy user-tracking scripts keep good INP only 37% of the time on mobile (Web Almanac, 2024).
• You manage them by auditing, prioritising, deferring, self-hosting where sensible, and setting a performance budget.
• Security tools (CSP and SRI) limit the damage a compromised third party can do.

Almost every site depends on third parties, and most depend on dozens. The problem isn’t using them, it’s using more than you need and loading them in ways that block your own content. This guide shows how to find your third-party scripts and reduce their impact on speed and security, building on our wider guide to improving Core Web Vitals.

How do you identify third-party scripts on your site?

You identify third-party scripts using your browser’s developer tools and free auditing tools, which list every external resource your page loads. You can’t reduce what you can’t see, so this is always the first step.

Three practical methods:

• Browser DevTools. Open Chrome DevTools (Cmd+Option+I on Mac, Ctrl+Shift+I on Windows), go to the Network tab, and reload. Sort by domain and anything not on your own domain is a third party. The Performance panel shows which of them occupy the main thread.
• Lighthouse and PageSpeed Insights. Both run a “Reduce the impact of third-party code” audit that lists each third party with its transfer size and main-thread blocking time, so you can see which ones cost the most.
• Your CMS plugins. On WordPress and similar, many plugins inject third-party scripts site-wide. Review each plugin’s settings, because plugins are where unexpected third parties usually creep in.

This matters because third parties compound: the median inclusion-chain depth is 3, meaning the scripts you add often pull in further scripts of their own (HTTP Archive Web Almanac, 2025). One tag can quietly become several.

How do you prioritise and remove non-essential services?

You prioritise third-party services by ranking each one against its performance cost, then removing or replacing the ones that aren’t worth what they slow down. Not every service earns its place, and the audit usually surfaces a few you can drop outright.

Work through a simple process. List every third party you found. For each, ask what it genuinely does for the business: is it core (payments, essential analytics) or merely nice-to-have (a second analytics tool, a rarely used widget)? Then check its cost in Lighthouse, which shows the main-thread time each one adds. Where a heavy service isn’t essential, remove it; where a lighter alternative exists (a privacy-friendly analytics tool in place of a heavy one), switch. Anything that survives but isn’t needed immediately should be deferred or lazy-loaded rather than loaded up front.

The payoff is concentrated in responsiveness. Tracking and consent scripts are among the worst offenders for Interaction to Next Paint: only 37% of mobile pages with user-behaviour scripts keep good INP, and consent-management scripts drop good-INP rates to 53% on mobile (Web Almanac, 2024). Cutting or deferring these often improves the metric Google now grades most directly.

How do you audit your tag manager?

A tag manager (like Google Tag Manager) is often where third-party scripts quietly accumulate, because marketing and analytics tags get added through it over months and the old ones never get removed. Auditing it is one of the highest-leverage clean-ups available, since a single container can be loading a dozen scripts you’ve forgotten about.

Work through the container methodically. List every tag, then for each ask whether it’s still used, who owns it, and whether it still fires on the right pages, paused campaigns, expired pixels, and abandoned A/B tests are common dead weight. Remove anything that no longer earns its place, and consolidate duplicates (two analytics tools doing the same job, say). Check firing triggers too: a tag set to fire on “all pages” that’s only needed at checkout is loading everywhere for no reason, so scope each trigger tightly. Finally, treat the tag manager itself as a third party with a budget, every new tag request should justify its cost before it goes in, because the container is only as fast as the sum of what it loads. A quarterly tag audit stops the slow accumulation that turns a fast site sluggish.

How do you load third-party scripts efficiently?

You load third-party scripts efficiently by using async and defer so they don’t block the page from rendering, and by lazy-loading anything that isn’t needed at first paint. The default <script> tag is render-blocking; these attributes change that.

The two attributes behave differently (MDN). With async, the script downloads in parallel and runs as soon as it’s ready, in no guaranteed order, which suits independent scripts like analytics. With defer, the script downloads in parallel but runs only after the HTML is parsed, in document order, which suits scripts that depend on page elements being present.

<script src="https://example.com/analytics.js" async></script>
<script src="https://example.com/widget.js" defer></script>

Beyond those attributes, lazy-load non-critical embeds (a social feed or map) so they load only when the user scrolls to them, and combine or remove duplicate tags to cut request count. This matters because blocking work is already high: median mobile Total Blocking Time is around 1,209 ms, roughly six times the recommended threshold (Web Almanac, 2024), and third-party scripts are a major contributor. Deferring them is one of the most direct ways to bring it down. For the related problem of your own blocking files, see our guide to eliminating render-blocking resources.

Should you self-host third-party scripts or use a CDN?

You should self-host third-party scripts when you safely can, and use a CDN to serve your own and static assets quickly, because both reduce the cost of fetching from many external servers. Each extra domain your page contacts adds a DNS lookup and a new connection, so consolidating where you can speeds things up.

Self-hosting means downloading a stable third-party file and serving it from your own server. The benefits are faster, more predictable delivery, full control over the version, and resilience if the third party’s server goes down. The caveat is maintenance: you become responsible for updates, so self-host scripts that change rarely, not ones the vendor updates constantly (like a live tag manager). A CDN, by contrast, serves your files from a server geographically near each visitor, which cuts latency and absorbs traffic spikes, and most CDNs add security features like DDoS protection. Reducing the number of distinct domains your page calls, and prefetching DNS for the ones that remain with <link rel="dns-prefetch">, trims the connection overhead further.

How do you protect security with CSP and SRI?

You protect against malicious or compromised third parties with a Content Security Policy (CSP) and Subresource Integrity (SRI), two browser mechanisms that limit what external code can do. Every third-party script is code you didn’t write running on your page, so these controls matter as much as speed.

A Content Security Policy tells the browser which sources are allowed to load resources, which helps prevent cross-site scripting and limits the blast radius if a third party turns malicious (MDN). You set it as an HTTP header listing trusted sources:

Content-Security-Policy: script-src 'self' https://trusted-cdn.com;

Subresource Integrity verifies that a file fetched from a third party hasn’t been altered, by checking it against a cryptographic hash (sha256, sha384, or sha512) you specify; if the file changes, the browser refuses to run it (MDN). You add the hash with the integrity attribute, plus crossorigin for cross-origin files:

<script src="https://trusted-cdn.com/lib.js" integrity="sha384-abc123" crossorigin="anonymous"></script>

Together they mean that even if a third party is compromised, it can’t easily inject new code or silently swap a file you trusted.

How do you monitor third-party performance over time?

You monitor third-party impact by testing regularly with performance tools and setting a performance budget so new scripts can’t quietly degrade your site. Third parties accumulate over time, so a one-off cleanup isn’t enough; you need a habit.

Use Lighthouse, PageSpeed Insights, or GTmetrix to track your Core Web Vitals and the third-party breakdown after any significant change. Watch the three current thresholds: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, all measured at the 75th percentile of real users (web.dev). Note that INP replaced the older First Input Delay metric as a Core Web Vital on 12 March 2024 (web.dev), so if your tooling still references FID, it’s out of date. Then set a performance budget, a cap on third-party size and count, and treat any new tag as a request that has to fit within it. That single discipline stops the slow creep that turns a fast site into a slow one.

What is a performance budget, and how do you set one?

A performance budget is a set of limits you agree for your pages, on size, requests, or timing, that any change has to stay within, so performance can’t quietly degrade as you add features and scripts (web.dev). It turns “keep the site fast” from a vague aim into a concrete rule you can check against.

Budgets come in three flavours, and most teams use a mix. Quantity-based budgets cap things you can count: total page weight (for example, “under 1.5MB”), the number of requests, or the size of third-party JavaScript specifically. Milestone-based budgets cap timings, such as “LCP under 2.5 seconds” or a minimum Lighthouse score. Rule-based budgets are pass/fail checks (no render-blocking resources, images served as WebP or AVIF). To set one, measure your current numbers as a baseline, agree a realistic limit slightly tighter than today (or matched to your Core Web Vitals targets), and write it down where the team can see it. Then enforce it: many teams wire a budget check into their build or use Lighthouse CI, so a change that blows the budget fails automatically. For third parties specifically, a budget is the discipline that stops the next “just one more tag” from being the one that tips your INP into the red.

Final thoughts

Third-party scripts are unavoidable and genuinely useful, but they’re also one of the heaviest, least-noticed costs on the modern web: the median page loads dozens of them, and the worst offenders quietly wreck responsiveness. The goal isn’t to remove them all, it’s to keep only what earns its place and load it without blocking your own content.

Audit what you have, drop the non-essential, defer and lazy-load the rest, self-host stable files, and protect yourself with CSP and SRI. Then set a performance budget so the problem doesn’t return. Do that and your third parties add value without dragging your site down. For the full performance picture, pair this with our guides to improving Core Web Vitals and reducing unused JavaScript.