I’ll research current data on third-party scripts and their performance impact before writing.I have strong data. Let me get one more data point on the prevalence and tag manager bloat to round out the article.I have everything I need. Here is the article.
The page builder isn’t the problem. The eleven things you bolted onto it are.
You spent good money on a fast site. The hosting is solid, the images are compressed, the codebase is lean. Then you run a speed test and the score is mediocre. Before you blame your developer or your CMS, open the report and look at what’s actually eating the load. On most mid-market B2B sites we audit, the first-party build is fine. The drag comes from analytics tags, a chat widget, a consent banner, a heatmap recorder, two ad pixels, and a tag manager quietly loading more of all of the above.
Your site isn’t slow. Your third-party scripts are. And the reason this distinction matters is that you fix the two problems in completely different ways. You cannot optimise your way out of a tag pile-up by buying faster hosting. You have to deal with the tags.
Why third-party code hits so much harder than your own
Here is the mechanism, because it explains everything that follows. When a browser loads your page, it does most of the work on a single main thread: parsing HTML, building the page, applying styles, running JavaScript, and registering clicks and taps. JavaScript runs on that main thread by default, and while it runs, nothing else can. Propellernet puts it plainly: long-running JavaScript tasks can block other code from executing, prevent user interactions from registering, and stop the page rendering until that task finishes. So a heavy tag doesn’t just add weight. It freezes the browser mid-job.
With your own code, you can fix this. You can split it, defer it, rewrite the slow function. With third-party code you have none of those levers. DebugBear makes the uncomfortable point directly: unlike first-party code, you can’t fix performance issues arising from third-party scripts yourself. You are running someone else’s software on your visitor’s device, on your domain, and you are accountable for the result while controlling almost none of it.
It gets worse because these scripts rarely arrive alone. The HTTP Archive’s 2025 Web Almanac found that the median depth of a third-party inclusion chain is three, meaning most third parties pull in at least one further third party of their own. You add a tag manager. The tag manager loads analytics. Analytics calls an ad network. The ad network calls another. SpeedCurve describes the trap well: you think you’re adding one script through your tag manager, but you could be adding many more behind the scenes. You approved one line of code. You shipped a supply chain.
How bad it really gets
The scale of this is not subtle. More than nine in ten web pages now include at least one third party, according to the 2025 Web Almanac, and across the whole dataset the median page makes around 79 third-party requests on mobile and 83 on desktop. The same report notes that third-party requests have risen across every rank of site year over year, with individual vendors sending more requests per page even as the number of distinct domains drops. The footprint is consolidating into fewer providers who each do more.
For a sense of just how lopsided the damage can be, SpeedCurve ran one page with and without its third parties. With third parties enabled, Largest Contentful Paint landed at 26.82 seconds. Without any of them, LCP came in under one second. That is not a tuning problem. That is the difference between a usable site and an abandoned one, caused entirely by code the business owner didn’t write.
And these scripts hit the metric Google now uses to judge interactivity. The 2024 Web Almanac performance chapter identified that presentation delay is the main contributor to poor Interaction to Next Paint, mostly caused by third-party scripts for behaviour tracking, consent providers, and CDNs. The tools you bought to understand your users are degrading the experience for those users, and dragging your Core Web Vitals down with them.
The bystander effect of one bad tag
The cruelty here is that one slow script poisons everything after it. If a tag loads synchronously in your page head, the browser stops and waits for that external server before it draws anything. SpeedCurve’s classification is worth internalising: a non-functioning blocking script, for example during a third-party outage, will prevent the page from rendering at all. Your site’s availability is now tethered to the uptime of a vendor you may not even be paying.
This is why the instinct to rip everything out is wrong. As SpeedCurve notes, the slowdown is often caused by just one or two bad actors, not the whole set. You don’t need a purge. You need to find the offenders.
The marketing team won’t like this, and they’re usually the cause
Let’s name the pattern, because it’s the same one almost everywhere. A marketer wants to measure a campaign, so they add a pixel. Someone wants session recordings, so they add a recorder. A new tool promises better attribution, so in goes another script. Nobody ever removes anything, because removing a tag feels risky and adding one feels free. Over a couple of years the tag manager becomes a junk drawer that every browser on earth has to open on every page load.
Lullabot captured the real obstacle precisely: it’s easy to get marketers to agree a fast site is good, and a completely different task to convince them their tags are to blame. That conversation is the whole game. The way to win it is to reframe each tag as a trade. A behaviour-tracking script that adds half a second to load is not free analytics; it is analytics paid for in conversions you will never see because some visitors left before the page responded.
You can put real numbers behind that. Google’s research, cited by Lullabot, found that 53% of mobile site visits are abandoned if a page takes longer than three seconds to load. And speed moves money in both directions: the same source notes the BBC lost an additional 10% of users for every extra second of load time. When a tag costs you visitors, the question stops being “is this data nice to have” and becomes “does this data earn back the customers it costs us”. Often the honest answer is no.
Find the actual culprits before you touch anything
Do not guess. Measure. The good news is that the diagnostic tooling for this is free and surprisingly precise.
Start with PageSpeed Insights. As NitroPack explains, it runs an audit called “Reduce the impact of third-party code” that sorts every third party by main-thread blocking time, so the worst offender sits right at the top of the list. Propellernet adds that the same audit lists each resource-intensive script alongside its file size and the length of time it blocked the main thread. That single view usually identifies your problem in under a minute.
Then confirm the cause by removing it temporarily. This is the step most people skip and it’s the most convincing. The web.dev team recommends a clear workflow: in Chrome DevTools, measure your load time, then block the URLs or domains responsible for the scripts you suspect, reload, and measure again. Crucially, they advise turning on network and CPU throttling, because your users are unlikely to have the fast connections and desktop hardware that hide expensive scripts under lab conditions. Test on a throttled mid-range phone, not your developer’s machine. The phone is where the damage shows.
When you record a performance profile, watch for Long Tasks. SpeedCurve defines a Long Task as any process consuming more than 50 milliseconds on the main thread, and the more of them you have, and the longer they run, the greater the risk of slowdown. A tag that throws up several long tasks during initial load is exactly the kind of script that delays interactivity even after your content looks ready.
A practical first-pass checklist for the audit:
- Run PageSpeed Insights on a real page, mobile profile, and read the third-party code audit top to bottom.
- List every tag in your tag manager and write down who owns it and why it exists.
- Block each suspect domain in DevTools and re-measure to confirm its true cost.
- Flag anything nobody can justify, and anything firing on every page that only needs to fire on one.
What to do once you’ve found them
You have a short menu of options, in rough order of preference.
Remove it
The cheapest fix is deletion. The patterns.dev guidance is blunt: if the value a third-party script provides is not proportional to its performance cost, remove it. The recorder nobody has opened in six months, the analytics platform you replaced but never uninstalled, the social widget that gets two clicks a month. Kill them. Every script you delete is a network round trip, a chunk of main-thread work, and a potential point of failure that simply stops existing.
Defer it
Most marketing and analytics tags do not need to run before the page appears. As patterns.dev sets out, defer should be the default choice for any script not needed in the critical rendering path, fetching it in parallel while the parser works and executing it only after the page is built. The fear is always that deferring will distort the data. The evidence says otherwise. The widely cited Telegraph case found that deferring all scripts did not skew any analytics or advertising metrics, and the First Ad Loaded metric actually improved by an average of four seconds.
Delay it until the user needs it
Some tools only matter on interaction. A chat widget that nobody opens does not need to load its full payload on arrival. DebugBear describes the facade approach: show a lightweight placeholder for the chat widget and only load the real thing when the user actually tries to interact with it. The same logic applies to anything triggered by scrolling or clicking. One illustrative example is loading social widgets only after the main content has rendered or when the user scrolls near them, so the cost lands when there’s value to justify it.
Move it off the main thread
For scripts you cannot remove or delay, there is a more technical route. DebugBear explains that the Partytown library can run third-party scripts in a web worker instead of on the main thread, freeing the main thread to render content and handle interactions. There is a genuine trade-off, and it’s worth being honest about: the third-party code itself can become less performant as a result, which is largely by design, because your own content and logic get prioritised. For a heavy analytics tag that the business insists on keeping, that trade is usually worth making.
The reason this keeps happening, and the only real fix
Most teams treat performance as something you fix after launch. You build the site, you ship it, then someone runs a speed test, panics, and starts patching. By then the architecture has hardened and the tags have multiplied, so every fix is a fight against decisions already baked in. Speed is an outcome of the choices you make before the build, not a coat of paint you apply afterwards.
In our projects we set a performance budget before design starts, and that budget covers third-party scripts explicitly, not just images and code. A budget turns the junk-drawer problem into a forcing function: if the page has a fixed allowance for main-thread blocking time, then adding a new tag means consciously removing or downgrading another. Marketing gets their tools, but the trade becomes visible instead of invisible. That single discipline does more for long-term speed than any amount of post-launch optimisation, because it stops the bloat at the moment it tries to enter.
It also changes how you negotiate with vendors. DebugBear’s advice is sound and under-used: if a third party is causing a performance issue, contact their support team, because they may be able to resolve it with no change required from your side. A vendor whose script you’re considering cutting will often suddenly find a lighter version or an async loading option. You have more leverage than you think, but only if you’ve measured the cost and can name it.
What to do this week
Pick your highest-traffic page and run it through PageSpeed Insights on the mobile profile today. Read the “Reduce the impact of third-party code” line and write down the top three offenders by blocking time. Then open your tag manager and produce a simple inventory: every tag, who owns it, and the last time anyone used the data it produces. You will almost certainly find at least one script you can delete outright and two more you can safely defer.
That exercise alone will tell you whether you have a hosting problem or a tag problem, and in our experience it’s nearly always the latter. If you’d like a second pair of eyes on what your scripts are actually costing you, and a view on what a performance budget would look like for your site, you can book your free discovery call and we’ll walk through your specific situation. Either way, stop blaming the engine. Check what you’ve been towing behind it.
Ready to get started?
