Third-Party Weight Budget

A team enforces a 300 KB limit on its main bundle in CI, passes every build for a year, and the median page in the field ships 2.8 MB of JavaScript with interaction latency doubled. The budget was not wrong; it was measuring the artefact the build produces, while the page loads code the build never sees.

Everything in that gap is unbudgeted by construction: tag managers, which are loaders for scripts chosen later by people outside engineering; analytics, session replay, consent, experimentation, chat, fraud and advertising scripts; and third parties that load their own third parties.

A third-party weight budget names that category and constrains it in three dimensions: how many, how many bytes, and how much main-thread time. The third is the one that hurts, because bytes are only a proxy: a payload must be parsed, compiled and executed, and on a mid-range phone that work is three to five times slower than on the developer's machine.

Why it matters

Third-party scripts are the only part of the page with no owner inside the engineering process. They are added by marketing, analytics, legal and security teams through interfaces designed to avoid a deployment, which is exactly why they escape every gate the deployment has. The result is the most common shape of front-end performance decay: a site that gets slower without any commit explaining it.

They are also the category with the worst failure behaviour. A first-party regression is caught by a test; a third party can change its own payload overnight, block the main thread for 400 ms, or fail to load and hold a synchronous document write. You have accepted a dependency you cannot version, test or roll back.

Implementation patterns

• Measure the assembled page, not the bundle. A synthetic run of the real page with the real tags, throttled to a named device and network profile, asserting total transferred bytes, script execution time and the field metrics. This is the check that fails where the bundle check passes.
• Attribute cost per origin. A table of third-party origins with bytes and main-thread milliseconds each, generated per release, because the conversation with a tag's owner is only possible once its cost has a number.
• An enforcement point, not a document. A content security policy listing permitted script origins makes adding a tag a change with a review. Tag managers must be inside that control, or the policy has a hole shaped like every future tag.
• A named owner with a standing allowance, which converts an unbounded queue of requests into a trade: a new tag means reducing another.
• Load third parties after interactivity, in a container the framework does not own, so they cannot mutate the DOM before hydration or block the first interaction.
• An inventory review each quarter. The first one reliably finds two or three scripts nobody can justify, and removing them beats constraining what remains.

Industry example

Public web-performance research has for years put third-party code at a large share of the median page's JavaScript, and the mechanism is the same everywhere: a tag manager added once, then used as a delivery channel for scripts chosen without engineering review. Performance-programme write-ups report the same conclusion — the largest single win is usually removing a third party rather than optimising first-party code.

The security consequence is documented in enforcement. When the ICO fined British Airways 20 million pounds in October 2020 over its 2018 breach, the mechanism was a modified third-party script on payment pages exfiltrating card details from more than 400,000 customers. The scripts that are a performance problem are the attack surface, which is why the budget and the content security policy are one piece of work.

Failure scenarios

• A green build and a slower site for a year, with no commit to blame.
• A vendor's overnight change doubling execution time, unnoticed because nothing watches per-origin cost.
• A tag manager used as an unreviewed deployment channel, so production JavaScript is edited outside the engineering process.
• A third party mutating the DOM before hydration or blocking the main thread during it, which surfaces as a framework problem.

Trade-offs

The honest constraint is that consent management and some fraud and accessibility overlays must run early to do their job, so the budget needs a small explicitly-approved early tier rather than a blanket rule.

When not to use it

A site with no third-party scripts needs none of this, and a site with two stable tags does not need a governance process — a lab check on the assembled page is enough. The full apparatus earns its cost when non-engineering teams can add scripts to production, which is the condition that creates the problem. It is also the wrong first move on a site whose performance issue is a 3 MB first-party bundle: measure first, fix the larger cause, and do not spend the political capital of a third-party budget on the smaller half of the problem.

Interview question

Q: Your CI performance budget has passed every build for a year and the site is measurably slower. Explain how, and design what you would put in its place.

What a strong answer covers: that the budget measures the build artefact while the page loads runtime-injected code; that bytes are a proxy for main-thread time and the two diverge threefold on a phone; the three-level replacement of field metrics, a lab check on the assembled page and a third-party allowance; an enforcement point that includes the tag manager; and the observation that the finding is organisational, since the scripts came from people the budget did not apply to.

Quick check

Quiz: Why does a bundle-size budget not constrain a tag manager? Because the tag manager is a loader: its own payload is small, and the scripts it fetches at runtime are never part of the build the budget inspects.

Flashcard: Which three dimensions should a third-party budget constrain? — Count of origins, transferred bytes, and main-thread execution time, with the last being the one that determines whether the page feels slow.