Third-party scripts: how tags, pixels and widgets slow your site

Every analytics tag, ad pixel, chat widget and video embed on your website is a third-party script: code written by someone else, running on your visitor’s phone while your own page is trying to load. One or two rarely matter. Fifteen, added over the years for different campaigns, often do: they’re a common reason a site that was fast at launch feels sluggish later.

This guide shows the marketing and digital teams who add them how to see what actually loads, cut the cost without losing tracking and stop the slowdown returning. It covers one layer of website speed optimisation; if you haven’t confirmed where your site loses time, start there.

The short answer

Third-party scripts slow websites in four ways:

• They compete for the main thread, where the browser also handles taps, so interactions lag and Interaction to Next Paint (INP) suffers.
• They delay the main content by blocking rendering, hiding the page during tests or competing for bandwidth, which hurts Largest Contentful Paint (LCP).
• They add connections and requests, because one tag often loads several more files from other domains.
• They move things around when widgets and banners arrive late, raising Cumulative Layout Shift (CLS).

The fix: list what loads, remove what nobody uses, load the rest only where and when it’s needed, replace heavy embeds with lightweight “facades”, and weigh every new tag against a performance budget.

How third-party scripts slow a page

They compete for the main thread

A page has one main thread. It runs JavaScript, works out the layout, paints the screen and responds to taps, one job at a time. Any task longer than 50 milliseconds counts as a long task, and while it runs, the visitor’s tap waits.

Many third-party scripts keep working after the page loads, watching scrolls and clicks and sending data home. On a mid-range phone that work takes far longer than on the laptop where the tag was tested, so the page looks ready but ignores the first tap. Google rates an INP of 200 milliseconds or less as good; Core Web Vitals explained covers how it’s measured.

They can hold back the main content

• Blocking scripts. A plain <script> tag in the page head, without async or defer, stops the browser building the page until it has downloaded and run. If the vendor’s server is slow, your page waits. Render-blocking resources explained covers the mechanics.
• Anti-flicker snippets. Client-side A/B testing tools often hide the page until their script arrives or a timeout passes. While the page is hidden, your main content doesn’t count as painted, so LCP waits.
• Bandwidth. On a slow connection, early scripts share the pipe with your hero image.
• The banner as main content. On a phone, a cookie banner with a paragraph of text can be the largest element on screen, so LCP waits for the consent script to draw it.

They add requests and move things around

Each new domain needs a DNS lookup, a connection and a secure handshake, and the tag you added is often just a loader for a larger library, iframes and tracking beacons. Ten tags in your tag manager can mean dozens of requests in the browser. Widgets that arrive after the page has drawn also push content down just as someone goes to tap.

The usual suspects, and what each one costs

Costs vary by vendor and set-up; these are the places to look first:

AI chat assistants deserve the same scrutiny as any widget; adding AI to your website looks at which AI features earn their place.

How to see what’s actually loading

Start with the tag manager, then look beyond it

List every tag in Google Tag Manager, or whichever tag manager you use, with its trigger. Then keep going: scripts also arrive through the theme, WordPress plugins, header snippets and page-builder blocks. Only the browser shows the complete list.

PageSpeed Insights: which providers cost the most

Test your homepage and one or two key templates on mobile, taking the middle of three runs. The lab results include a third-party breakdown by provider, with transfer size and main-thread time; its label changes between Lighthouse versions, so search the report for “third-party” or “3rd parties”. How to read a PageSpeed Insights report explains the rest.

Chrome DevTools: the complete list

1. Open the page in a private window, right-click, choose Inspect and open the Network panel.
2. Tick “Disable cache”, choose a mobile throttling preset and reload.
3. Under “More filters”, tick “3rd-party requests” (or type -domain:*yourdomain.com in the filter box). Sort what’s left by domain to group each vendor, then by size.
4. Accept the cookie banner and reload. Many tags load only after consent, so you are really testing two versions of the page.
5. In the Performance panel, record a reload with CPU throttling and look for long tasks, flagged in red. In recent Chrome versions, the Summary tab also lists main-thread time and transfer size for each third party.

Put a number on one script. Right-click one of the vendor’s requests, block its domain (under “Block request” in recent versions), reload and compare. It’s the quickest way to see what a single widget costs; remove the block afterwards, because DevTools remembers it. If you’re not yet sure third parties are the main problem, why is my website slow? sets out the full diagnosis.

