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

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.

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.

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.

Written by Hadil Ben Abdallah

Software Engineer • Technical Writer (1M+ Readers & 25K+ Followers) • LinkedIn Brand Designer & Profile Optimizer