Third-party scripts and site speed: how to audit them

The short answer

A third-party script is code on your page that is loaded from another company's server, such as analytics, chat, advertising, video or font services. To audit them, list every script, measure what each one adds to page load, check who uses it, and remove or delay the ones that are unused, duplicated or not worth their cost.

What counts as a third-party script

Your own code comes from your own domain. A third-party script is any code your page loads from somewhere else. The visitor's browser fetches it from the other company's server and runs it inside your page, with much the same access as your own scripts.

Typical examples on a business site:

• Analytics and tag management.
• Advertising and conversion tracking pixels.
• Live chat and chatbot widgets.
• Embedded video, maps and social feeds.
• Web fonts loaded from an outside service.
• Review widgets, booking tools and cookie banners.
• A/B testing and heatmap tools.
• Payment and form services.

Each one has a reason to be there. The problem is that they pile up. A tool is added for a campaign, the campaign ends and the script stays. Over a few years a page may be loading a dozen services that nobody can explain. That pile-up is often called tag bloat.

Why third-party scripts slow a page

Every outside script costs something, and the cost sits outside your control.

• The browser must contact another server, which takes time before any code arrives.
• The script has to be downloaded, read and run, which uses the visitor's processor. On an older phone that effort is noticeable.
• Some scripts block the page while they load, so the visitor waits.
• Scripts often load more scripts, which then load more again.
• If the other company's server is slow or down, your page waits for it or breaks.
• Scripts can shift the layout as they appear, making content jump.

These costs show up in the measures that describe how a page feels to use. Our guide to handling traffic spikes explains how the same weight becomes a bigger problem when many visitors arrive at once.

Scripts also carry privacy and security weight. They can set cookies, collect data and, if the provider is compromised, run harmful code on your site. Our website security checklist for small businesses lists the other checks that sit alongside this one.

Step 1: list every script

You cannot judge what you cannot see. Build a simple table with one row per script.

1. Open the page in a browser and view the network panel in the developer tools. Reload the page. Filter by script and sort by domain. Every domain that is not yours is a third party.
2. Open your tag manager, if you use one, and list every tag, trigger and the person who added it.
3. Check your content system for plugins and theme options that add outside code.
4. Check the page source for scripts pasted directly into templates.
5. Repeat on different page types: home page, a blog post, a product or service page, the contact page and the checkout. Different pages often load different scripts.

For each script record the name of the service, what it is for, which pages it loads on, who asked for it and whether anyone still uses what it provides. Gaps in this table are findings in themselves. A script with no owner is a script nobody will defend.

Step 2: find which scripts slow a page

Use two kinds of evidence: a measuring tool and a before and after test.

A page speed report names the scripts that take the most time or block the page. Look for the items it flags as render-blocking or as using the most processing time, and note which domain each belongs to. Our guide to checking and improving website speed explains how to read these reports.

The network panel shows the order of loading and how long each request takes. Sort by time and look for a few large items rather than many small ones.

For a direct test, block one script at a time in the developer tools, reload and run the speed test again. If the page improves clearly, that script is a significant cost. Test on a phone-sized view with a slower connection setting, because that is where the difference shows.

Run each test several times. Speed results vary, so one run proves little. Compare averages and change one thing at a time.

Step 3: decide what stays

For each script, ask four questions.

Typical findings are two analytics tools running side by side, a pixel for an advertising account that was closed, a chat widget nobody answers, an old font service and a heatmap tool left on after the test ended. Those can usually go.

Which scripts can be removed safely?

Safe candidates are those with no owner, no recent data and no visible feature. Be careful with anything tied to payment, security checks, consent, forms or order tracking. Removing a script that a form relies on can break the form without any warning. Our guide to getting more submissions from website forms is a good reminder of what depends on those scripts.

Ways to reduce the cost of scripts you keep

Not everything can be removed. For the rest, there are ways to lessen the harm.

• Load scripts after the main content, so the page appears first. Developers call this deferring or loading asynchronously.
• Load heavy tools only when needed. A chat widget can wait until a visitor clicks a button. A video can show a still image until it is played.
• Load a script only on the pages that use it.
• Host files such as fonts on your own domain where the terms allow it.
• Keep tools up to date, and drop the ones their makers no longer support.
• Use fewer tags in the tag manager, and name each clearly.

Take care with privacy at the same time. Check that consent settings control the scripts that need consent. Rules differ by country and change, so ask a qualified adviser and check the current documentation of each provider.

Make the audit part of normal running

An audit cleans up a mess. Governance stops the mess returning.

1. Keep the script table somewhere shared and update it when anything changes.
2. Require a named owner and a reason for every new script.
3. Ask for a review date when a script is added for a campaign, and remove it when the campaign ends.
4. Limit who can add tags in the tag manager.
5. Repeat the audit once or twice a year, and after any redesign.

Ownership matters here. If a supplier installed the tools under their own accounts, you may not be able to see or remove them. Our guide to who should own your domain, hosting and code covers that, and our guide to what to agree in a website development contract explains how to write it down. Teams that provide website development can run the audit with you and rebuild pages so they depend on fewer outside services.

Related guides

• Website development
• Website forms how to get more submissions
• Website security checklist for small business
• Website Ownership: Who Owns Your Domain, Hosting, Code
• Website Traffic Spike: How to Plan So Your Site Holds
• Ecommerce site speed product images and scripts

Questions and answers

What counts as a third-party script?

Any code that your page loads from another company's server. Analytics, advertising pixels, chat widgets, embedded video, maps, web fonts, review widgets and cookie banners are all common examples.

How do I find which scripts slow a page?

Run a page speed report and note the scripts it flags. Then use the browser's network panel to see which outside domains take longest, and block scripts one at a time to see how much the page improves. Repeat each test several times.

Which scripts can be removed safely?

Scripts with no owner, no recent data, no visible feature or a duplicate doing the same job. Be careful with scripts tied to payments, forms, consent or security, and test after every removal.

What is tag bloat?

Tag bloat is the build-up of tracking and widget scripts over time, often added for short campaigns and never removed. It slows pages and adds privacy and security risk.

How often should I audit third-party scripts?

Once or twice a year is enough for most small sites, plus after any redesign or campaign. Keep a shared list so each new script has an owner and a reason.