Static SignalStatic Signal
Signal vs Noise Web Performance Developer Experience (DX)

Why I Deleted Google Analytics

Static Signal
A vast dark steampunk surveillance chamber at night, towering brass observation racks holding hundreds of glass camera-eye lenses receding into atmospheric purple fog, most of the lenses now dim and dark with only a few still flickering faint teal; in the foreground a single solid copper workbench under a fading amber lamp where a heavy brass lever has been pulled all the way down to the OFF position, severed copper data cables hanging loose and unplugged from a tarnished switchboard, a small pile of inert glass eyes set aside beside the lever, reflective wet stone floor with circuit-pattern grouting glowing only faintly amber, cinematic shallow depth of field, moody editorial composition, no text, no people

I deleted Google Analytics from every site I run.

Not in protest, not because of a single dramatic incident, and not because I had a clever replacement that needed an excuse. I deleted it because I sat down one afternoon and tried to answer a simple question — what is this script actually doing for me? — and the honest answer was: very little, badly, while costing real money.

This is the version of that afternoon I now give to clients when they ask whether GA4 should be on the new site. The short answer is no. The long answer is below.

What I Was Actually Using It For

Before I argue against GA, I have to be honest about what I was using it for. On a typical content site, my actual questions were:

  • How many people came to the site this week?
  • Which posts are getting read?
  • Where are people coming from — search, social, direct, RSS?
  • Are people on phones or laptops?
  • Is anything obviously broken — a 404 spike, a sudden drop in traffic?

That is the entire list. I have never, on any site I personally operate, used a funnel report, a cohort retention curve, a custom event for “scroll depth over 50%,” or a calculated metric. Those features exist because GA is built for companies with a marketing team that lives in dashboards. I am not that company. Most of the sites I work on are not those companies either.

If the only questions you’re asking are the five above, you do not need GA. You may not need any JavaScript-based analytics at all. That realization is the whole post.

The Performance Tax

Let’s start with the cost, because the cost is more concrete than the benefits.

The current GA4 tag (gtag.js loading from googletagmanager.com) is about 90KB gzipped on first load, and pulls in a second script from google-analytics.com for the actual measurement protocol. On a content page with a budget of, say, 80KB of JavaScript total, that single decision more than doubles the JS payload.

But payload is the smaller half of the cost. The bigger half is what GA does after it loads. It registers event listeners, fires beacons on page transitions, batches events with sendBeacon, and on Chrome it does this on the main thread. Page Speed Insights will happily tell you that the largest contributor to your Total Blocking Time is gtag.js evaluating after your hero finishes painting. I have seen otherwise-clean static sites lose 8-15 Lighthouse performance points to GA alone.

On the server side, every pageview is a network request to Google’s infrastructure. On a mobile connection that adds 100-300ms of background activity competing with your actual page resources. None of that work is visible to the user — except in the form of a slightly slower site.

You can defer it. You can lazy-load it. You can put it behind a consent banner so it only loads for the fraction of users who click through. None of those are removing it. They are paying interest on a debt you took on without checking the rate.

The Data Quality Problem Nobody Talks About

Here is the part that most “should I use GA” debates skip: GA’s data is dramatically incomplete, and has been getting worse for years.

The compound effect of ad blockers, tracking-protection browsers, content-blocker extensions on iOS, and privacy-first browsers like Brave is that GA undercounts traffic by somewhere between 25% and 60%, depending on your audience. A developer-facing site is at the high end — I have run side-by-side comparisons between GA and server logs on dev tool sites where GA reported barely 40% of the actual sessions. A general consumer site is closer to 20-30% lost.

That gap is not random noise — it is systematic. Users with ad blockers are correlated with technical fluency, higher-income demographics, and certain operating systems. The slice GA does see is biased in ways that are not obvious from the dashboard. You are making decisions on filtered data without the filter being labeled.

Then there is GA4 itself, which sampling-by-default applies once you hit moderate traffic, runs through Google’s machine-learning “modeling” to guess at the events it didn’t actually see, and presents the result as if it were a count. If you have ever pulled the same report twice and gotten two different numbers, that’s why.

