Add a third-party widget

Every third-party embed is a permanent dependency on somebody else’s uptime, performance and privacy practices, added in exchange for a feature. The install takes ten minutes; the consequences are ongoing, and the two that matter are measured here.

1. Establish what it is and where it goes. Which vendor, which pages, and whether it needs to load on every page or just one. “Site-wide” is the default the vendor’s instructions assume and is usually wrong — a booking widget belongs on the booking page.
2. Measure the page before it goes on. Performance baseline, so the cost of the embed is a number rather than an impression. Without this the answer to “did that slow us down” is permanently unavailable.
3. [manual] Install the embed. Following the vendor’s snippet, on the pages decided in step 1, deferred rather than blocking wherever the vendor allows it. Publish and purge.
4. Check it actually rendered. The embed health check is the point of this procedure: it finds the embed that occupies space and displays nothing — an empty iframe, a container the script never filled, a widget blocked by consent tooling. A silently blank embed is the standard failure and it looks like a design choice.
5. Re-measure and compare. Same page, same tool. A widget that costs a second of load time is a decision to take back to the client, not a fact to absorb quietly.
6. Verify presentation and links. Before/after check, link and image check, screenshots across devices. Third-party embeds are frequently fixed-width and are the most reliable way to give a responsive page a horizontal scrollbar on mobile.

The empty embed

An embed fails by rendering nothing, which on a page with generous whitespace is indistinguishable from an intentional gap. Nobody reports it, because nobody who did not install it knows it should be there. That is why step 4 is a check and not a look.