Third-Party Scripts Audit: Tag Manager, Ads, Chat

A third-party script audit is a structured review of every piece of code on your pages that you did not write, with the cost and the value of each one put side by side. The short version: list every script, block each one in a test and measure the difference, keep only what earns its place, load the survivors in the least harmful way, and repeat the review monthly. This guide applies that routine to tag managers, ad code, chat widgets and consent tools, with decision rules and checklists. It promises no particular score and no ranking result.

It suits a site owner whose pages have quietly grown heavier with each added tool, an SEO specialist negotiating between marketing's tag requests and page experience, and a developer who needs a repeatable way to show what a snippet costs. The legal side of consent tools is outside the scope of this article, and it is not legal advice.

A Page Is Mostly a List of Promises Made by Different People

Before measuring, find out what is on the page. On most sites nobody can name every script, because each was added by a different person, for a different campaign, in a different place.

What counts as third party

Lighthouse defines a third-party script as one hosted on a different domain than the audited URL. In practice, split the list by control: code you ship and update yourself, versus code served from someone else's server whose content you cannot change. The web.dev guide to loading third-party JavaScript (Opens in a new tab) names that lack of control as a common reason these scripts slow pages down.

Three places to look

Combine three sources so that nothing hides:

1. The Network panel in browser developer tools: which domains receive requests during load, how many requests each gets and how much data each moves.
2. The tag manager: which tags are live and which triggers fire them.
3. Your templates and plugin files: hard-coded snippets and code pasted into theme settings.

The third source is the one people skip. A script embedded in a template never shows up in the tag manager, and if it is not in the inventory it is never questioned.

What to record per script

A script with no internal owner is the easiest deletion candidate. If you ask who needs it and nobody answers, switching it off until someone claims it is a reasonable first experiment.

Example scenario: a regional news site

Picture a regional news site. Its pages carry an analytics tool, a tag manager, two ad vendors, a comment platform, a newsletter pop-up, a chat widget from last winter's campaign and a consent banner. During the inventory the team finds the analytics tag twice, once hard-coded and once through the tag manager, and a comment platform that is loaded on pages where comments were switched off. No measurement has been taken yet, and the list has already produced two cleanups.

Weighing Cost Against Value, Script by Script

With the inventory done, each line gets two questions: what does this script give the page, and what does it take from it?

What the cost side contains

The web.dev guide lists the ways third-party code costs you. It can trigger many network requests to multiple servers, and each adds load time. Heavy JavaScript occupies the main thread, can block DOM construction, can delay interaction and can drain batteries. Big unoptimized images or videos consume data. A script loaded without care becomes a single point of failure. Poor caching, weak compression and legacy APIs such as document.write() add to the bill. It also notes that third-party embeds can block window.onload when their servers are slow, even with async or defer.

On the interaction side, the web.dev article on script evaluation and long tasks (Opens in a new tab) explains that the browser parses, compiles and runs JavaScript, and that this work can block the main thread and delay interactions while the page is still loading. Total Blocking Time correlates well with INP, so a high TBT hints that script evaluation is hurting responsiveness during load.

What Lighthouse reports

The Lighthouse audit for reducing the impact of third-party code totals how long each third-party script blocks the main thread during load and flags the page when that total passes 250 ms. Its documentation (Opens in a new tab) gives only that threshold, so derive any further limit for your site from your own measurements. It also notes that, as of Lighthouse 13, the audit moved into the "Use efficient cache lifetimes" insight, so a missing standalone box in a newer report does not mean the topic disappeared.

The block-and-measure method

The surest way to price a script is to remove it and compare. The workflow in the web.dev guide goes like this:

1. Turn on network and CPU throttling.
2. Take a baseline measurement.
3. In the Network panel, right-click the suspect request and choose to block its URL.
4. Reload and measure again.
5. Repeat at least three times.

The guide also mentions grouping by product in the Performance panel, and in WebPageTest the option to block domains and a SPOF view that simulates a third party timing out or failing. Three repetitions protect you from a single noisy run.

Write down the value too

Cost alone is half a decision. For each script, record:

• Which decision or revenue line depends on it, and when it was last used.
• What is lost if it is switched off: income, consent handling, measurement.
• Whether the same job could be done by another script already present, or on the server.
• Whether it is needed on every page or on a few.

A four-way decision rule

Give every line one of four outcomes:

1. Remove: no owner, unclear value, or a duplicate.
2. Narrow: the value is real but only on certain pages. Load it only there.
3. Postpone: the value is real and the script is not needed for the first screen. Start it after interaction or visibility.
4. Keep: tied directly to revenue, a legal obligation or a core feature. Keep it, but with the right loading pattern and a size budget.

