2026-08-04

Slow website: the tracking scripts behind your bad score

You ran a PageSpeed test. The number came back red.

So you compressed the images. You switched on caching. You installed the optimisation plugin everyone recommends.

The number moved by four points.

I know that loop, because I ran it on my own site for a month. My code was not the problem. The problem was everything I had bolted onto it.

Analytics. An ad pixel. A chat widget. A consent tool to ask permission for the first two.

Each one felt small when I added it. Together they were heavier than my entire page.

Here is why that matters beyond the score. Google measures real loading behaviour through Core Web Vitals and those signals feed into ranking. A slow page also converts worse, because people leave before they see anything.

This article shows you how to find the weight and what you can safely cut.

Why a tracking script costs more than its file size

A 50 kilobyte script does not cost you 50 kilobytes. It costs you a chain of work and most of it happens on the visitor's phone.

Weight is not the only cost. The same third party scripts can also break a button on your page.

A DNS lookup and a new connection. The script sits on someone else's domain. The browser has to find that server and open a secure connection before it can download anything.

Loading a second script. Many tags are loaders. They arrive, then fetch the thing that does the actual work.

Main thread time. The script has to be parsed and executed. While that happens, the browser is not drawing your page. This is what turns into a bad Interaction to Next Paint score.

Layout shift. A consent banner that appears after the page has drawn pushes your content down. That is a direct hit to Cumulative Layout Shift.

"1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay."

Jakob Nielsen, Usability Engineering, 1993

Nielsen wrote that before the tracking tag existed. The limit has not moved since, because it comes from human attention, not from hardware.

Find the weight in ten minutes

You do not need a paid tool for this. Two free checks are enough.

1. Sort your requests by third party

Open your site, press F12 and go to the Network tab. Reload the page.

Sort by domain. Now separate the requests that come from your own domain from everything else.

Write down two numbers: how many external requests there are and how many kilobytes they add up to. That second number is the honest cost of your tags.

2. Look at the main thread, not the file sizes

Run a PageSpeed Insights test and open the section on third party code. It tells you how many milliseconds each external script kept the main thread busy.

This is where the surprise usually is. The heaviest script on your page is rarely the largest one.

What you can cut, in order

Work from the biggest win down. The order below is roughly what I found on my own site.

• The consent tool. It loads early, blocks rendering and shifts your layout. If you remove the trackers that made it necessary, this goes with them.
• The ad pixel you are not using. Most sites carry at least one pixel from a campaign that ended. If you are not running ads right now, take it out.
• The chat widget. Load it on click instead of on page load. The bubble can be a static image until someone touches it.
• Embedded video. Use the cookie free embed or show a preview image and load the player only when someone presses play.
• Analytics itself. This is the one you keep. But the weight difference between tools here is large and it is easy to check before you switch.

Still with me? The last item is where most of the remaining weight lives.

How to compare analytics scripts honestly

Vendors quote file sizes. That is the smallest part of the story. Check these three things instead.

Size after compression, not before. Ask for the transferred size, which is what the visitor actually downloads.

One request or several. Does the script load anything else after it arrives?

Does it block rendering. A tracker should load asynchronously and never sit in the critical path.

A tag manager container deserves a separate mention. It is convenient and it is also a script that loads more scripts. If you only use it for one tag, you are paying a middleman.

What you should not expect

Removing tags will not fix a slow server. If your hosting takes 800 milliseconds to send the first byte, no amount of script trimming will hide that.

It will also not fix an unoptimised hero image. Cut the tags and compress the image, in that order, because the tags affect interactivity and the image affects what people see first.

Be realistic about the score too. Going from red to green in one afternoon is rare. Going from red to amber by removing three scripts is common.

Where StatJolt fits in

The StatJolt script is a few kilobytes and it loads asynchronously so it never blocks your page from drawing.

It sets no cookies. That means no consent banner so the heaviest item on the list above disappears with it.

It also measures Core Web Vitals for you, alongside your traffic. You see what your visitors actually experienced, not what a test machine measured once from a data centre.

Two lines of code and the page speed work you already did stops being cancelled out by your tags.

The short version

Your PageSpeed score is usually held back by third party scripts, not by your own code. Open the Network tab, add up everything that comes from outside your domain and cut from the top of that list. The tags you remove give you back interactivity, which is the part Google actually measures.

Back