Your Marketing Site Has 40 Scripts. Which Ones Are Actually Worth Keeping?

Hadil Ben Abdallah — Tue, 13 Oct 2026 09:09:59 +0000

Third-party scripts are easy to accumulate on a marketing website. A site might start with GA4 for analytics, a cookie banner, and a chat widget.

A year or two later, the list can look very different.

There’s a tag manager, heatmaps, session recordings, A/B testing, ad pixels, a CRM integration, a chatbot, a scheduling tool, a consent platform, embedded videos, social widgets, product analytics, and other tools.

Each one had a reason to exist.

The problem is that the browser doesn't care why you added it.

It has to download, parse, and execute that code on a real visitor's device. Some third-party scripts consume CPU, compete for network resources, delay other work, or add work to the main thread. Chrome's performance guidance specifically calls out third-party code as a significant source of page-load and JavaScript costs.

And that creates a problem that has very little to do with whether your marketing team likes a particular tool.

The question is whether the tool still earns its place on the website.

TL;DR

Keep a third-party script when it has a clear business purpose, an identifiable owner, useful data or functionality, and a cost that makes sense for the pages where it runs.

Remove it when nobody can explain why it exists, nobody uses the data it collects, another tool already does the same job, or its performance and maintenance cost are greater than its value.

A practical way to evaluate every script is to ask:

What does this script do?
Who actually uses what it provides?
Does it affect leads, conversions, analytics, customer experience, or another measurable business outcome?
Does another tool already cover the same job?
Does it need to load on every page?
What does it cost in performance, privacy, maintenance, and reliability?
Who owns it?

If you cannot answer those questions, the script deserves an audit.

Why Too Many Third-Party Scripts Become a Problem

Third-party code is common on modern marketing websites. Analytics platforms, advertising tools, chat systems, consent management, testing platforms, embedded content, and other services often depend on JavaScript loaded from an external domain.

That doesn't automatically make them bad.

A script that sends important conversion data to your analytics platform can be worth its cost. A consent-management platform may be essential for how your site handles tracking. A scheduling widget may directly support your sales process.

The problem starts when the list grows without anyone reviewing it.

A marketer adds a new tool for a campaign. A developer installs its snippet. Another team adds a heatmap tool six months later. A redesign introduces a second analytics implementation. An agency adds its own tracking script. The campaign ends, but the script stays.

Nothing looks broken.

The website still loads. The forms still work. The analytics dashboard still has numbers in it.

Meanwhile, the browser is doing more work every time someone visits the site.

Chrome's Lighthouse documentation notes that third-party scripts can significantly affect page performance, including the amount of work performed on the browser's main thread.

That matters even more on marketing websites because the third-party script list often grows through small, reasonable decisions rather than one obviously bad technical choice.

The result is script bloat.

And script bloat is difficult to spot when you look at each tool separately.

How to Find Every Third-Party Script on Your Website

Before deciding what stays and what goes, you need a complete inventory.

This sounds simple until you actually do it.

A script can be added directly to a page, injected through Google Tag Manager, loaded by a WordPress plugin, included by a Webflow integration, or introduced by another third-party tool. Looking at the page source alone may give you an incomplete picture.

For a proper audit, I would check the website from several angles.

Start with the browser

Open Chrome DevTools and go to Network.

Reload the page with the Network panel open, then filter by:

JS
Fetch/XHR
Img
Doc

The JavaScript filter is the obvious starting point, but don't stop there. A third-party tool may load JavaScript and then make additional requests through XHR or fetch.

Look at the domains making those requests.

You might find something you recognize immediately:

www.googletagmanager.com
www.google-analytics.com
connect.facebook.net
snap.licdn.com
static.hotjar.com

You may also find domains that mean nothing to you.

Those deserve investigation.

The goal at this stage isn't to decide whether a script is good or bad. You're building the inventory first.

Check your tag manager

If the site uses Google Tag Manager, open the container and review every tag.

Pay attention to:

