How a 1KB Analytics Script Keeps Your Site Fast
I ran a Lighthouse audit on a client’s blog last year. Performance score: 74. The biggest offender? Google Analytics. Not the images, not the fonts, not the CSS — the analytics script.
Removed GA, added a lightweight alternative. Score jumped to 89. Same content, same hosting, same everything else. That’s when I started paying attention to what analytics scripts actually cost.
The weight of “just one more script”
Here’s what the major analytics tools add to each page load:
| Tool | Script size (gzipped) | Requests per pageview |
|---|---|---|
| Google Analytics (GA4) | ~45 KB | 3-5 |
| Matomo | ~25 KB | 2-3 |
| Plausible | ~1.5 KB | 1 |
| Fathom | ~2 KB | 1 |
| HushStats | <1 KB | 1 |
GA4 isn’t just one file. The main gtag.js loads, then it fetches a configuration payload, then it fires tracking requests. Depending on what you’ve enabled, the total transfer can exceed 100KB. On every single page load.
45KB of JavaScript doesn’t sound like much. But JavaScript isn’t like images — it has to be downloaded, parsed, compiled, and executed. That execution blocks the main thread, which delays interactivity. On a fast laptop with fiber internet, nobody notices. On a $150 Android phone on a 3G connection — which describes a significant and growing chunk of the world’s internet users — it’s the difference between your page feeling snappy and feeling sluggish.
The SEO angle nobody talks about
Google uses Core Web Vitals as a ranking factor. The metrics — Largest Contentful Paint, First Input Delay, Cumulative Layout Shift — are all affected by JavaScript execution. There’s an irony in using Google’s analytics product to hurt your ranking in Google’s search engine, but here we are.
A lighter analytics script won’t magically fix a slow site. But if your Lighthouse audit already flags “Reduce unused JavaScript” or “Minimize main-thread work,” trimming 45KB of analytics payload is one of the easiest wins available.
How we keep HushStats under 1KB
It wasn’t hard, honestly. Most of GA’s size comes from features we deliberately don’t have.
The script is vanilla JavaScript — no frameworks, no dependencies, no polyfills. It collects page URL, referrer, browser, device type, and screen size. That’s a small amount of data, so it’s a small amount of code.
Each pageview fires one GET request. The response is a 43-byte transparent GIF. No follow-up requests, no configuration fetches, no event queues, no retry logic.
No cookies means no cookie management code. Reading, writing, expiring, and syncing cookies across subdomains is a surprising amount of an analytics library’s codebase. We skip the whole thing.
The defer attribute on the script tag means the browser downloads it in parallel with HTML parsing and executes it after the document is fully parsed. Your page renders first, analytics run after. Visitors see content immediately.
Edge delivery matters too
File size is half the story. Where that file comes from is the other half.
We serve our tracking script from a global edge network — over 300 points of presence worldwide. A visitor in Jakarta gets the script from a server in Jakarta. A visitor in Buenos Aires gets it from Buenos Aires. Sub-50ms response times, consistently, everywhere.
Contrast this with analytics tools hosted on a single server cluster in, say, Germany. Great for European visitors. Not as great for someone in New Zealand waiting for a round trip to Frankfurt.
Try it yourself
This is easy to test: run a Lighthouse audit with your current analytics installed, note the score, swap in a lightweight alternative, and run it again. Most sites see a 3-10 point bump in Performance. On mobile, often more.
Your analytics script runs on every page, for every visitor, on every visit. A 45KB script on a site with 100K monthly pageviews transfers over 50GB of analytics JavaScript per year. A sub-1KB script transfers about 1GB. That’s bandwidth your visitors are paying for — on something they’ll never see or benefit from.
Worth thinking about.