Lightweight WordPress Analytics: I Measured Them All

I downloaded eight WordPress analytics tools and weighed every byte. Tracker scripts, plugin archives, the works. Before I tell you which one is "lightest," here is what I found.

The smallest tracker belongs to Plausible, not Clickport. The smallest plugin belongs to Koko Analytics. The single heaviest plugin, by a long way, is MonsterInsights at 27.8 megabytes. The single heaviest script is the one Google itself ships: gtag.js at 139 KB gzipped, roughly a hundred times the size of any privacy-first analytics tracker.

If you have ever searched for "lightweight WordPress analytics," you have seen the same five vendors claim the title. Koko says 500 bytes. Fathom says 2 KB. Independent Analytics says 2 KB inlined. We at Clickport could say 2.8 KB. They are all measuring the same thing: the JavaScript that hits your visitor's browser. Nobody measures the plugin code your server loads on every request. Nobody measures the database writes happening on every pageview. Nobody measures the admin dashboard queries that fire when you open your stats.

This article does all of that. I will show you the numbers, then I will tell you what "lightweight" actually means once you account for the parts you cannot see from the outside.

A disclosure before we start: I run Clickport, so I am not pretending to be a neutral reviewer. But the numbers below are public, downloadable, and reproducible, and where another tool beats Clickport on a specific metric, I will say so. Plausible has a smaller tracker than ours. Koko has a much smaller plugin than a hypothetical Clickport plugin would be. Fathom compresses better. The honest comparison is the one worth writing.

What does "lightweight" actually mean for WordPress analytics?

The word gets used three different ways, sometimes in the same sentence.

The first is tracker bytes: the JavaScript that runs in your visitor's browser. This is the only thing PageSpeed Insights measures from the outside. It is the metric every vendor leads with.

The second is plugin code weight: the PHP that WordPress loads on every request to your site. Invisible to PageSpeed, but very real to your server. A plugin that bundles a tiny tracker can still drag your site down through megabytes of PHP code.

The third is per-request overhead: the work your site does on every pageview. Database writes. Filter hooks. Admin-bar queries. The kind of thing that makes your wp-admin feel slow at three months even though nothing visible changed.

Most "lightweight" claims address only the first. You see "our tracker is 2 KB" and you assume the rest is also light. That is not how it works, and once you measure all three, the rankings change.

Three categories of tools exist in the WordPress analytics space:

Script-only SaaS tools: Plausible, Fathom, Umami, Clickport, Simple Analytics. The tracking is just a script tag. You can install a WordPress plugin for convenience, but the actual data collection is a few KB of JavaScript and a network request. There is no PHP overhead, no database write, nothing to slow your admin.

WordPress-native plugins: Koko Analytics, Slimstat, Independent Analytics, Statnive, WP Statistics. The plugin stores everything inside your WordPress database. The tracker bytes might be small, but the plugin running behind the scenes is the bigger story.

GA4 wrappers: MonsterInsights, Google Site Kit, ExactMetrics. These are WordPress plugins that wire up Google Analytics 4 for you. The tracker that hits your visitors is Google's gtag.js at 139 KB gzipped. The plugin is bonus weight on top of that.

If you only measure tracker bytes, you cannot tell these three categories apart. That is why most "lightweight WordPress analytics" articles end up misleading you.

For the rest of this piece I will look at four dimensions:

• Tracker bytes (over the wire, gzipped)
• Plugin code weight (PHP code that loads on every request)
• Database writes per pageview (does it touch your DB?)
• Admin dashboard cost (does opening stats slow your wp-admin?)

A genuinely lightweight setup wins on all four. Most tools win on one or two.

The trackers, weighed: gzipped bytes that hit your visitor

I downloaded each tracker's production script from its CDN and gzipped it with the same algorithm that browsers and CDNs use. Numbers are from May 2026 and you can reproduce them yourself with curl.

Two things to flag honestly.