tags that are still active
tags with unclear names
old campaign tags
duplicate analytics tags
tags firing on every page
tags that were created for a temporary campaign
tags owned by former employees or agencies

Check your CMS and plugins

If the website runs on WordPress or another CMS with integrations and plugins, check those too.

A plugin may inject tracking code without anyone adding a script manually.

This is one reason script audits should include the systems responsible for adding code, not just the code itself.

You may discover that the same service is being loaded through two different paths.

For example:

GA4 is configured directly in the CMS
another GA4 implementation exists in GTM
a plugin adds another tracking library
a custom script sends additional events

The result can be duplicate data and unnecessary browser work at the same time.

Measure the Cost of Third-Party Scripts

Once you have the inventory, measure the actual impact.

This is where Chrome DevTools and Lighthouse become useful. Core Web Vitals can also help you understand how performance issues affect the actual experience of visitors.

Lighthouse has a dedicated third-party summary that helps identify third-party resources and the amount of main-thread work associated with them.

You can also use Chrome DevTools to inspect individual requests and understand what happens when the page loads.

Look at:

request count
transferred size
resource size
loading time
JavaScript execution
main-thread activity
additional network requests
when the resource starts loading
whether it blocks or delays important work

Don't obsess over one number.

A 200 KB script isn't automatically worse than a 50 KB script. The smaller script could trigger several additional requests or perform expensive JavaScript work after it loads.

Likewise, a script that takes a little time to load may still provide significant business value.

The broader impact of website speed also matters when evaluating third-party code, especially on marketing sites where performance directly affects the user experience.

You're looking for the cost-to-value ratio.

Look for Duplicate Functionality

One of the easiest wins in a script audit is finding tools that overlap.

A growing marketing stack can accumulate several tools that solve almost the same problem.

For example, you might have:

GA4 for analytics
another product analytics platform
a heatmap tool
a session-recording tool
a CRO platform
a separate event-tracking solution

They aren't identical, but there may be significant overlap.

The same thing can happen with tracking.

You might find multiple systems tracking:

page views
form submissions
CTA clicks
video plays
conversions

That creates two problems.

First, you're paying for tools that may not all be necessary.

Second, your team can end up with several versions of the same event and different numbers in different dashboards.

That kind of inconsistency can make analytics harder to trust, especially when multiple tracking systems are collecting similar data.

The technical cleanup can be easy.

The organizational cleanup is usually harder.

Someone needs to decide which system is the source of truth for each type of data.

Do Third-Party Scripts Need to Load on Every Page?

This is one of the highest-value questions in the entire audit.

A tool can be useful without needing site-wide access.

Consider a scheduling widget.

If its only purpose is to let visitors book a call, loading it on every blog article may not make sense.

The same applies to:

calculators
interactive demos
chat tools
review widgets
embedded videos
campaign-specific tracking
product-specific functionality

A simple rule is useful here:

If a script only supports one type of page, try to load it only where that functionality is needed.

This can reduce unnecessary requests and JavaScript execution on pages that don't benefit from the tool.

It also makes the website easier to reason about.

When someone investigates a slow blog post six months from now, they won't have to wonder why it is loading a collection of sales and product widgets that have nothing to do with the article.

A Script Audit Should End With a Decision

Once you've collected the data, every script should have a clear status.

I like using five:

1. Keep

The script provides meaningful business value, and its cost is justified.

2. Optimize

The tool is valuable, but its loading behavior, implementation, or scope can be improved.

3. Restrict

The tool is useful only on certain pages, for certain users, or after a specific interaction.

4. Replace

The business needs the functionality, but another implementation may provide a better balance of functionality, reliability, and performance.

5. Remove

Nobody needs it, nobody owns it, or its value doesn't justify keeping it.

That final category is often smaller than people expect.

The goal of a good audit isn't to delete half the website.

It's to make sure every piece of third-party code has a reason, an owner, and an appropriate place in the user journey.

Consent Changes the Loading Strategy

Privacy and consent requirements add another layer to script management.