If the entire purpose of analytics is to count things, and the tool can no longer count reliably, the tool is failing at its job. You are still paying the performance tax. You are getting a confidently-wrong number in exchange.

The Privacy Problem That Won’t Go Away

GA4 is, in EU jurisdictions, a regulatory time bomb. Several national data-protection authorities — Austria, France, Italy, Denmark, Norway — have ruled at various points since 2022 that the standard GA implementation violates GDPR by transferring personal data (IP addresses, device fingerprints, cookie IDs) to a US-based controller without adequate safeguards. The legal terrain has shifted multiple times with each iteration of the EU-US data framework, and it will shift again.

The practical effect is that running GA on a public site in 2026 means either:

  • A cookie consent banner that lets users opt out, which means GA only sees the slice of users who clicked “Accept All” — usually 40-70% of EU traffic, further degrading data quality.
  • A server-side GA implementation that proxies events through your own domain to obscure the third-party transfer — which is technically a bigger lift than just running first-party analytics in the first place.
  • Hoping nobody complains.

None of those are good options. Each one is the kind of structural compromise that makes you wonder why this particular vendor is the one you’re contorting your stack around.

And separately from the legal angle, there is the plain ethical angle: Google is the largest advertising company in the world, and every site that runs GA is sending behavioral data to that company about every visitor. The user did not ask for that. They came to read your post. There is something quietly off about the default being “of course we send your reading habits to an ad broker.”

What You Get Without It

This is where most “delete GA” arguments get vague. Let me be specific. Here is what I run instead, in decreasing order of how much I personally rely on each one.

Self-hosted Plausible or Umami. A single small VPS — $5/month or free on Hetzner’s smallest tier — running Plausible Community Edition or Umami. Both ship a sub-1KB tracker script that runs first-party, doesn’t set cookies, doesn’t trigger GDPR consent requirements in most jurisdictions, and answers the five questions I actually ask. Plausible is more polished; Umami is more flexible. Pick one. Either is faster, smaller, and more accurate than GA.

<!-- Umami: this is the entire integration -->
<script defer src="https://umami.example.com/script.js" data-website-id="..."></script>

If you do not want to run a server, both are also available as hosted SaaS at $9-19/month — still cheaper than the engineer-hours you currently spend explaining GA’s weird numbers.

Server logs, via GoAccess. This is the no-JavaScript option. Every request to your site is already being logged by your CDN or your origin server. GoAccess takes that log file and produces an HTML dashboard with pageviews, top pages, referrers, devices, and bandwidth. Zero client-side code, zero privacy implications, and it counts everything — including the 25-60% of users that GA can’t see, plus RSS readers, feed aggregators, and AI crawlers.

goaccess /var/log/nginx/access.log -o report.html \
  --log-format=COMBINED --real-time-html

For a static site behind Cloudflare, you can do the same thing against Cloudflare’s log push to R2 — no origin needed. This is, weirdly, the most accurate analytics setup you can run, and it’s also the one with the lowest moving parts.

Cloudflare Web Analytics or Vercel Analytics. If you’re already on either platform’s free tier, both offer first-party, cookie-less analytics that meet the bar for the five questions. They’re not as feature-rich as Plausible, but they’re free, the script is tiny, and the privacy posture is reasonable. Worth turning on as a backstop.

Nothing. This is a real option and worth considering. The set of sites for which the correct number of analytics platforms is zero is larger than you’d think. A personal blog with a few hundred readers does not need to know that Tuesday’s post got 14% more clicks from Twitter than Wednesday’s. The dashboard is theater. Read the comments. Watch the RSS subscriber count. Ship the next post.

What You Lose

Honest accounting. Removing GA does cost you a few things, and you should know what they are before you do it.

Cross-domain attribution. If you run multiple properties and need to follow a single user across them, that’s harder without GA. None of the alternatives above stitch sessions across origins. For most content sites this doesn’t matter; for some businesses it does.

