How Much Do Tracking Tags Slow Your Site? Estimate the Core Web Vitals Cost

Every tracking tag on a page is JavaScript someone else wrote, downloaded and executed on your user’s device before your page is fully interactive. Marketing asks for one more pixel; engineering knows each one costs bytes and main-thread time; nobody in the room has a number. Running a full Lighthouse audit for every “can we add Hotjar?” conversation is overkill — what you want first is an order-of-magnitude answer: roughly what does this stack of tags cost, and is it drifting into territory that threatens LCP or INP?

The free Tracking → Core Web Vitals Impact estimator gives you that answer two ways: tick the trackers a page loads and get catalog-based totals before you ship, or feed it a real page’s resources — a HAR file, performance.getEntriesByType('resource') JSON, or a plain URL list — and see which bytes belong to known trackers. It runs 100% client-side (nothing is uploaded, it works offline), and it is deliberately labeled BETA, estimates only: rough public order-of-magnitude figures and a documented heuristic, not a measurement.

What it does

The tool has two tabs:

• Estimate from tags. A checkbox grid of eight common trackers — Google Analytics 4 (gtag.js), Google Tag Manager, Meta Pixel, Hotjar, Microsoft Clarity, LinkedIn Insight Tag, TikTok Pixel, and Segment (analytics.js) — each shown with its approximate transfer weight and main-thread cost from a built-in catalog. Tick a stack and the totals update live: trackers selected, estimated KB of transfer added, estimated main-thread ms added, and a qualitative LCP/INP risk band.
• From a real page. Drop a .har export, paste resource-timing JSON, or paste one URL per line. The tool sums total transfer, script-only transfer, and estimated main-thread time, flags every resource whose URL matches a known tracker origin, and breaks out the tracker-only subset with its own risk band. A table lists every resource, sorted with tracker rows first and then by size, and you can export the tagged list as CSV.
• A one-click bookmarklet. “CWV resource grab” — drag it to your bookmarks bar, click it on any page, and it copies that page’s resource-timing entries as JSON to your clipboard, ready to paste into the tool. The bookmarklet source is displayed verbatim so you can read exactly what it does.

How it works

The engine (cwv.js) is pure logic with no dependencies and no DOM access, and every constant it uses is exposed so the UI can label it.

The main-thread heuristic. There is no way to measure real CPU time from a static resource list, so the engine uses one documented rule of thumb: roughly 1 ms of main-thread parse + compile + execute time per KB of script transferred (MS_PER_SCRIPT_KB = 1), framed for a mid-tier mobile CPU. Only script bytes count toward main-thread time — CSS, images, and fonts are summed into transfer weight but excluded from the ms estimate, because they don’t block the main thread the same way.

Risk bands. Estimated added main-thread ms maps onto three bands: under 50 ms is low, 50 ms up to 200 ms is moderate, and 200 ms or more is high. The thresholds are judgment calls anchored to public Core Web Vitals guidance — INP’s “good” ceiling is 200 ms and long tasks over 50 ms are the classic INP culprit, while LCP (good ≤ 2.5 s) is delayed by main-thread contention. The tool reports the same band for LCP and INP, since both are pressured by the same blocking work.

Input parsing. parseResources() accepts three shapes and normalizes them to {url, kb, type, isScript}: a HAR object (it walks log.entries, preferring the over-the-wire response._transferSize and falling back to content.size), a resource-timing array (preferring transferSize when it’s above zero — it can be 0 for cached or cross-origin entries — then encodedBodySize, then decodedBodySize), or a newline-separated URL list, which yields URLs with unknown sizes. A resource counts as script if its initiatorType is script, its MIME type matches JavaScript/ECMAScript (or JSON), or its URL ends in .js, .mjs, or .jsx before any query string or fragment.

Tracker fingerprinting. Each catalog vendor carries known host patterns — googletagmanager.com/gtag, connect.facebook.net, static.hotjar.com, clarity.ms, snap.licdn.com, analytics.tiktok.com, cdn.segment.com, and so on. Every resource URL is matched against that flattened host list, and hits are labeled with the vendor name and rolled into the tracker-only subtotal. It’s a best-effort substring match of the URL against known host patterns, not a full blocklist.

