Auditing your third-party scripts

The scripts you did not write

A modern marketing site often loads more code from other companies than from its own team. Analytics, heatmaps, chat widgets, consent managers, advertising pixels, A/B testing tools, social embeds: each one was added for a good reason, by a different person, at a different time. Together they frequently account for most of the main thread's work during page load.

Build an inventory

Start by listing every third-party origin your pages contact. The network panel grouped by domain gives a quick picture. For each one, record:

• What it does and which team asked for it.
• How much it costs: bytes transferred and main-thread time.
• Whether anyone still uses it. A surprising number of tags belong to tools nobody has logged into for a year.

This list alone usually justifies removing two or three scripts outright.

Measure the real cost

Transfer size understates the impact of a script. What matters more is how long it runs on the main thread, because that time directly delays the page's response to taps and clicks. A 30 kilobyte script that runs 400 milliseconds of JavaScript is far more expensive than a 100 kilobyte image.

Profile the page on a mid-range phone with the script blocked, then again with it allowed. The difference is the true cost.

Load later, or not at all

For scripts that must stay, change when they load:

1. Defer anything that does not need to run before the page is interactive.
2. Load on interaction: a chat widget can wait until someone clicks the chat button, with a lightweight placeholder until then.
3. Load on idle: analytics can initialize after the main content has rendered.
4. Move to the server: some tracking can be sent from your backend rather than the browser.

Use facades for embeds

An embedded video player can load hundreds of kilobytes before anyone presses play. A facade shows a static thumbnail with a play button and loads the real player only when clicked. The visual result is identical and the cost is nearly zero for visitors who never watch.

Govern new additions

The audit is only half the work. Without a process, the same scripts creep back. Require that every new third-party tag has an owner, a stated purpose, and an expiry date when it will be reviewed. Put tag changes through the same review as code changes.

Results to expect

Teams that do this audit for the first time commonly reduce main-thread blocking time by a third and remove several hundred kilobytes of JavaScript, without losing any capability anyone actually relies on.