Growth Notes

Third-Party Scripts

Tags: web-dev analytics concept

Third-Party Scripts

Date: 2026-08-16

Code you didn’t write, running with full access to your page, from servers you don’t control. On most retail sites they’re the largest single cause of poor responsiveness — and nobody owns them, which is why nothing ever gets removed.

What it is

A third-party script is JavaScript loaded from an origin you don’t control: analytics, tag managers, chat widgets, review platforms, testing tools, personalisation, ad pixels, consent banners, fraud detection.

The critical property: a cross-origin script is not sandboxed. It executes with your page’s full privileges — your DOM, your cookies, your storage, your forms. Loading one is a trust decision, not a performance decision. See The Same-Origin Policy.

What they actually cost

Four distinct costs, and the file size is the smallest of them.

CostWhy it hurts
NetworkAn extra origin means DNS + TCP + TLS before a byte of script arrives
Main threadParse, compile and execute all block the one thread that also renders — Long Tasks and Blocking
CascadeMost tags load further scripts, invisible to the preload scanner — Document Parsing
ReliabilityTheir outage is your outage, if loaded synchronously

The main thread cost is the one that shows up as a metric. A tag that adds 180ms of execution adds it to every interaction competing for the thread, which is exactly what Interaction to Next Paint measures.

In plain terms: a 40KB tag doesn’t cost you 40KB. It costs a connection setup, its own execution, whatever it loads next, and a share of every interaction for the rest of the session.

Auditing them

The audit is straightforward and almost nobody has done it.

1  DevTools → Network, filter by domain ≠ your own
   list every origin, its bytes, and what loaded it

2  Performance panel → Bottom-Up, group by URL
   which third parties own the most main-thread time

3  Lighthouse → "Reduce the impact of third-party code"
   ranks them by blocking time

4  For each: who owns it? what decision does it inform?
   when was it last looked at?

Question four is the one that removes things. Most sites carry tags for tools nobody uses any more, added for a campaign that ended, by someone who has left. See Guide - Auditing a Tracking Plan.

Containing them

In rough order of effectiveness:

  • Remove. Always try this first. The cheapest script is the absent one
  • Move server-side. One first-party call from your server to the vendor, no browser cost, no ad blocking, no CSP hole. The strongest fix and a real engineering investment — Server-Side Tag Management
  • Defer or lazy-load. Chat widgets, review carousels and anything below the fold can load on interaction or on idle. A chat widget that loads when the user clicks the chat bubble costs nothing until then
  • Load on consent only, which you may be required to do anyway — Consent Management
  • Facade pattern. Render a lightweight placeholder — a static image of the video player, a fake chat button — and load the real thing on click
  • Set a budget per third party and enforce it — Performance Budgets
  • Subresource Integrity where the vendor supports it, so a compromised CDN can’t silently change the file

The governance problem

The technical fixes are easy. The reason third parties accumulate is organisational: adding a tag takes minutes and requires no engineering approval, and removing one requires finding out who depends on it.

What actually works:

  • One owner per tag, recorded, with a review date
  • A quarterly audit where anything unowned is removed
  • A performance budget in CI that fails when third-party weight grows
  • A default answer of “server-side or not at all” for new vendors

Without those, container size only goes up — see Tag Manager Performance.

The security dimension

Worth stating separately because it’s usually absent from the performance conversation:

  • A compromised vendor CDN can inject anything into every page — this is how several large card-skimming attacks worked
  • Any tag can read form fields, including payment details on a page you thought was safe
  • Any tag can read localStorage, which is why session tokens don’t belong there — Client Storage
  • Content Security Policy is the containment mechanism, and it’s the thing tag managers make hardest to deploy

The blunt summary: every third-party script is a decision to trust that vendor with your customers’ sessions. That’s a reasonable decision for a few of them and an unexamined one for the twenty on a typical retail site.

Graph View

Backlinks