Plausible's tracker is smaller than ours. Their base script focuses on pageviews and basic events. Clickport's tracker is heavier because it also handles engagement (scroll depth, time on page, copy detection, click tracking), goal events (form submissions, custom events), and the engagement score logic. Different feature set, different weight. If pageviews are all you need, Plausible's 1.3 KB is mathematically lighter than our 2.8 KB. The 1.5 KB difference is roughly 0.001% of a typical 200 KB WordPress homepage payload, so the choice between the two should be made on features, not bytes.

The gtag.js number is also real. Google Analytics 4's tracker is 139,121 bytes gzipped, downloadable from googletagmanager.com right now. If you are running MonsterInsights, Site Kit, ExactMetrics, or any other plugin that wires up GA4, this is the script your visitors actually download. The plugin sits on your server. The 139 KB hits every visitor's browser, every page, every time.

Koko Analytics claims a 500-byte tracker. I could not verify this from outside because their plugin embeds the script inline rather than serving it from a public URL, but the figure is consistent with their architecture: Koko writes everything to your local WordPress database with no remote endpoint, so the script can be minimal. I will take their number on faith. It is smaller than ours.

Independent Analytics also embeds the script inline and claims 2 KB. Same constraint, same trust. Statnive does not publish a number I could find, but based on the plugin code it is in the 1 to 3 KB range.

The takeaway: the script-tag analytics category (Plausible, Fathom, Umami, Clickport, Simple Analytics) is tightly clustered between 1 and 4 KB gzipped. Differences inside this range do not really matter for Core Web Vitals. The difference between this range and gtag.js absolutely does.

If your only frame of reference is "how much does this tracker add to my page weight," the answer for any privacy-first tool is "less than a single low-quality image." The interesting numbers are in the next sections.

The plugins, weighed: PHP code Google never sees

PageSpeed Insights tests what a visitor's browser sees. It does not test what your WordPress server has to load on every request. A WordPress analytics plugin can be tiny on the wire and gigantic on disk, and your server still has to read, parse, and hold that PHP in memory every time WordPress boots.

I downloaded the latest stable .zip of each WordPress-native analytics plugin from wordpress.org. Here are the file sizes:

A few things stand out.

MonsterInsights is 27.8 megabytes of PHP code in its free version. That is the plugin that ships with the "free" label on wordpress.org. The Pro version is heavier. To put that in perspective: the entire WordPress core (the CMS itself, not just an analytics plugin) is around 25 MB. MonsterInsights ships more code than WordPress.

Koko Analytics is the lightest of the bunch at 203 KB. About one-twentieth the size of Site Kit. About one-hundred-and-thirtieth the size of MonsterInsights. Their architecture is genuinely minimal: a small PHP plugin, a tiny inline tracker, and a local WordPress database table.

Independent Analytics is 7.7 MB and ships 2,516 PHP files. That is an unusual number. Most WordPress plugins, even mature ones, have a few hundred PHP files. Independent Analytics has more files than the entire WooCommerce plugin had at its 5.0 release. The reason: they bundle a lot of dashboard UI, charting libraries, and integrations into the plugin itself.

Why does this matter for "lightweight"?

Every time someone hits your WordPress site, PHP boots, WordPress loads, and any active plugins load. The PHP opcode cache helps, but the plugin code still occupies memory and takes time on the request that fills the cache. A 27 MB plugin file tree is 27 MB of code your server has to know about. Even when nothing in the plugin runs on a given pageview, WordPress has read the main plugin file and registered its hooks.

The script-only category (Plausible, Fathom, Umami, Clickport, Simple Analytics) sidesteps this entirely. There is no WordPress plugin to load because the tracking is just a script tag in your theme's <head>. Plugin code weight on the row that says Clickport, Plausible, or Fathom is zero. Not "small." Zero. The convenience plugins exist for one-click setup, but you can run any of these tools with no plugin at all.

That is a structural difference, not a marketing claim.

The hidden cost: database writes per pageview