Not every tracking or marketing script should necessarily load in the same way for every visitor.

Depending on the jurisdiction, consent configuration, and purpose of the technology, some third-party scripts may need to wait until the appropriate consent has been given. Google's Consent Mode documentation explains how Google tags can adjust their behavior based on a user's consent choices.

That means your audit should document:

which scripts are strictly necessary
which require consent
what happens when consent is denied
whether the consent platform actually controls the scripts
whether tags can fire before the expected consent state
whether the implementation matches your organization's privacy requirements

This is another reason you shouldn't simply copy a list of scripts from one website to another.

The technical implementation and the privacy requirements need to be considered together.

A consent banner that exists visually while tracking scripts continue firing before the appropriate consent state isn't solving the underlying problem.

The Goal Isn't Fewer Scripts. It's a Website You Can Explain.

A marketing website can have dozens of integrations and still be well managed.

The problem isn't the number sitting in your inventory.

The problem is when nobody can explain what those scripts do, why they load, who owns them, or what would happen if they disappeared.

That's when your marketing stack starts becoming technical debt.

A good WebOps process gives every integration a purpose and a place.

It also gives the team a way to challenge old decisions.

A tool that made perfect sense two years ago may not make sense today. A campaign may have ended. A new platform may have replaced an old one. A feature may have moved into another part of the stack.

The website should evolve with those changes.

And that brings us to the simplest rule I use for third-party scripts:

If you can't explain the value, the owner, the scope, and the cost, it's time to investigate why the script is still there.

Frequently Asked Questions

How many third-party scripts should a marketing website have?

→ There is no universal number that defines a healthy website.

A site with 10 scripts can have serious performance or tracking problems, while another site with 30 or 40 can be well managed.

What matters is whether each script has a clear purpose, an owner, an appropriate loading scope, and a reasonable technical cost.

Focus on understanding and controlling the script stack instead of chasing a specific number.

Do third-party scripts slow down a website?

→ They can. Third-party scripts can add network requests, download JavaScript, consume CPU, execute code on the main thread, and trigger additional resources.

The actual impact depends on the service, how it is implemented, when it loads, and what it does after loading.

Tools such as Chrome DevTools and Lighthouse can help you identify which third-party resources are contributing to the work performed by the browser.

Should I remove Google Tag Manager to improve website performance?

→ Not automatically. Google Tag Manager is a container that can load many different tags, so the performance impact depends heavily on what you put inside it.

Removing GTM while leaving the underlying tracking requirements unresolved may simply move the problem somewhere else.

Audit the tags inside the container first. Remove unused tags, eliminate duplicate tracking, restrict tags to relevant pages, and review how non-critical tags are loaded.

Should every marketing script load on every page?

→ No. A script should generally load wherever its functionality or measurement is actually needed.

A scheduling tool may only be necessary on pages where visitors can book a meeting. A product demo widget may only belong on product pages. A campaign-specific tracking script may only be relevant during a particular campaign.

Reducing unnecessary site-wide loading can improve performance while keeping the functionality your marketing team actually needs.

How often should I audit third-party scripts?

→ For many B2B SaaS websites, a quarterly review is a sensible starting point.

You should also review the script inventory after major website changes, migrations, new marketing tools, tracking architecture changes, or campaigns that introduce temporary integrations.

The exact frequency depends on how quickly the website and marketing stack change.

Final Thoughts

Having less scripts in your marketing site shouldn’t be just a goal in itself. Your site must utilize a technology stack that your marketing team is familiar with and can justify.

Each and every third-party script must justify its right to exist through efficiency of its business function, prevail scope, and the known owner.

Next time you find dozens of third-party requests present in DevTools, don’t ask yourself how to get rid of them. Instead, try to find out which requests actually has the right to exist.

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben AbdallahFollow

Software Engineer • Technical Writer (300K+ readers & 25K+ followers) • Trusted by 20+ startups and tech companies worldwide I turn brands into websites people 💙 to use

DEV Community: Yasser Soliman