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.
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.
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.
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?
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.
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.
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.
The website still loads. The forms still work. The analytics dashboard still has numbers in it.
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.
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.
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.
The goal at this stage isn't to decide whether a script is good or bad. You're building the inventory first.
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