WordPress-native plugins store data inside your WordPress database. That means every tracked pageview is at minimum one database write. Often several: one for the pageview itself, one for session linking, one for referrer parsing, sometimes one for the visitor record.

I grepped each plugin's PHP source for INSERT, UPDATE, wpdb->insert(), and wpdb->update() patterns. The number of PHP files that perform database writes:

• Koko Analytics: 7 files
• Statnive: 9 files
• WP Slimstat: 10 files
• WP Statistics: 14 files
• Independent Analytics: 50 files

That count is files, not writes per request. Most plugins do not run every file on every pageview. But the surface area gives you a sense of how much database activity the plugin can generate. Independent Analytics has 50 PHP files with at least one write pattern in them, against Koko's 7.

The script-only tools do not write to your database. Zero rows. Zero writes. The tracker fires a network request to the vendor's server, and the data lands in the vendor's infrastructure. Your MySQL is untouched.

Here is what that means in practice. If your site does 10,000 pageviews a month, a WordPress-native analytics plugin is adding 10,000 database writes a month at minimum, probably more like 20,000 to 50,000 if it records sessions, referrers, and events separately. On managed WordPress hosting where you pay per database query or per write IOPS, these add up. On a server you run yourself, the inserts compete with your real WordPress workload (page renders, the admin, WooCommerce checkout).

A 100,000-pageview-a-month site running Independent Analytics is doing potentially 500,000 extra inserts a month. The plugin's tracker might be 2 KB, but the cost to your database is real.

This is also the answer to a question I see asked on r/Wordpress regularly: "Why does my site feel slow even though my analytics tracker is small?" The tracker is not the slow part. The plugin running on your server is.

The dashboard query problem

There is one more cost that almost nobody talks about: opening the analytics dashboard itself.

When you click "Analytics" in your WordPress admin, a plugin-based tool runs a series of SELECT queries against your database to render the report. The bigger your data, the heavier those queries. The slower your admin gets. The more you avoid checking your stats. The less value you actually get from the tool.

There is a long support thread on wordpress.org titled "Independent Analytics Update Killed My Site Loading Speeds" where a user describes their site grinding to a halt after a version update. The thread is from October 2024. The plugin author responded, the issue was eventually fixed, but the underlying architecture is the same: when your stats live in your WordPress database, opening your stats is a workload on your WordPress database.

This shows up in a more subtle way too. The WordPress admin bar at the top of every wp-admin page often includes a "site stats" tile. Some analytics plugins query the database to populate that tile on every admin page load. So you visit Plugins, you visit Posts, you visit Settings, and the plugin runs a stats query every single time. Multiply by every editor on the team, multiply by every admin page they open, and the admin gets slower over time.

Script-only tools route stats queries to the vendor's infrastructure. Your wp-admin stays clean. Your MySQL only does the work it has to do for your real site.

The Clickport dashboard runs on our servers. When you open it, you are querying our ClickHouse cluster, not your WordPress database. Same goes for Plausible's dashboard, Fathom's dashboard, Umami's cloud version. None of these put load on your WordPress instance when you open stats.

Google Site Kit, revisited with numbers

Site Kit is a special case that deserves its own row. It is technically a WordPress plugin, but the heavy lifting happens in Google's gtag.js and Google's analytics infrastructure. The plugin's job is to authenticate with Google, connect the tools, and wire up the script.

That sounds like it should be light. It is not.

In a separate article I documented PageSpeed drops between 20 and 67 points after installing Site Kit, with one user reporting their score dropped from 86 to 19. Google's own support docs acknowledge "a slight impact on performance." The reality is anything but slight.

What Site Kit adds, in our numbers:

• The plugin .zip is 5.1 MB.
• It loads gtag.js (139 KB gzipped) on every visitor's first page.
• It adds 1.13 MiB of PHP memory overhead per request, documented in detail in our Site Kit article.
• It hits Google's servers for periodic auth refreshes.

