Third-party scripts: every tag is a dependency
Why every analytics tag, chat widget and pixel on a website is code you run but do not control, and how we decide which ones a site carries.
The short answer
Every analytics tag, chat widget, tracking pixel, heat-map tool, review badge and social embed on a website is a script from another company that runs in your visitors’ browsers with the same power as your own code. It can read the page, set cookies, load further scripts and send data anywhere, and its owner can change it at any time without telling you. Each one adds weight and connections that slow the page, adds a data flow your privacy setup must cover, and adds a way for a compromise elsewhere to reach your visitors. The typical business site carries a dozen, several from tools nobody uses any more. We keep a register of every third-party script with its purpose, owner and data flow, load each one as late and as narrowly as possible, integrate them with consent, and remove the ones nobody can justify. Fewer, justified scripts make the site faster, safer and easier to keep compliant.
What a tag costs
| Cost | How it shows up |
|---|---|
| Speed | Extra connections, hundreds of kilobytes of script, main-thread time on phones; often the single largest cause of a poor mobile score |
| Privacy | Visitor data sent to the third party, often before consent; cookies set; fingerprinting in some cases |
| Security | Code you do not control running on your page; a compromised supplier becomes an attack on your visitors |
| Reliability | A slow or failing third party can delay or break the page |
| Compliance | Each script must be documented, covered by consent where required and reflected in the privacy statement |
| Maintenance | Someone must know what each one does, who owns it and whether it is still needed |
Our rules for third-party scripts
- Every script has an entry in the register before it goes live, with an owner and a purpose.
- Prefer first-party alternatives: self-hosted fonts, cookieless analytics, a form built into the site rather than an embedded one.
- Load as late as possible: after the page is usable, when the visitor interacts, or only on the pages that need it.
- Load as narrowly as possible: the chat widget on the contact page, not every page; the conversion pixel on the thank-you page only.
- Integrate with consent so scripts that need it do not run until it is given, verified in the browser, not assumed.
- Set a content security policy that lists the domains allowed to run code, so an unexpected script fails rather than runs.
- Review quarterly: remove what nobody claims, measure what remains.
The alternatives that remove the need
Analytics that run without cookies and without a heavy script. Forms and booking built into the site instead of embedded. Fonts and icons served from your own domain. Video from a host that does not track. A contact page that offers email and phone rather than a chat widget nobody answers. Each replaces a third party with something you control, and most are better for visitors as well.
What this means for you
Treat every third-party script as a dependency with a cost in speed, privacy and risk. Keep a register, prefer first-party alternatives, load late and narrowly, tie scripts to consent and a content security policy, and review quarterly. A site that carries only the scripts it can justify is faster, safer and simpler to keep compliant, and a site can lose half of its scripts without anyone noticing anything but the speed.
Frequently asked questions
Our marketing team wants to add another tag. What is the harm?
Each tag is a piece of code from another company that runs on every visitor's device with full access to the page. It costs speed, it sends visitor data to that company, it can be changed by them at any time without you knowing, and if their systems are compromised your site becomes the delivery vehicle. None of that means never; it means every tag should have a purpose, an owner and a review date, and be loaded in the least harmful way.
What does a tag manager change?
It makes adding scripts easy, which is the problem as much as the benefit. A tag manager is a script that loads other scripts, so it is itself a dependency, and it often lets people add tags without anyone technical reviewing them. Used with discipline, a register and consent integration, it is workable; used as a free-for-all, it is how a site ends up with twenty scripts and a speed score in the twenties.
How do we know what our site loads today?
Open the site in a private window with the developer tools' network panel open, reload, and list every domain that is not yours, then repeat after accepting the cookie banner. Each domain is a third party receiving visitor data. The list turns up scripts from tools you stopped using, from old agencies, and from experiments nobody remembers.
Sources
- web.dev: Best practices for loading third-party JavaScript (accessed 2026-09-12)