SolisReach
← Journal
Web Performance5 min read

Third-party scripts: an audit framework, not a blanket ban

Written by the SolisReach team

Every performance audit eventually points at third-party scripts: chat widgets, analytics tags, ad pixels, review platform embeds. The advice to "remove third-party scripts" isn't realistic for most businesses, since several of them drive real revenue or real operational value. The useful version of that advice is a framework for deciding which ones are worth their cost, not a blanket removal.

The instinct to treat every script as equally guilty is understandable, since they all show up the same way in a Lighthouse report, as a red flag competing for the main thread. But a chat widget converting real leads and an unused A/B testing tool from a trial nobody canceled are not the same problem, even though they look identical in a performance audit's raw list of offenders. Treating them the same wastes effort removing the wrong one first.

Score each script on value and loading cost separately

We list every third-party script on a site, note what business value it provides, and separately measure its actual loading cost using browser dev tools. A script with high value and low cost stays as-is. High value and high cost gets deferred or lazy-loaded so it doesn't block initial render. Low value and any meaningful cost gets removed, and it's surprising how often that category is bigger than anyone expects once it's actually measured.

This scoring exercise is worth doing with whoever actually owns each tool, not just the developer running the audit, because value is often organizational knowledge a performance report can't see. A marketing team might know a specific pixel is essential for a retargeting campaign generating real revenue, information a script inventory alone won't surface, which is why we run this as a short cross-team review rather than a purely technical exercise.

Load order matters as much as the script itself

A chat widget doesn't need to load before the page's main content is visible and interactive. Deferring non-critical scripts until after the main thread is free, rather than loading everything synchronously in the head, is often a bigger win than removing any individual script, and it doesn't require giving up any functionality at all.

The technique itself is simple: load the script with the `defer` or `async` attribute, or trigger it programmatically after a `window.onload` or a short idle-time delay, so it never competes with the resources actually needed for the first paint. We've cut Largest Contentful Paint by a full second on sites carrying six or more third-party scripts purely by fixing load order, without removing a single tool anyone was actually using.

Revisit the list quarterly, not once

Scripts accumulate the same way font weights and CSS rules do: someone adds a trial tool, the trial ends, the script never gets removed. We put a quarterly script audit into every retainer specifically because this list only ever grows without a deliberate, recurring check.

We've found abandoned scripts from tools a client stopped paying for a year earlier, still loading on every page because removing a script tag felt riskier than leaving it, even after the subscription itself had lapsed. A quarterly check catches this kind of dead weight before it accumulates into the kind of bloated head tag that takes a full day to safely untangle.

The conversation this needs to be, not a unilateral developer decision

A developer removing a script purely on performance grounds, without checking who owns it and why it's there, is how a legitimate revenue-driving tool gets accidentally cut. We always circulate the script inventory to the client before removing anything in the low-value bucket, giving them a chance to flag something we didn't have context on. It adds a day to the process and it's prevented more than one avoidable mistake.

We've had a client flag a script we'd scored as low-value and high-cost, which turned out to be feeding a compliance dashboard their legal team checked weekly. Nobody on the marketing or engineering side had that context, and it wasn't documented anywhere a performance audit would naturally surface it. That one conversation, five minutes on a call, saved us from breaking something a purely technical process would have missed entirely.

A developer removing a script purely on performance grounds, without checking who owns it and why it's there, is how a legitimate revenue-driving tool gets accidentally cut.

What a completed audit typically finds

Across the audits we've run, a typical mid-size marketing site carries somewhere between twelve and twenty distinct third-party scripts by the time anyone actually counts them, and roughly a quarter to a third end up in the low-value, meaningful-cost bucket once measured honestly. That's usually enough on its own to move Largest Contentful Paint by several hundred milliseconds without touching a single piece of actual functionality anyone relies on.

The remaining scripts, the ones that earn their place, still benefit from the load-order fix even when they're not being removed. So a full third-party script audit typically produces two separate wins: a smaller, more defensible list of tools, and a faster-loading page even for the tools that stayed, which is a better outcome than either change would have produced on its own.

We deliver both numbers to a client at the end of an audit, not just the performance improvement: how many scripts were removed and how much they were collectively costing in monthly subscription fees nobody was actively using. More than once, the subscription savings alone paid for the audit itself, which makes an otherwise technical, hard-to-visualize performance project a lot easier to justify to whoever controls the budget. It also gives the finance side of a business a concrete reason to care about a project that would otherwise read as a purely engineering concern, and it turns a performance conversation that used to live entirely inside the development team into one the whole leadership team has a reason to pay attention to, which tends to make the next quarterly audit an easier conversation to schedule.

A short list beats a perfect one

Clients sometimes want the audit to be exhaustive before acting on any of it, waiting for a complete inventory of every script across every page template before removing a single one. We push back on that instinct. Acting on the obvious high-cost, low-value scripts immediately, while the remaining, more ambiguous ones get a slower second pass, delivers most of the performance win in the first week rather than making everyone wait for a perfectly complete list that adds weeks to the timeline for very little additional benefit.

Start a project

Want this applied to your site?

We run a Core Web Vitals and SEO audit before quoting any performance marketing engagement, and we're happy to share what we'd find on yours.