Is Your Analytics Slowing Down WordPress? What the Numbers Say
Tracking scripts are the most commonly installed third party code on the web, and the most commonly ignored in performance audits. Here is how to see what yours costs.
On this page
Yes, analytics costs you something. The useful question is how much, and the answer is almost never the file size everybody quotes. A tracking script’s real cost is when it runs and what it holds up, and a single well-behaved script is a rounding error next to a tag manager quietly loading six tools behind it.
The good news is that you do not have to guess. Every browser ships the tools to measure this on your own site, with your own theme and your own plugins, in about fifteen minutes.
Why File Size Is the Wrong Number
Vendors advertise script weight because it is small and flattering. A tracker measured in single-digit kilobytes sounds like nothing, and on a fast connection the download genuinely is.
What the number leaves out is everything around it. Before a byte of that script arrives, the browser has to resolve a new domain name, open a TCP connection and complete a TLS handshake. On a mobile connection that sequence can cost more than the file itself. Then the code has to execute, and execution happens on the same main thread that renders your page.
So two scripts of identical size can have very different costs depending on how much work they do once they arrive.
The Part That Actually Hurts
Three things separate a cheap tracker from an expensive one.
Whether it blocks rendering. A script loaded without the async or defer attribute stops the browser parsing your HTML until it has been fetched and run. This is the single biggest mistake, and it is usually caused by pasting a snippet into the wrong place rather than by the script itself.
How much work it does on load. Some trackers just record a pageview. Others build a device fingerprint, read cookies, watch for scroll and click events, and start a session recording. That work is invisible in the file size and very visible in the main thread timeline.
How many friends it brings. The most expensive analytics setups are rarely one tool. They are a tag manager that loads analytics, a heatmap tool, an ad pixel, a chat widget and a consent manager, each of which was added by someone who reasonably assumed they were adding one small thing.
Measure Your Own Site in Fifteen Minutes
Open Chrome DevTools, go to the Lighthouse tab and run a mobile performance audit. Then look at the Third-party usage section, which lists every external origin your page loaded and the main thread time each one consumed.
That report is the honest answer for your site. A tracker showing a few tens of milliseconds of blocking time is doing its job quietly. One showing several hundred is worth investigating.
For the real proof, run the audit twice: once as the site is, once with the tracking script commented out. The difference between the two numbers is your actual cost, measured on your actual site, and it beats any published benchmark.
What a Cookieless Tracker Skips
Some of the work in a traditional tracker exists to solve a problem that a cookieless design does not have.
If a tool identifies returning visitors with cookies, it has to read and write them, handle the consent state around them, and often coordinate across domains. That is code that runs on every page. It also usually means you need a cookie banner, which is itself another script, and a banner that blocks the tracker until someone clicks is a second delay stacked on the first.
DevDome Analytics is cookieless by default, so there are no analytics cookies to read, write or ask permission for, and no consent gate sitting in front of the measurement. The script records the pageview and gets out of the way. That is a design decision made for privacy reasons, and the performance saving is a side effect of it rather than the point.
The Server Side Difference
There is one more cost that never shows up in a speed audit: the work your visitor’s browser does that could have happened somewhere else.
Click tracking is the clearest example. The usual approach attaches JavaScript listeners to every outbound link, which means more code, more event handlers and more main thread work, and ad blockers strip a lot of it anyway so you pay the cost without getting the data. Capturing those clicks on the server instead removes the listeners entirely and produces numbers that ad blockers cannot remove.
Audit the Tag Manager, Not the Tag
If your site feels slow and you are looking at your analytics script, you may be looking at the wrong thing.
Open your tag manager container and count what is in it. Most sites that have had a marketing team for two years are carrying at least one tag nobody can explain: a pixel for an ad campaign that ended, a test tool someone trialled, a script from an agency you no longer work with.
Each of those is a DNS lookup, a connection and a chunk of main thread time on every page view, forever, until somebody deletes it. Deleting three dead tags will do more for your speed than switching analytics vendors.
A Reasonable Standard
You are not trying to reach zero. You are trying to keep the measurement cheap enough that it never becomes the reason a page feels slow.
One tracking script, loaded async, that does not need a consent gate in front of it and does not attach listeners to every element on the page, is a cost most sites should be happy to pay. Five scripts doing overlapping jobs is not, and no amount of vendor optimisation fixes that. Run the audit, count the origins, and delete what nobody can justify.
Disclosure: DevDome publishes this blog and makes the products it mentions. We describe what they do rather than promise results.
Key takeaways
- Script weight matters less than when the script runs and what it blocks.
- A tag manager loading several tools compounds the cost far beyond one script.
- Third party scripts also cost a DNS lookup and a TLS handshake before a single byte arrives.
- Measure your own site rather than trusting a vendor's published number.
- The honest test is a before and after run with the script removed.
Sources
- web.dev: optimize third party JavaScript — how third party scripts affect load and what async actually changes
- Chrome for Developers: Lighthouse third party summary — the audit that reports blocking time per third party origin
Links last checked August 20, 2026.
Frequently asked questions
Does an async script really have no cost?
Async means the download does not block the page from parsing, which removes the worst kind of delay. It does not mean free. The browser still spends time on the DNS lookup, the connection, the download and then executing the code, and that execution competes with your own scripts for the main thread. Async makes a script polite, not invisible.
Should I self-host my analytics script to make it faster?
Self-hosting removes the extra DNS lookup and connection to a third party domain, which is a genuine saving on the first visit. It also means the file is served with your own caching rules. The trade-off is that you now own updating it, and a stale copy can quietly stop reporting. Weigh that against a saving usually measured in tens of milliseconds.
Is Google Tag Manager itself slow?
The container is small. What makes it expensive is what people put inside it, because a tag manager makes adding another tool feel free. A container with eight tags in it is eight third party scripts, and each one was added by someone who assumed it was the only one. Audit the container, not the loader.
How much speed is worth losing for good data?
That is a business question, not a technical one, but the framing helps: you are trading a fraction of a second on every page against knowing what your visitors do. Most sites should accept one lightweight tracker and refuse the fifth one. The problem is almost never the first script.