The catalog numbers. The per-vendor KB and ms figures are rough, public order-of-magnitude values that drift as vendors ship new script versions. They exist to make relative comparisons — is this stack twice the weight of that one? — not to be quoted as measurements.

How to use it

1. Open the CWV Impact estimator.
2. Before you ship a tag: on the “Estimate from tags” tab, tick the trackers the page will load. The three stat tiles (trackers selected, transfer added, main-thread added) and the LCP/INP risk sentence update as you click.
3. For a live page: switch to “From a real page”. Either drag the CWV resource grab bookmarklet to your bookmarks bar and click it on the page you’re auditing (it copies the resource JSON to your clipboard), export a .har from your browser’s Network panel and drop it on the drop zone, or paste URLs one per line. Then press Estimate impact (or Ctrl/Cmd+Enter).
4. Not sure of the format? Press Sample to load a six-resource demo page — gtag.js, the Meta Pixel, Hotjar, a first-party bundle, a stylesheet, and a hero image — and see how the output distinguishes tracker weight from the rest.
5. Read the summary line (“N resources · M matched a known tracker origin”), the five stat tiles, and the resource table, where tracker rows are listed first and tagged with a vendor chip. Press Export CSV to download the tagged list (url, type, kb, is_script, tracker).

Limitations

The tool is explicit about its bounds, and they’re worth restating:

• Estimates, not measurements. Catalog figures are ballpark public numbers that drift over time, and the ms figure comes from a single 1 ms/KB heuristic. Real cost varies widely with code shape, caching, and device. For a real number, run Lighthouse or WebPageTest on the actual page.
• Sizes depend on your input. A pasted URL list carries no byte counts, so those rows show 0 KB; resource-timing entries for cached or cross-origin (opaque) responses can report a transferSize of 0. HAR exports give the most complete picture.
• Tracker tagging is a host match, limited to the catalog’s known origins. Server-side or first-party-proxied tracking (see the server-side tracking guide) won’t match, and an unlisted vendor won’t be flagged.
• It says nothing about data collection. Weight is only half the story — the tool cannot tell you what those trackers collect or where they send it.
• Client-side and beta. Everything runs in your browser; nothing is sent anywhere. The BETA badge is on the page for a reason.

FAQ

Is this a Lighthouse alternative? No. Lighthouse loads and profiles the real page; this tool arithmetic-sums a catalog or a resource list you hand it. Use it for quick relative comparisons and pre-ship conversations, then confirm with a real lab or field measurement.

Where does the 1 ms per KB figure come from? It’s a documented rule of thumb for JavaScript parse + compile + execute cost per KB of transferred script on a mid-tier mobile CPU, and the tool exposes the constant on-page rather than hiding it. Modern flagship phones do better; cheap devices do worse — treat it as order-of-magnitude.

Why do LCP and INP get the same risk band? Because the estimator only knows one thing: added main-thread work. Blocking work delays LCP rendering and inflates INP interaction latency alike, so the tool maps the same ms total onto both labels (low under 50 ms, moderate from 50 ms, high from 200 ms) rather than pretending to separate them.

Does uploading a HAR send my data anywhere? No. The HAR is read with the browser’s FileReader API and parsed locally. The page sends nothing to any server, has no analytics, and works offline.

Can it tell me if a tag is worth the cost? It gives you the cost side of that ledger in comparable units. Whether the measurement value justifies it is a judgment call — the attribution fundamentals and GA4 guides cover what these tags actually buy you.

Related

• Tracking → CWV Impact estimator — run an estimate on your own tag stack or page right now.
• How web tracking works — what those scripts are doing once the bytes arrive.
• Google Tag Manager — the container most of these tags load through, plus the GTM Container Explorer to audit what’s inside yours.
• Server-side tracking — the main architectural lever for cutting client-side tag weight.
• Pixel Scanner and Cookie Scanner — find out which trackers a page runs before estimating what they cost, and browse vendors in the directory.
• The State of Web Tracking report — how heavy tracking stacks have become across the wider web. Same caveat applies there as here: the estimator gives you order-of-magnitude estimates, and only a real measurement of your page settles the question.
• This tool prices tracking in milliseconds; ad.rip audits what a live site’s trackers actually collect.