During a vendor outage, pages on your site stayed blank for twenty seconds; the vendor's tag is fetched from their domain by a plain <script> tag in the page's <head>. Why did a third-party script have that power over your page, and what containment would you put in place?

## What went wrong A render-gating third-party script hands three of your properties to another company: your availability, your latency and your ability to change. If their host is unreachable, the browser's behaviour is not to skip the resource — it waits for the network stack to give up, and connection timeouts are measured in tens of seconds. Your users see nothing during that time, so from their point of view your site is down. Nobody signed off on that risk; it arrived attached to a snippet a vendor supplied with the instruction to paste it into the head. The same dependency exists in a milder, permanent form: even when the vendor is healthy, every visitor pays their DNS lookup, connection setup and response time before your content can appear, on the worst networks and the oldest devices too. ## The first containment: keep them off the critical path The default rule for third-party code is that nothing it does may stand between the user and the first render. That means non-blocking loading at minimum, and for most tags something later still — after the page is usable, or at the moment the user engages with the feature that needs it. Vendor code deserves the last position in the queue, because the page is yours and their measurement or widget is not what the visitor came for. This single rule downgrades an outage from "our site is down" to "a widget is missing", which is the outcome you actually want. ## The second containment: bound anything that gates content Some vendor products legitimately need to run before content is visible — personalisation and experimentation tools are the honest examples, since showing the control variant and then swapping it produces a visible flicker. The containment for those is a cap, not an exemption: a timeout after which the page renders its default content regardless, and a defined behaviour for what the user sees if the vendor never answers. Mature vendors in this category document a timeout setting precisely because they know the risk they represent. If a vendor tells you their product only works if it can block rendering indefinitely, that is a product decision to escalate with the cost quantified, not a technical constraint to accept. ## The third containment: isolation When a widget needs to display something but does not need access to your page, put it in an iframe. The frame's loading, layout and script execution are its own; a slow or broken vendor degrades a rectangle rather than a document. Sandboxing the frame narrows what its code may do at all. The cost is that communication becomes explicit message passing and that a frame has its own overhead, so this suits heavyweight embeds better than a two-line measurement tag. For tags that mostly do bookkeeping rather than user interface, another option is moving their execution off the main thread — tooling such as Partytown exists specifically to run third-party scripts in a worker with proxied access to page APIs. It removes their main-thread cost, at the price of a proxy layer that some vendor scripts do not tolerate, so it needs testing per tag. ## The fourth containment: self-hosting, with eyes open Serving a vendor's file from your own origin removes their outage from your load path, removes an extra connection, and lets you cache it on your own terms. It also makes you responsible: you now own updating that file, and when the vendor changes their service the pinned copy you froze may break or silently stop reporting. Some licences forbid it outright, and some tags are loaders that pull further code from the vendor anyway, which defeats the purpose. Self-host deliberately, with a stated update process and an owner — not because it made a graph look better once. ## Governance and visibility Containment that is not visible decays. Two habits keep it honest. First, record in field data how long third-party resources take for real users, so a vendor's slow week shows up as a graph rather than as a support ticket. Second, treat the tag manager itself as a component with the same risk profile: it is a convenient central control point, and it is also a place where new blocking dependencies can be introduced without a code review, so its container is worth a policy of its own. ## Saying it well in an interview Lead with the principle — a page's render must not depend on a party you do not operate — and then give the ladder: keep them off the critical path, cap what genuinely gates content, isolate heavyweight embeds, self-host where it is safe, and measure vendors in the field. Avoid two weak answers: "add async and it is fine" (which fixes the render dependency but not a widget the interface waits on, nor its main-thread cost) and "use a CDN" (which is not what this failure is about at all).