Every analytics tool asks you to add a script to every page of your site. That script has a cost: bytes to download, JavaScript to parse and run, and sometimes extra requests to other domains. For most sites the cost is small. For some it isn’t, and it’s worth knowing which kind of site you have.
This article covers what that cost actually is, how the popular tools compare, and how to load any tracker so it stays out of your visitors’ way.
What an analytics script costs
Four things, roughly in order of how much they matter for user experience:
- Main-thread time. Browsers run JavaScript on the same thread that handles taps and clicks. A large script that runs a lot of code at startup can delay the page’s response to the first interaction, which shows up in Core Web Vitals as Interaction to Next Paint (INP).
- Download size. Bytes compete with your images, fonts and your own code for bandwidth, most noticeably on slow mobile connections.
- Extra connections. A script hosted on another domain needs a DNS lookup and a TLS connection before it can download. Tag managers can pull in further scripts from more domains.
- Blocking. A script loaded without
asyncordeferin the<head>blocks rendering until it has downloaded and run. This is the one that really hurts, and it’s entirely avoidable.
How the popular tools compare
Sizes below are approximate transfer sizes (compressed) for the default tracking script. They change as vendors ship updates, and what you actually load depends on your configuration, so treat them as orders of magnitude rather than exact numbers. Where we couldn’t verify a figure from the vendor, we say so.
| Tool | Approximate script size | Notes |
|---|---|---|
| Google Analytics 4 (gtag.js) | Around 100 KB or more | Plausible’s comparison cites roughly 135 KB. Google Tag Manager containers add more on top, depending on the tags inside. |
| Plausible | Under 1 KB to a few KB | Plausible advertises its script as lightweight, around 2.5 KB in recent materials. |
| Fathom | A few KB | Small; exact current size not verified. |
| Umami | A few KB | Small; exact current size not verified. |
| Cool Analytics | About 3 KB | Measured at about 2.7 KB gzipped, loaded with defer. |
| Product analytics suites (PostHog, Mixpanel and similar) | Tens of KB or more | They do much more (session replay, feature flags, surveys), so they ship more code. Many load features on demand. |
The gap between a tag-manager-plus-GA4 setup and a minimal tracker is often 30–50x in bytes. On a fast laptop that’s barely noticeable. On a mid-range Android phone on a patchy connection, a hundred-plus kilobytes of JavaScript that has to be parsed and run is a real cost, especially if it’s competing with your own code during startup.
So does Google Analytics slow down your site?
Honestly: usually only a little, if it’s loaded correctly. The gtag snippet loads asynchronously, so it doesn’t block the first render. The cost shows up as main-thread work and bandwidth competing with your own resources, and in practice most of the damage comes from what gets added around it: a tag manager with a dozen marketing pixels, a consent management platform, chat widgets, heatmap tools. Each one is “just one more script”.
If you care about Core Web Vitals, measure rather than guess:
- Run Lighthouse or PageSpeed Insights on a key page and look at “Reduce the impact of third-party code”.
- In Chrome DevTools, open the Performance panel, record a page load with CPU throttling, and look at how long third-party scripts run.
- Temporarily block a script (DevTools → Network → right-click → Block request URL) and compare.
How to load any analytics script well
Always use defer or async
defer downloads the script in parallel and runs it after the HTML is parsed, in order. async runs it as soon as it arrives. For analytics, either is fine; defer is the gentler choice.
<script defer src="https://coolanalytics.dev/hb.js" data-site="YOUR_SITE_ID"></script>In Next.js, use next/script
The Script component lets you choose when a script loads. afterInteractive (the default) is right for analytics: it loads after the page becomes interactive. Our Next.js guide has the exact code.
Don’t stack overlapping tools
It’s common to find GA4, a second analytics tool, two ad pixels and a heatmap tool all measuring roughly the same visits. Audit once a year. Every tool you remove is a free performance win.
Be careful with tag managers
Tag managers make it easy for anyone to add scripts without a code review. That’s their point, and also their risk. If you use one, review the container regularly and remove tags nobody owns.
Preconnect only if you need to
A <link rel="preconnect"> to your analytics domain can shave a little time off the request, but it also competes with more important connections early on. For a deferred analytics script it’s usually not worth it.
Size isn’t everything
A tiny script is a nice property, but it’s not the reason to choose an analytics tool. Choose based on whether it answers your questions, how it handles privacy and consent, and what it costs. Then, among the tools that fit, prefer the one that stays out of your visitors’ way.
If you’re comparing options, our comparison with Google Analytics covers features and privacy alongside performance, and the pricing comparison covers cost.
Quick checklist
- Every analytics script loads with
deferorasync. - You know how many third-party scripts load on your key pages, and who owns each one.
- You’ve checked third-party impact in Lighthouse on a throttled mobile profile.
- You don’t run two tools that answer the same question.