If you cannot state a script's value in one sentence and name its owner, default to remove.

Loading Patterns That Limit the Damage

If a script stays, how it loads sets its price. The guide describes these tools.

async versus defer

JavaScript blocks the parser by default. With async, the script downloads while HTML parsing continues, and parsing pauses when it executes. With defer, it downloads in parallel and runs after parsing is complete. The guide suggests async for scripts that should run early, such as some analytics, and defer for less critical ones, and warns against async for essential libraries like jQuery. In Blink-based browsers both attributes lower the request priority, so such a script may arrive later than a blocking one. It adds that async alone will not rescue a page full of tracking scripts.

Warming up connections

Connection setup, meaning DNS, redirects and TLS negotiation for HTTPS, can be slow on weak networks. dns-prefetch does only the lookup. preconnect also covers the TCP round trips and TLS negotiation, and can noticeably cut load time for HTTPS origins. Reserve preconnect for the few origins the page will definitely use early, since each hint spends resources.

Lazy loading and delayed start

Lazy loading postpones embedded resources such as ads and video until they are needed, for instance when the visitor scrolls near them. The guide prefers IntersectionObserver over scroll and resize listeners combined with getBoundingClientRect(), which it calls error-prone and slow. Content can also load after the main content but before a likely interaction. Analytics can be loaded late while preserving early page-load data, and the guide points to one example setup.

For chat widgets a popular pattern is to show a simple button first and load the real widget when it is clicked. This is a general design pattern, not something the web.dev guide describes, but it applies the same lazy-loading principle. Because loading starts on click, show a loading state so the visitor knows something is happening.

Self-hosting

Hosting a script yourself gives control over DNS time and HTTP caching headers. The guide states the catch: a self-hosted copy does not receive automatic updates for API changes or security fixes, so you must apply them by hand. Choose self-hosting only for scripts whose versions you can track, and check the provider's terms permit it.

Iframes and sandboxing

A third-party script in an iframe does not block execution of the main page, an approach the guide says AMP uses. The iframe still delays the onload event, so do not hang critical features on onload. A Permissions Policy can disable selected browser features for third-party content, and the iframe sandbox attribute restricts what embedded scripts can do. Long tasks that originate in iframes can be attributed to a frame with PerformanceObserver and longtask.

Size and splitting for your own code

According to the script evaluation article, every classic script element creates its own evaluation task, and a limit of 100 kilobytes per individual script is a good target, with the caveat that device capability makes exact limits hard to set. Dynamic import() keeps code you do not need at startup out of the way, and web workers move evaluation off the main thread. Splitting has a trade-off: smaller files compress less efficiently but improve cache reuse. These ideas apply to code you author. You cannot change the internals of a vendor's script, only decide when and where it loads.

Starting points by script type

These are starting points. Confirm each with the block-and-measure routine.

Tag Managers: Convenience With a Catch

A tag manager looks like one script but can host dozens. The web.dev guide says Google Tag Manager can deploy tags asynchronously, reduce network calls and collect data through its data layer. It also names the risks: excessive tags and automatic event listeners add network requests and reduce responsiveness, and since anyone with access can add JavaScript, there are security and performance risks. The recommendation is to limit access.

Audit questions for the container

• Which container version is live, and when was it last published?
• Does every live tag have an owner and a reason?
• Are paused tags that nobody needs deleted?
• Are triggers broader than necessary, such as all pages or all clicks?
• Are automatic event listeners actually used?
• Who can publish, and are changes reviewed?
• Is any measurement done twice, once in code and once through a tag?

Duplicate measurement corrupts the data and doubles the cost at once.

Ads, Chat Widgets and Consent Tools

These three categories are the most argued about, because they are tied to business goals. That is why the right outcome is often "manage" rather than "remove".

Advertising code

Ad scripts can bring many requests, auction logic and content of variable height. There are two separate problems: main-thread load and layout shift. Reserving space with a fixed minimum height for the slot addresses the second. For the first, load slots lazily when they are off-screen and trim vendors you do not need. For how auction logic affects a page, see the header bidding and Prebid basics article; for balancing ads against Core Web Vitals, see the publisher balance guide. Screen-covering formats are a separate quality question, covered in the intrusive interstitials article.

Chat widgets

A chat widget looks like a small corner button yet often brings its own frame, fonts and network connections. Apply one rule: load it only on pages where support or sales help is valuable, such as pricing and contact pages, and not on long reading pages. Measure real usage. If few visitors open it, remove it or load it on click.

Consent tools

