The Case for Limiting Analytics and Tracking Scripts

The Case for Limiting Analytics and Tracking Scripts

I spend a great deal of my time auditing websites, and in about 90% of those audits I find unused tracking scripts. Scripts nobody remembers adding, scripts that track data nobody reads, scripts that were "just one more pixel" added by marketing two years ago. Each one seemed harmless at the time. Together they add seconds to every page load.

According to Kaspersky's 2024 web tracking report, the average website now has 48 trackers. The 2025 Web Almanac shows that over 90% of web pages include at least one third party, and the top 1,000 most visited sites fire a median of 129 third-party requests on desktop. That is not a tracking strategy. That is a performance problem.

Last reviewed by Arjen Karel on March 2026

Why sites use analytics and tracking scripts

Analytics and tracking scripts serve a real purpose. Google Analytics tells you where your visitors come from. Facebook Pixel tracks ad conversions. Hotjar shows you where people click. Without this data, you are guessing.

The problem is not that these tools exist. The problem is that most sites load far more tracking than they need. Popular tools like Google Analytics, Facebook Pixel, and Cloudflare analytics all add JavaScript, cookies, and HTTP requests. And they are rarely the only tracking on the page.

Fact: In about 90% of all audits I will find unused tracking scripts. Usually these scripts are injected late through a tag manager or other third party script.

How heavy are these scripts?

Not all tracking scripts are created equal. Here is what the most common ones actually cost you:

• Google Analytics 4 (gtag.js): 134 KB compressed, 371 KB uncompressed. Loaded asynchronously, so it does not block rendering, but the JavaScript still needs to be parsed and executed on the main thread.
• Google Tag Manager: ~33 KB compressed for the library itself, plus whatever tags you put inside it. The median container is about 50 KB. An empty GTM container adds roughly 100ms of delay. Eight tracking tags inside GTM add about 3 seconds on Fast 3G and 10 seconds on Slow 3G.
• Facebook/Meta Pixel: 340 KB uncompressed (95 KB compressed). That is 7 times larger than Google Analytics. It makes 4 HTTP requests before it is done and adds 1.3 to 1.5 seconds to every page load.
• Consent Management Platforms: OneTrust can add 124 to 347 KB depending on configuration. In one case a consent banner became the LCP element, increasing LCP from 1.43s to 3.61s.

Stack GA4 + GTM + Facebook Pixel + a consent banner and you are looking at roughly 400 to 600 KB of tracking JavaScript before any of your own code runs. That is often more than the entire page content itself.

How tracking scripts affect the Core Web Vitals

Largest Contentful Paint

Every script competes for network bandwidth and CPU time during page load. Even asynchronous scripts take up bandwidth that could be used for the LCP image or critical CSS. When you load 8 tracking scripts alongside your hero image, you are forcing the browser to share its limited mobile bandwidth across all of them.

This is particularly bad on mobile networks. The 2025 Web Almanac reports a median mobile Total Blocking Time of 1,916ms (up 58% from 2024). Much of that blocking comes from third-party JavaScript. You can defer your scripts, but they still compete for resources once they start loading.

Interaction to Next Paint

Interaction to Next Paint (INP) is where tracking scripts do the most damage. The 2024 Web Almanac found that presentation delay is the main contributor to poor INP, and the scripts causing it are behavior tracking tools, consent providers, and advertising pixels.

Many tracking scripts keep working long after the page has loaded. Google Analytics can be configured to track every click. Heatmap tools like Hotjar listen to every mouse movement. Each of these event listeners adds processing time to user interactions. When a visitor clicks a button and your code takes 50ms to handle it, but three tracking scripts also fire event listeners that add another 150ms, the interaction feels sluggish.

The numbers tell the story: 77% of all mobile pages pass INP, but only 53% of the top 1,000 most-visited websites do. Those top sites have more complex JavaScript and more third-party scripts. If you want to keep your pages responsive, tracking scripts are the first place to look.

Time to First Byte and cookie overhead

Each tracking script can place its own cookies. Individual cookies are small (median 40 bytes according to the 2025 Web Almanac Cookies chapter) but their collective impact adds up because cookie data is sent with every HTTP request. If your site sets 4 KB of cookies and loads 39 resources, that is 156 KB of extra upload data across those requests.

When total cookie data exceeds roughly 1,500 bytes, request headers no longer fit in a single TCP packet. That forces extra round trips, directly increasing your Time to First Byte on subsequent navigations and static resource loads.

Cumulative Layout Shift

Consent banners are the worst offender here. When a cookie consent banner renders late and pushes page content down, it causes a layout shift. Some consent platforms inject large DOM trees (200+ nodes) that reflow the page. In one documented case, a consent banner was the LCP element for 50% of pageviews because it rendered on top of the actual content.

Strategies for smarter tracking

Audit what you actually use

Open your tag manager and go through every single tag. For each one, ask: who reads this data? When was it last checked? If nobody can answer, remove it. I routinely find tags for A/B testing tools from campaigns that ended months ago, pixels for ad platforms the company no longer uses, and duplicate analytics implementations (both GA4 via GTM and a hardcoded gtag.js).

Delay non-essential scripts

Not everything needs to load on page view. Nobody has ever been disappointed that a heatmap script took 3 seconds to start recording. Fire analytics and tracking tags on the Window Loaded event or, even better, defer them until the user interacts with the page. AnalyticsMania's testing showed that delaying tag firing by 1.5 seconds after page load saved 6 seconds on Slow 3G.

// Load analytics only after first user interaction
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
    events.forEach(e => document.removeEventListener(e, loadAnalytics));
    // Load your analytics script here
    const script = document.createElement('script');
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    document.head.appendChild(script);
};
events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));

Use the Beacon API for custom events

If you send custom analytics events (form submissions, button clicks, scroll depth), use navigator.sendBeacon() instead of XMLHttpRequest. The Beacon API sends data asynchronously without blocking the main thread and is guaranteed to complete even during page navigation. This is especially important for keeping INP low on interactions that trigger analytics calls.

// Send analytics data without blocking the interaction
document.querySelector('.buy-button').addEventListener('click', (e) => {
    // Use sendBeacon - non-blocking, survives page navigation
    navigator.sendBeacon('/analytics', JSON.stringify({
        event: 'purchase_click',
        timestamp: Date.now()
    }));
});

Consider server-side alternatives

The most effective way to eliminate tracking JavaScript is to not load it at all. Cloudflare Zaraz moves analytics execution to the edge, replacing client-side tag manager scripts with a lightweight beacon. GTM Server-Side Containers let your server forward data to analytics providers without any vendor JavaScript reaching the browser. These approaches take more effort to set up but their impact on performance is close to zero.

For simpler needs, lightweight alternatives like Plausible (under 1 KB) or Umami (about 2 KB) provide traffic analytics at a fraction of GA4's 134 KB cost.

What good looks like

Across sites monitored by CoreDash, pages loading fewer than 5 third-party scripts pass INP at roughly 88%, compared to 64% for pages loading 15 or more. The difference in LCP is just as clear: fewer competing requests means the browser can prioritize what actually matters to the visitor.

You do not need to remove all tracking. You need to be intentional about what you load, when you load it, and whether anyone actually uses the data. Start by auditing your tag manager. Remove what you do not need. Delay what you do. Use Real User Monitoring to verify the improvement in field data, because lab tests will not show you the full picture of how tracking scripts interact with real network conditions and real user behavior.