As the engineer accountable for a site's speed, how would you decide which third-party vendors are worth their performance cost, and what would you do about the ones that are not?

## The failure this is meant to prevent Third-party scripts accumulate because each individual decision is cheap and locally reasonable, while the cost is shared, delayed and owned by nobody. The engineer who objects has a Lighthouse score; the stakeholder who wants the tag has a business need. Scores lose that argument, and should. The job at this level is to make the two sides commensurable. ## Cost in comparable units Every vendor gets measured identically, so the table can be sorted: number of requests and distinct origins, transferred bytes, main-thread time on a mid-tier device, and the delta in the field metrics that matter when the vendor's origins are blocked and the same journey repeated. Measure at the 75th percentile on hardware and networks resembling your users', because third-party execution cost scales with CPU and the difference between a developer laptop and a mid-range phone is where these arguments are usually won or lost. Cost is not a single number per vendor either. Separate the load-time cost from the ongoing cost: a widget with a modest download that installs document-level listeners charges you on every interaction for the life of the session, which shows up in interaction latency rather than in load metrics. ## Value that is claimed versus value that is demonstrated Every vendor should have a named business owner and a sentence stating which decision or capability depends on it. That alone retires a meaningful fraction of an old inventory: campaigns that ended, tools that were replaced, experiments whose owner has left. For the rest, the honest instrument is a holdback. Withhold the vendor from a slice of traffic, run it long enough to be statistically meaningful, and compare the business metric its owner cites. This is the move that changes the conversation, because it puts the burden of proof on the claim rather than on the objection, and because vendors often fail it: the chat widget that supposedly drives conversion, the personalisation tool whose lift disappears under scrutiny, the third analytics package measuring what two others already measure. A holdback also measures the other direction: run it and you learn what the page is worth without the vendor, in the same metrics you already report. ## Sorting by tier, not by argument Once cost and value are on the table, the decisions become mechanical: - **Essential to function** (payments, consent management, fraud, authentication): load early, keep them small, self-host or move first-party where the vendor permits, and hold them to the tightest availability requirements because they can break the page. - **Measurement**: prefer one implementation over four. Move to server-side collection where the vendor supports it so the device stops paying for each SDK, and sample where full fidelity is not needed. - **Engagement widgets** (chat, video, maps, social): facades and load-on-intent by default, because engagement rates are low and the cost per view is high. - **Unowned or unproven**: remove. Removal is a real option and should be exercised regularly enough that people expect it. ## Making the decision stick Governance decays unless it is enforced and monitored. Admission should be a reviewed change, with a Content Security Policy script-source allowlist making it technically true that an unapproved origin cannot run: the policy then doubles as an always-current inventory. Monitoring should watch third-party requests, bytes and long-frame attribution grouped by origin in real-user data, with an alert on a new origin, because vendors change their payloads without any deploy of yours and a periodic audit is stale the day after it is written. And there should be a standing review, quarterly or so, that re-asks the ownership question, since the inventory regrows to its old size within a year otherwise. ## The organisational half The technically correct programme fails if it is delivered as engineering vetoing marketing. What works is offering something in exchange: a fast, reliable path to add a vendor when it is justified, help with server-side collection so their data quality survives, and honest evidence when a holdback shows the vendor really does pay for itself, in which case you keep it and say so. Credibility earned by keeping a proven vendor is what makes the removal of an unproven one uncontroversial. The answer an interviewer is listening for is not zero third parties. It is that you can price them, prove their value, contain the ones you keep, and run a process that keeps the total from drifting.