The 5.1 MB on disk is the smallest of these problems. The 139 KB on every visitor's browser is the bigger one. PageSpeed Insights flags this; Google's own page speed tool flags Google's own plugin.

If you are reading this because your WordPress site feels slow after installing Site Kit or MonsterInsights, the answer is not to optimize harder. The answer is to remove the GA4 script entirely.

The "no plugin" alternative: just a script tag

Here is what Clickport's footprint looks like on a WordPress site:

The installation is one line in your theme's header:

<script defer data-domain="yoursite.com" src="https://clickport.io/tracker.js"></script>

That is it. No PHP. No database table. No admin-bar query. No plugin to update when WordPress releases a new version. The same setup works on a static site, a Next.js app, a Hugo blog, a Webflow site. WordPress is just one of the supported environments.

If you want a step-by-step setup for WordPress, our docs page walks through both the script-tag method and our optional connector. The connector is a thin wrapper that injects the script into wp_head. It does no database writes, registers no admin pages of its own, runs no cron. The whole thing is small because it does not need to do anything else: the actual analytics work happens in a 2.8 KB script in the browser and a ClickHouse cluster on our side.

This is the architectural difference between script-tag analytics and WordPress-native analytics. The trade-off is also worth naming: if you require everything to live inside your WordPress install (for self-hosting or vendor-independence reasons), Koko, Slimstat, and Independent Analytics give you that. You accept the plugin weight and the database load in exchange for full data ownership inside WordPress. That is a legitimate choice. It is not a "lightweight" choice.

The honest ranking

If you weight all four dimensions equally, this is the ranking I would give based on the measurements above:

A few notes on the ranking.

Plausible takes the top spot on raw tracker bytes. We are fourth. That is what the numbers say. If your job is "smallest possible tracker on a high-traffic content site that does not need engagement scoring," Plausible is the rational choice on this axis. We will not pretend otherwise.

Koko Analytics is interesting. Their tracker is smaller than ours (0.5 KB vs 2.8 KB), but they sit at rank 6 because of the plugin overhead. If you weight the tracker heavily, Koko is genuinely small. If you weight the total footprint, the script-only category beats it.

The bottom four are tools that have GA4 in the pipeline. The 139 KB gtag.js dominates everything else. You could ship a 100-byte WordPress plugin and you would still serve 139 KB to every visitor because of the Google script.

What this ranking really shows is that "script-only architecture" is the biggest single decision. If you pick a script-tag tool (Plausible, Fathom, Umami, Clickport, Simple Analytics), the differences between them on weight are in the noise. If you pick a WordPress-native plugin, you are accepting plugin code weight and DB writes in exchange for keeping data inside WordPress. If you pick a GA4 wrapper, you are accepting 139 KB on every visitor.

These are architectural trade-offs, not "which vendor optimized harder."

How to verify your current setup is actually lightweight

You do not have to take my word for any of this. The measurements are reproducible. Here is how to weigh your own analytics setup in under five minutes.

Step 1: Check what your visitors actually download. Open your site in an incognito window. Open browser DevTools (F12 on most browsers), go to the Network tab, and reload the page. Filter for "analytics," "gtag," or your tool's domain. Click each request. The "Size" column shows what you served and the "Time" column shows how long it took.

If you are running MonsterInsights or Site Kit, you should see a request to googletagmanager.com/gtag/js?id=... somewhere around 139 KB transferred. That is gtag.js. That is the script your visitors load on every page.

Step 2: Check what your WordPress server loads. Install the Query Monitor plugin. Open any page on your front-end while logged in. Query Monitor will show you total queries and total memory used. Then deactivate your analytics plugin, refresh the same page, and compare.

The delta is what your analytics plugin costs per pageview. For Site Kit and MonsterInsights this is usually 1 to 3 MB of memory and a handful of queries. For WordPress-native plugins (Independent Analytics, Slimstat, WP Statistics) it can be more, especially if they track sessions or referrers.