Keep a tag register

Record each tag in a shared sheet: what it’s for, who owns it, which pages it runs on, when it loads, its consent category, its measured cost, its last review and the decision (keep, delay, replace or remove). A row nobody can fill in is usually your first removal.

How to reduce third-party code without losing tracking

Work in this order; the first two need no new tools and often bring the biggest gains.

1. Remove dead and duplicate tags

Typical finds on an older site:

• pixels from finished campaigns and tools left over from free trials
• Universal Analytics tags, which Google stopped processing in July 2023 (July 2024 for 360 properties)
• Google Optimize code, including anti-flicker snippets that only hide the page, left over since the product closed in September 2023
• GA4 installed twice, by a plugin and the tag manager, which also double-counts page views

Pause anything without an owner for two weeks. If nobody complains, remove it; Tag Manager’s version history keeps the old set-up if you ever need it back.

2. Load only on the pages that need it

A map belongs on the contact page, a booking widget on the booking page. Ad platforms need more care: the conversion event fires only on a successful submission, but the base tag (or Google’s conversion linker) usually runs on every page to record which ad brought the visitor, and retargeting needs every page to build audiences. Follow each platform’s own instructions.

3. Load later

In Google Tag Manager, move tags that aren’t needed straight away from the Page View trigger to Window Loaded, or fire them after the first scroll or click. Keep the consent tool and core analytics early, so short visits still count. For scripts added directly to the page, use defer or async where the vendor’s instructions allow it.

Anything loaded later misses visitors who leave within seconds. That hardly matters for a heatmap, and key events still fire on the action itself.

4. Swap heavy embeds for facades

A facade is a lightweight stand-in that looks like the real thing and loads it only on interaction, a pattern Google’s performance guidance recommends.

• Video: show the thumbnail and a play button, and load the player on click. A YouTube embed facade is one of the simplest wins available.
• Maps: show a static map image with a “Get directions” link, or load the map on click.
• Chat: a button styled like the launcher loads the widget when pressed. Proactive greetings won’t appear, so check your chat history: if visitors start most conversations, you lose little.

Build each facade as a real <button> with a clear label (“Play video: how our process works”) so keyboard and screen-reader users can use it. For embeds lower down, loading="lazy" on the iframe waits until the visitor scrolls near.

5. Consider server-side tagging, where it makes sense

With server-side tagging, the page sends one stream of events to a server you control, such as a Google Tag Manager server container, which forwards them to analytics and ad platforms. Fewer vendor scripts run on the visitor’s phone, and you control what data leaves.

It suits sites with real ad spend across several platforms and someone to maintain it. For a site with GA4 and one pixel, it’s rarely worth it: the server costs money every month, set-up needs specialist skills, some platforms still expect their browser tag and consent obligations don’t change.

After any change, check your tracking. Test in Tag Assistant’s preview mode, then compare key events with real enquiries for a couple of weeks. Our guide to GA4 conversion tracking shows how.

Set a performance budget for third-party code

A performance budget is a short set of limits agreed before anything new is added. Take a mobile baseline on three or four key templates and set rules against that, not against an ideal.

Only the first line uses Google’s published thresholds; the rest are house rules that turn “the site feels slower” into a yes-or-no question.

A tag-approval routine that stops speed creeping back

Slow sites are rarely one bad decision. They’re twenty reasonable ones nobody revisited.

Before a new tag goes live:

• It supports a named campaign or question, and has an owner.
• It runs only on the pages that need it, as late as its job allows.
• It sits in the right consent category.
• It’s tested in preview, with a before-and-after mobile test.
• It fits the budget, or something else comes out.
• It has a removal or review date.

Every quarter, walk through the register, remove what has expired, re-run the baseline tests and check the Core Web Vitals report in Search Console.

Limit who can publish. Google Tag Manager separates permission to edit from permission to publish, so give publishing rights only to the one or two people who own the website and know the budget.

What to do next

Third-party scripts aren’t the enemy; analytics, pixels and chat earn their place when they serve a clear purpose. The problem is accumulation: tags nobody owns, loading everywhere. An afternoon in the tag manager and DevTools often finds the worst of it; a budget and an approval routine keep it away.

If you’d rather hand that routine to someone else, our website care plans keep your site updated and monitored, and the Growth plan adds monthly improvements and speed work. Not sure whether tags are your main problem? Speed is one of the areas our free website audit reviews.