Ask a marketing team how many third-party scripts run on their website and the answer is usually a guess. Ask the browser and the number is often much higher. Analytics, ad pixels, heatmaps, chat widgets, A/B testing tools, video embeds, review widgets and social buttons all load code from someone else's server, and each one was added for a good reason at some point.

Over time these scripts become one of the biggest causes of slow pages, a major privacy obligation and, occasionally, a security risk. An audit once or twice a year keeps them under control.

Why third-party scripts deserve attention

Speed

Every script competes for the same browser main thread your page needs to respond to visitors. Third-party code is a common cause of poor Interaction to Next Paint scores, and you cannot optimize code you do not control. You can only decide whether, when and where it loads.

Privacy and consent

Most marketing scripts set cookies or collect data about visitors. Under GDPR and the ePrivacy rules in Europe, and a growing number of US state privacy laws, many of them need a legal basis or consent before they run. A cookie banner does not help if scripts load before the visitor answers it, or keep loading after they decline.

If you advertise with Google to visitors in the European Economic Area, Google has required Consent Mode v2 signals since March 2024. Without it, conversion tracking and remarketing for those visitors are limited.

Security

A third-party script runs with the same power as your own code. It can read what visitors type into forms and change what the page shows. If the provider is compromised, or the domain changes hands, your site serves whatever that domain now delivers.

This is not theoretical. The polyfill.io domain, used by more than 100,000 websites to load a common JavaScript helper, was bought by a new owner in early 2024. In June 2024, security researchers found it serving malicious code that redirected some visitors of those sites to scam and gambling pages.

For sites that take card payments, PCI DSS version 4.0 added specific requirements for scripts on payment pages, including keeping an inventory, justifying each script and detecting unauthorized changes. Those requirements became mandatory on March 31, 2025.

The audit, step by step

1. Make an inventory

Open your key pages in Chrome, open DevTools, and look at the Network panel filtered to JavaScript. Group requests by domain. Do this on the home page, a typical content page, a form and, if you have one, the checkout.

Then open your tag manager and list every tag, its trigger and when it was last changed. Tag managers are where forgotten scripts live.

2. Find an owner for each script

For each script, write down who in the organization uses it and for what. If nobody can name an owner, that is a strong sign it can go. Common examples are old A/B testing tools, pixels for ad platforms you no longer use, and heatmap tools from a past redesign.

3. Measure the cost

Use the Performance panel and Lighthouse to see how much main-thread time each script takes, and the Coverage panel to see how much of the downloaded code actually runs. Some tools are light. Others add hundreds of milliseconds of work on a mid-range phone.

4. Check consent behavior

Clear your cookies, load the site, and watch which requests fire before you touch the cookie banner. Then decline and browse a few pages. Then accept and check again. Every script that runs before consent, or after a decline, needs a clear justification as strictly necessary, or it needs to be fixed.

It is also worth checking that consent actually reaches the tools. A banner can save a visitor's choice correctly while the analytics setup is waiting for a different signal, which means tracking is either always on or never on.

5. Decide: keep, change or remove

For each script, choose one:

  • Remove it if nobody uses its data.
  • Load it later, after the page is interactive or after a user action, if it is not needed immediately.
  • Load it only on the pages that need it, instead of site-wide.
  • Replace heavy embeds with a lightweight placeholder. A static preview image of a video or map that loads the real embed on click is a common pattern.
  • Self-host small libraries instead of loading them from a public CDN, so you control the exact code you serve.
  • Keep it as it is, with a named owner and a date for the next review.

6. Protect what stays

For scripts loaded from fixed URLs, use Subresource Integrity, which makes the browser refuse a file that does not match a known hash. A Content Security Policy can limit which domains are allowed to load scripts at all. Restrict who can publish changes in your tag manager, and review its change history.

Make it a habit

The audit is most valuable when it is repeated. Add a short rule to your process: every new third-party script needs an owner, a reason and a review date, and somebody checks its effect on speed and consent before it goes live.

The result is a site that is faster, easier to defend in a privacy review and less exposed to someone else's security problem.

Want us to audit the scripts on your site? Get in touch and we will send you a clear list of what to keep, change and remove.