Step 3: Baseline your PageSpeed. Run PageSpeed Insights against a representative page (your homepage, your most-trafficked blog post). Note the mobile score. Deactivate your analytics plugin or remove the script tag. Wait two minutes for caches to settle. Run PageSpeed Insights again. The delta is the real-world cost.

Most sites we have helped switch from Site Kit see PageSpeed mobile scores jump 20 to 40 points just from removing it. We documented this in detail in Google Site Kit Dropped My PageSpeed by 40 Points.

Step 4: Check admin speed. Open your wp-admin. Click around. If your admin feels slower than it used to, and you installed an analytics plugin in the last six months, your analytics plugin is a primary suspect. Run Query Monitor on the admin pages too.

These four checks tell you what each tool is actually costing you. No vendor claims, no marketing copy, just your own numbers.

Common questions

How do I fix a slow WordPress site?

The most common cause of WordPress slowness is plugin bloat, and analytics plugins are some of the biggest offenders because they run on every request. Start by deactivating plugins one at a time and re-running PageSpeed Insights. The plugins that cause the biggest jump when removed are the ones to replace or remove. Analytics, caching, security, and SEO plugins are the four categories that most often need scrutiny.

What is the best analytics tool for WordPress?

The answer depends on which dimension matters most to you. For pure tracker bytes, Plausible. For zero plugin overhead and engagement scoring, Clickport. For everything inside WordPress with no third party, Koko Analytics (smallest plugin) or Independent Analytics (most features). For users who want GA4 but with a friendly dashboard, MonsterInsights (accepting the 27 MB plugin). There is no single answer because the trade-offs are real.

Does Google Site Kit slow down WordPress?

Yes. Documented PageSpeed drops range from 20 to 67 points across users on the wordpress.org support forums. The cause is 139 KB of gtag.js on every page plus around 1 MB of PHP memory overhead per request. We covered this in detail in Google Site Kit Dropped My PageSpeed by 40 Points.

Do plugins slow down WordPress?

Some do, most do not. The plugins that slow WordPress are the ones that run code on every request: analytics, security firewalls, caching layers, SEO plugins that rewrite content. A plugin that registers an admin page and does nothing on the front-end has almost zero performance cost. An analytics plugin that runs on every pageview has measurable cost. This is why analytics deserves the closest scrutiny.

Is there a free website analytics tool?

Yes, several. Google Analytics is free but is the heaviest option on every dimension above, and is also under active scrutiny from European data protection authorities for GDPR violations. Koko Analytics is free and the lightest plugin. Umami offers a free self-hosted version. Most privacy-first SaaS tools (Plausible, Fathom, Simple Analytics, Clickport) offer a free trial but require payment after, because they do not monetize your visitor data.

A 2.8 KB script tag is the whole thing

If you want lightweight WordPress analytics and you do not specifically need everything to live inside WordPress, the answer is straightforward: pick a script-tag tool. Plausible, Fathom, Umami, Clickport, or Simple Analytics. Any of them will give you tracker bytes in the 1 to 4 KB range, zero PHP overhead, zero database writes, and no admin slowdown. The differences between them come down to features and pricing, not weight.

If you also want engagement scoring, scroll depth, copy detection, click tracking, form submissions, goal funnels, and bot filtering built in (which the bare-pageview tools do not include), Clickport is what we built. Our tracker is 2.8 KB gzipped. There is no WordPress plugin to install (the optional connector is a one-click convenience for users who prefer plugin-based setup). Your WordPress database is untouched. Your admin stays fast.

You can start a free 30-day trial without a credit card. If you are already on Site Kit or MonsterInsights and want a before-and-after PageSpeed comparison, the easiest way to get one is to install both, leave them running for a week, then deactivate the GA4 plugin. Most users see 20 to 40 points back on mobile PageSpeed within a single page reload.

I answer every email from new accounts personally. If you have a question about which architectural trade-off is right for your specific WordPress setup, hello@clickport.io reaches me directly.