Every embed hands your visitor to somebody else

What an embed actually does

It tells your visitor's browser to fetch something from another company's servers. That company receives the request, learns which page it came from, and can set a cookie.

From the visitor's point of view they visited your site. In practice they visited yours and several others at the same time.

That is why an embed is a privacy decision, not just a design one.

It is also a decision the visitor never made. They chose to visit your page; the connection to three other companies came with it, and only you can tell them that in your policy.

The usual suspects

An embedded map. A video player. Web fonts loaded from a font service. A chat widget. A social feed. A booking tool. A review badge.

Most sites carry several, added over years, each for a reason that made sense at the time.

Almost nobody removes them when the reason goes away, so they accumulate.

What they cost besides privacy

Speed, mostly. Each one is a new connection and a download the browser has to make before the page settles.

They also break in ways you cannot fix. When the other company has an outage, your page has an outage, and you have no way to repair it.

And they are outside your accessibility work. A chat widget that traps the keyboard is still trapping visitors on your site.

They also fail independently of you. When the other company has an outage your page has an outage, and there is nothing in your own code to fix.

Cheaper replacements

A static map image with a link to directions, instead of a live map. A video thumbnail that links out, instead of an embedded player.

Fonts served from your own site instead of a font service. A phone number and a form instead of a chat box nobody is watching after five.

Each swap removes a third party, a cookie and a delay, and most visitors never notice the difference.

• A static map image with a link to directions, instead of a live map
• A video thumbnail that links out, instead of an embedded player
• Fonts served from your own domain instead of a font service
• A phone number and a form instead of an unattended chat box
• A link to your profile instead of an embedded social feed
• A plain text quote instead of a review widget

Working out what you load

Open your page in a browser and look at the network panel in the developer tools. Every request is listed with its destination.

Anything not on your own domain is a third party. Write the list down. It is usually longer than expected and the first pass is the shocking one.

A free check will also report the third parties a page pulls in, along with what they cost in load time.

The list is usually longer than expected, and the first pass is the one that changes minds. It is the same inventory described in what your website collects.

Deciding what stays

For each item ask what it does for a customer, and what it would cost to replace with something static.

Keep the ones that genuinely earn their place, such as a booking tool your business runs on. Remove the ones added for a campaign that ended.

Name the survivors in your privacy policy, because a visitor cannot judge what they agreed to if the page never says who is involved.

What our pages ship with

The default is nothing added to a visitor's browser. Pages here are written from a conversation about your business, and anything you embed is a decision you make knowingly rather than a default you inherit.

Every page passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards. A third party script runs outside that check, which is itself a reason to keep the list short.

Nothing here is legal advice. Fewer moving parts is simply easier to explain and easier to keep working.

Fewer moving parts is also measurably faster, which is the argument made from the performance side in page speed and search.