Estimating tracking payload: how many kilobytes the tags cost

The check downloads up to six known tracking scripts itself and sums their size. Over 100 KB is "to review", over 200 KB critical.

What we check

In the HTML: the scan looks for the loaders of seven known trackers, gtm.js, gtag.js, Meta fbevents.js, Hotjar, LinkedIn Insight, Microsoft Clarity and HubSpot, downloads up to six of them itself (three-second limit each) and adds up their size. Up to 100 KB means "ok", up to 200 KB "to review", above that critical. If it finds no known loader, the line is a note: nothing to measure. The figure is an estimate, and the line says so.

What the scan cannot see: everything the container loads afterwards, meaning the actual tags in the tag manager, plus chat widgets, A/B tests and embeds. It measures transfer size or raw size, depending on what the server reports, and never the compute time a script costs in the browser.

Why it matters

Tracking scripts run on every page, for every visitor, before any content. A container with 60 tags can cost more time on a mid-range Android device than rendering the page itself. And the load is only the visible symptom. Behind 200 KB of tracking there are usually three tools measuring the same thing, session recording on pages nobody analyses, and a container nobody has tidied in three agencies. Each of those scripts is also an entry in the privacy policy that someone has to maintain.

Common causes

Several analytics tools measure the same thing in parallel, GA4 plus heatmap plus session recording plus product analytics.
Tag manager containers grew for years, nobody ever deleted a tag.
Session recording tools load on every page although only the checkout was meant to be studied.
Consent, chat, and personalisation widgets each bring their own library along.

The fix

A script audit with three columns: tag, user of the data, last access to the report. Whatever fills no column goes. Reduce duplicate measurement to one tool, limit session recording to the pages under study, everything else into a container with consent triggers. Then measure the actual load in the network tab, not the scan's estimate. If you run many pixels, look at the server container: what gets forwarded server-side, the browser no longer has to load.

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

The scan reports 40 KB, Lighthouse counts 600 KB of third-party. Who is right?

Both, they measure different things. The scan only downloads the loaders of the known trackers from the HTML, six at most, and adds up their size. What the tag manager loads afterwards, pixels, heatmaps, session recording, it does not see. Lighthouse counts everything that arrives in the browser. The scan gives a lower bound; the real load is in the network tab.

Why is a kilobyte figure critical at all?

Because over 200 KB of tracking scripts rarely come from one tool. Usually it is three tools measuring the same thing, plus a container nobody has ever deleted a tag from. The figure itself slows less than what it signals: every one of those scripts runs on every page, for every visitor, with or without consent.

How do we cut the payload without losing measurement?

Take inventory: which tags fire, who uses the data, when was the report last opened. Switch off duplicate tools, limit session recording to the pages someone is studying, and move the rest into a container with consent triggers. A server container takes further work off the browser, because many pixels then no longer need to run in the client at all.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint