On a site where a marketing team publishes tags through a tag-manager container, page weight and main-thread time keep growing in weeks when the frontend team ships nothing at all. Why is that cost so hard to control, and what would you put in place?

## Why this is a governance problem wearing a performance costume A tag manager exists so that non-engineers can change what runs on the site without waiting for a release. That is genuinely valuable, and it is also precisely the property that makes the cost hard to control: the container is a second production deploy channel with different reviewers, different tooling and, usually, no performance gate at all. The practical consequences follow directly: - **Your build cannot see it.** Bundle analysis and CI size checks examine what the bundler produced. A tag published this morning is fetched at runtime and appears in none of that. Green checks and a heavier page are perfectly consistent. - **One tag becomes several vendors.** A published tag frequently loads code from further origins, so approving one relationship silently admits others, each with its own connection setup and its own main-thread work. - **Nobody owns the total.** Individual tags are each defensible; the sum is what hurts, and no single publisher sees the sum. - **Free-form tags can be pathological.** Containers usually allow custom HTML tags containing arbitrary markup and script. Careless ones inject synchronous work, poll on timers, or write into the document in ways that block rendering. - **The cost is only visible in the field.** Since the container's contents can differ by page, by audience segment and by trigger, a single lab run under-reports it. Real-user data is where the growth shows. ## What actually works **Inventory with ownership.** Enumerate every tag in the container and attach three facts to each: what business question it answers, which named person or team depends on it, and when it is next reviewed. Tags that fail to acquire an owner are removed at the next review, and in practice a first pass over an old container removes a substantial share of tags: campaigns that ended, vendors that were replaced, experiments that concluded. **Access and approval.** Publishing to production should require review the same way a code change does. Restrict publish rights, use the container's workspace and approval flow, and prefer vetted templates over free-form custom HTML so that what a tag may do is bounded. **Technical enforcement.** Governance that relies on people remembering decays. A Content Security Policy with an explicit `script-src` allowlist converts the vendor list into something the browser enforces: an unapproved origin cannot execute, and the violation reports tell you who tried. It doubles as an always-accurate inventory of who is allowed on your pages. **Load timing.** Decide deliberately when the container and its tags load rather than defaulting to the head of every page. Consent gating already forces this for a large class of marketing tags, since they must not run before the visitor agrees. Beyond that, load non-essential tags after the page is interactive or during idle time, and use facades for widgets that inject UI. Expect pushback, because deferring a measurement tag genuinely costs some data fidelity; that is a negotiation to have with numbers, not a decision to make unilaterally. **Move measurement off the client.** Where the vendor supports it, server-side tagging replaces several browser-executed vendor scripts with one first-party request that your server forwards. The user's device stops paying for each vendor's SDK. It costs infrastructure and it does not fit every vendor, but for a sprawling container it is often the largest single win available. **Continuous monitoring.** Track third-party requests, bytes and long-frame attribution grouped by origin in your real-user monitoring, and alert on a new origin or a growing one. Because the container changes without a deploy, a periodic audit is always out of date; a monitor is not. ## How to frame it with the other team The failure mode of this conversation is engineering demanding the container be shut off, and marketing hearing that their measurement is being taken away. The version that works starts from shared numbers: here is what each tag costs in requests, bytes and main-thread milliseconds; here is what the page gains when a given tag is absent, from a holdback; here is the subset we propose to defer, move server-side or retire, and here is what you lose in each case. Then agree a standing review so the list does not regrow to the same size in six months.