The consent banner appears on the first screen and gates much of your measurement, so a slow one hurts twice: it delays the page and, because other scripts wait for the choice, it lengthens the chain. How to load the tool, which scripts to hold until consent and how to manage measurement loss is explained in the cookie consent and measurement loss guide. From an audit view, check two things: the tool must not block the main content or the first interaction, and anything meant to wait for consent must really wait. For the legal side, consult the official sources and legal counsel; this article is not legal advice.

Record shifts and delays separately

Ads, chat buttons and consent bars all appear after the page begins. Note separately which one reserves space, which pushes content and which delays the first tap. When three sources contribute to shift on one page, only one-by-one removal tests show who is mainly responsible.

A Monthly Re-Audit That Actually Happens

Third-party code is not static. Vendors ship new versions, marketing adds tags and plugins update. A one-off cleanup drifts back within months.

The monthly routine

1. Update the inventory: new domains, removed scripts, changed owners.
2. Record the total third-party request count and the five heaviest domains in the Network panel.
3. Run Lighthouse on the main templates (home, article, listing, checkout) with the same device profile, and note third-party blocking time.
4. Review last month's changes in the tag manager.
5. Check field data for interaction and layout shift trends. Field data is a 28-day rolling window, so do not read a short wobble as a verdict.
6. Revisit the remove, narrow, postpone and keep decisions.

A third-party budget

Agree a written budget with marketing and engineering. For instance, a new script is added only after an old one is removed or after the requester supplies block-and-measure results. A written rule moves the argument from opinion to evidence and creates less friction than a vague complaint that something is heavy. Derive your threshold from your own measurements. The 250 ms Lighthouse threshold can be a reference point, but it need not be your target.

Security rides on the same inventory

The web.dev guide recommends HTTPS and avoiding HTTP third parties to prevent mixed content, using a Content Security Policy script-src to restrict script sources, and regularly auditing third-party scripts with subresource integrity and secure transmission. A performance audit and a security review can share one inventory, which saves effort.

Audit checklist

• Does the inventory list purpose, owner and date added for every script?
• Were ownerless and duplicate scripts removed?
• Was every script measured with blocking at least three times?
• Are scripts needed on few pages limited to those pages?
• Do non-critical scripts use defer, lazy loading or a wait-for-interaction pattern?
• Is preconnect used only for origins that are truly needed early?
• Are paused tags removed from the tag manager and publishing access limited?
• Do ad slots reserve space and load late when off-screen?
• Does the chat widget load only on pages where it adds value?
• Does the consent tool leave the main content unblocked?
• Is the next audit date on a calendar?

Observation to action table

Frequently Asked Questions

What makes a third-party script slow a page down?

According to web.dev, it can send many requests to many servers, occupy the main thread, block DOM construction, delay interaction and act as a single point of failure. Because you do not control the code, you can only decide when and how it loads.

Should I use async or defer for tracking scripts?

Use async for scripts that should run early, such as some analytics, and defer for less critical ones. Avoid async for essential libraries like jQuery. Async alone will not fix a page with many tracking scripts, so measure and remove what you can.

Does Google Tag Manager slow my site?

The container itself is one script; the tags and triggers inside it carry the cost. web.dev notes that it can deploy tags asynchronously, but excessive tags and automatic event listeners add requests and reduce responsiveness. Clean up paused tags and restrict publishing access.

What is the 250 ms figure in Lighthouse?

Lighthouse adds up how long third-party scripts block the main thread during load and flags the page when the total reaches 250 ms. It is an audit threshold, not a promise about user experience, and since Lighthouse 13 the audit lives inside the "Use efficient cache lifetimes" insight. Audit names and thresholds can change between Lighthouse versions, so check the documentation for the version you use.

How can I measure what one script costs?

Throttle the network and CPU, take a baseline, block the script's URL in the Network panel, reload and measure again. Repeat at least three times and weigh the difference against the script's value.

How often should I repeat the audit?

The documentation does not state a frequency. As a practical routine, repeat it monthly and after any large campaign, theme or tag change, because third-party code can change without any action from you.

Conclusion

Managing third-party code is an ongoing inventory, not a one-time fix. List every script with its owner and purpose. Block each one in a test, weigh the measured cost against the written value, and decide whether to remove, narrow, postpone or keep it. For what remains, apply async, defer, preconnect, lazy loading and iframes where they fit. Limit tag manager access, reserve space for ads, and load chat and consent tools so the main content is never blocked. Then repeat the loop monthly. These steps aim at a faster, steadier experience; they do not guarantee any score or ranking, and nothing here is legal advice on consent.

If you are looking for ad placements that respect page experience, you can browse the ad spaces at Akua Adforce; scope and terms are listed on the product page.