Provenance notice: this repository does not establish an independently verified incident source or measurement dataset for this case. Treat its organizations, events and numerical outcomes as illustrative teaching material until a maintainer supplies provenance. They are not measurements from the new executable labs.
Case Study: Third-Party Script Performance Incident
Incident summary
A marketing team added personalization and analytics through a tag manager. Desktop conversion looked better in a small experiment, but mobile paid traffic saw worse LCP, poor INP on the lead form, and higher abandonment.
The incident exposed a governance failure: a browser dependency was added outside normal frontend review.
Timeline
| Time | Event |
|---|---|
| Day 0 | Marketing adds personalization vendor through tag manager. |
| Day 1 | Desktop experiment dashboard shows conversion lift. |
| Day 3 | Paid mobile campaign begins. |
| Day 4 | Lead form abandonment rises for mobile users. |
| Day 5 | RUM shows LCP and INP regression isolated to campaign routes. |
| Day 5 | Engineers discover vendor script injects DOM above form and adds heavy input listeners. |
| Day 6 | Script disabled manually; metrics recover. |
| Week 2 | Third-party register, route budgets, and tag-manager review policy adopted. |
Production signals
- mobile p75 LCP worsened on campaign landing route
- p75 INP worsened on form input
- conversion lift disappeared after segmenting by mobile paid traffic
- CLS increased when personalization injected content above the form
- no owner could explain the script's data access or kill switch
Root cause
The script was treated as a marketing configuration change instead of a production dependency. No route budget, data-access review, owner, consent behavior, or kill switch existed.
Architecture failures
- tag manager bypassed frontend review
- experiment success ignored Web Vitals guardrails
- vendor script loaded before first useful content
- injected DOM changed layout after render
- event handlers ran on every input
- no third-party script register existed
- no tested kill switch existed
Bad alternatives
| Alternative | Why it was wrong |
|---|---|
| Ban all marketing scripts | ignores valid business needs and creates shadow work |
| Keep script because conversion improved on desktop | sacrifices important cohort and hides segment harm |
| Ask vendor to optimize later while staying live | leaves active user harm in production |
| Move tag manager ownership entirely to marketing | separates business owner from runtime accountability |
Corrected architecture
| Control | Practice |
|---|---|
| Third-party register | owner, purpose, data access, consent, routes, budget, kill switch |
| Loading policy | critical path denies nonessential scripts before first useful content |
| Experiment policy | conversion and Web Vitals reviewed together |
| Consent/privacy | destination routing and data minimization are explicit |
| Monitoring | Web Vitals segmented by route, campaign, device, release, and variant |
Corrected script lifecycle
Prevention controls
- tag-manager changes require engineering-reviewed register entry
- every third-party script has route allowlist and denylist
- marketing experiments include Web Vitals guardrails
- route budgets include third-party transfer and main-thread cost
- kill switches are tested before launch
- session replay/analytics/attribution have consent-aware loading policy
Review questions
- What does this script read, write, inject, or observe?
- Does it run before the primary content or interaction?
- Which routes deny it by default?
- Who can disable it during an incident?
- How are conversion and Web Vitals evaluated together?
Reusable lesson
A script loaded outside the repo is still frontend architecture. If it can affect DOM, network, storage, event handlers, privacy, or main-thread work, it needs ownership and review.
Source lens
Use Part VI performance budgets, Part VIII privacy/measurement, the client-side security/privacy review packet, and the performance-critical lead funnel capstone.