Third-party scripts: the weight you did not write

Analytics, tag managers, chat widgets and pixels each look harmless on their own. Together they decide how fast your page is — here is how to take stock and cut them back.

Performance · Published: 3 October 2026 · 7 min read · Ольга Мирошник

Open the network panel on almost any commercial site and count the domains. Your own origin, a CDN, then a long tail: analytics, a tag manager, two ad pixels, a chat widget, an A/B testing tool, a font service, a map, a video embed. None of that code was written by your team, none of it is reviewed in your pull requests, and all of it runs with the same rights as your own JavaScript.

Each tag was added for a good reason by someone who needed it. The problem is that nobody owns the sum.

What every new origin costs

Connection setup. A new domain means a DNS lookup, a TCP handshake and a TLS negotiation before the first byte of the script arrives. On a mobile connection that is easily several hundred milliseconds per origin, and a script that loads more scripts from yet another domain pays it again.

Main-thread time. Third-party JavaScript has to be downloaded, parsed and executed on the same thread that handles clicks and taps. A chat widget that boots a whole UI framework or an A/B tool that rewrites the DOM competes directly with your page's interactions, and it shows up as poor INP (Interaction to Next Paint).

Render blocking. A plain <script src> in the <head> without async or defer stops the parser until it has been fetched and run. Some A/B testing snippets do this deliberately, and hide the page until they finish, to avoid flicker.

Single point of failure. If a vendor's server is slow or down, a blocking script makes your page slow or blank with it. Your uptime now depends on theirs, and your monitoring will not tell you why.

Privacy and consent. A pixel that fires before the visitor has answered the cookie banner sends their data to a third party without consent. Loading the script at all is often enough to transfer the IP address and a referrer.

Security. Every external script is part of your supply chain. If the vendor or the CDN is compromised, the attacker's code runs on your checkout page. A strict Content Security Policy becomes much harder to write when the allowlist grows with every tag.

Take inventory

Start with facts rather than memory:

• In Chrome DevTools, open Network, reload, and group or sort by domain. Note every origin that is not yours and what it loads.
• Open the Coverage panel to see how much of each script actually executes on a typical page.
• Look inside the tag manager: list every tag, its trigger and the date it was last changed.

For each tag, ask three questions. Who owns it? If nobody can name a person or a team, that is a candidate for removal. Is it still used? Pixels for campaigns that ended last year and trials of tools that were never bought are common finds. Does it need to load on every page, immediately? Usually the answer is no.

A SiteScan report helps with the first step: it counts the third-party origins your pages load resources from and flags it when there are too many ("Cut the number of third-party origins the pages load from"). It also lists the technologies and widgets it detects on the site, which is a quick way to spot a forgotten tool.

Techniques that work

Remove. The fastest script is the one that is not there. Deleting two dead tags beats optimising five live ones.

Defer what stays. Analytics and most pixels can use async or defer, or be fired from the tag manager after the page has loaded. Nothing that does not draw the first screen should block it.

Load on interaction. A chat widget or a YouTube embed does not need to boot before anyone wants it. Show a lightweight facade — a static button or a thumbnail image — and load the real thing on click:

<button class="chat-facade" type="button">Chat with us</button>
<script>
  document.querySelector(".chat-facade").addEventListener("click", () => {
    const s = document.createElement("script");
    s.src = "https://widget.example-chat.com/loader.js";
    document.head.append(s);
  }, { once: true });
</script>

Self-host where the licence allows. Fonts and small libraries served from your own origin skip the extra connection and stay under your caching rules.

Preconnect sparingly. <link rel="preconnect"> helps for the one or two third-party origins that are on the critical path. Adding it for ten origins just spends early bandwidth and sockets on things that are not urgent.

Keep the tag manager clean. Restrict who can publish, require a description and an owner for each tag, and review the container regularly. A tag manager makes adding scripts easy; it should not make it invisible.

Pin static files with Subresource Integrity. For a versioned library on a public CDN, an integrity attribute makes the browser refuse a file that has been altered:

<script src="https://cdn.example.com/lib@2.4.1/lib.min.js"
        integrity="sha384-..."
        crossorigin="anonymous"></script>

SRI does not work for scripts the vendor changes in place, which is exactly why those deserve the most scrutiny.

Set a budget. Agree on a limit — number of third-party origins, kilobytes of third-party JavaScript — and check it before each new tag goes live. A budget turns "just one more pixel" into a decision.

Check-list

1. Every third-party origin is listed with an owner and a purpose.
2. Unused tags and expired campaign pixels are removed.
3. No third-party script blocks rendering of the first screen.
4. Chat widgets and video embeds load on interaction behind a facade.
5. Nothing that tracks visitors loads before consent.
6. Preconnect is used only for the one or two critical origins.
7. Static CDN files carry an integrity attribute.
8. A third-party budget exists and new tags are checked against it.