Integration with Google’s ad stack. If you run AdWords or Display Network campaigns, GA is how attribution flows back to those campaigns. There’s no clean substitute. If you’re spending real money on Google ads, the calculus changes — though even then, you can keep GA scoped to the landing pages that drive ad traffic and remove it from the rest of the site.

Years of historical data continuity. If you’ve had GA on your site for a decade, you’re throwing away a long time series. This one is mostly emotional — almost nobody actually queries year-over-year-over-year reports — but it’s real. Export what you care about before you uninstall, and accept that the new tool’s data starts at zero.

The “everyone uses it” defense. If your boss or your client asks “what does the analytics report look like” and you don’t have a familiar-looking dashboard to show them, that’s a meeting you’ll have to handle. Plausible and Umami both render dashboards that pass this bar; GoAccess and “nothing” do not. Choose accordingly.

That is the entire cost list. For most sites, all four items are negotiable.

How to Actually Rip It Out

I have done this on a dozen sites and the playbook is short.

Step 1: Export anything you can’t afford to lose. Pull a CSV of the last 12 months of top-pages and traffic-sources reports. That’s the only historical data anyone has ever asked me for in retrospect. The rest is dashboard fluff.

Step 2: Set up the replacement first. Stand up Plausible or Umami on a VPS. Add the tracker script to your site. Let it collect a week of data so you can sanity-check that your traffic matches your expectations before you remove the old tool. Having both run in parallel for seven days is the single thing that prevents “wait, where did my traffic go” panic.

Step 3: Remove the script. For a static site this is usually one line in a layout file. For a CMS, it might mean disabling a plugin or pulling a Tag Manager snippet. Search the codebase for gtag, googletagmanager, google-analytics, ga.js, and analytics.js — modern installations only use the first two but legacy code is everywhere.

Step 4: Remove the consent banner if GA was the only thing it gated. This is the underrated payoff. If you were running a cookie banner only because of GA, you may not need a banner at all anymore. Check your other third-party scripts — embedded YouTube videos, Stripe checkout, Intercom — but on a typical static content site, removing GA removes the banner.

Step 5: Update the privacy policy. Remove the GA section. Add a one-paragraph note about whatever you’re using instead. If you went with server logs only, the privacy policy gets shorter, which is usually a good sign.

Step 6: Re-run Lighthouse. This is the satisfying part. On a typical content site that was running GA, removing it bumps the Performance score by 5-15 points immediately, drops Total Blocking Time by 100-300ms, and shaves 80-120KB off first-load JavaScript. Take a screenshot before and after. It’s the cheapest perf win you will get all year.

The whole migration is usually an afternoon’s work, including the parallel-running week and the privacy-policy update.

The Question Behind the Question

The reason “should I use GA” is a contentious question is that it’s not really a technical question. It’s a question about what kind of operator you are. Are you the kind of operator who instruments first and asks what to do with the data later, or are you the kind who decides what you need to measure and instruments only that?

GA is the default for the first kind of operator. It collects everything, presents you with a dashboard full of metrics, and assumes you’ll eventually figure out which ones matter. For a company with a marketing team and a $50K/year budget for that team’s tooling, that’s a fine bet — they will figure it out, and the breadth is genuinely useful.

For everyone else — every solo developer, every freelancer’s client site, every content blog, every internal tool, every documentation site — that breadth is dead weight. You’re paying for a dashboard you don’t read in a tool that can’t see most of your users, hosted by an ad broker, slowing down your site, all to find out which of last month’s posts got the most pageviews. Which you could have found out by looking at your server logs in four seconds.

The decision to delete GA is, ultimately, the decision to stop instrumenting things you aren’t actually using. It is the same decision as auditing your dependency list, killing the dark-mode flash, dropping the headless CMS you don’t need. It is the static-first instinct applied to one more layer of the stack.

If your honest answer to “what would I do with this report” is “I’d glance at it once a week,” then you don’t need the most invasive analytics platform on the internet. You need a number, and you can get that number without sending your readers’ behavior to an ad company.

Delete it. The site will be faster, the privacy policy will be shorter, and the dashboard you actually look at will be the one that tells you the truth.