Google Analytics is the most widespread audience measurement tool on the web, and the third-party script found on almost every page we audit. It's implemented once, early in the site's life, often by someone who no longer works there, and it's rarely questioned: it's a free tool, provided by Google, whose official snippet is only eight lines long. Yet, these eight lines hide several hundred kilobytes of JavaScript executed with every visit.
An audience measurement tool is a script that collects navigation events, page views, clicks, and conversions in the visitor's browser, then sends them to a collection server. Google Analytics 4 does this via the Google tag, gtag.js, served from the googletagmanager.com domain, the same as the Google Tag Manager container, with which it is often confused. The difference matters because the two do not load, execute, or optimize in the same way.
This article traces the origin of the tool, measures its real cost to a page, details five levers to reduce this cost without losing any data, compares lightweight alternatives with supporting figures, and places Google Analytics within the broader family of third-party scripts. How does Google's integration recommendation, unchanged for twenty years, hold up against the Core Web Vitals that Google itself uses to rank your pages?
Where does Google Analytics come from?
Google Analytics was born from Google's acquisition of Urchin Software in March 2005. The tool has gone through four generations, from Urchin to the classic tag, then Universal Analytics in 2012, and finally Google Analytics 4, which became mandatory when Universal Analytics was discontinued on July 1, 2023. Each generation has increased the size of the embedded script as measurement became more closely tied to advertising.
From Urchin to Universal Analytics
Before being called Google Analytics, the tool was called Urchin, and it analyzed server log files. Google acquired Urchin Software Corporation in March 2005 and launched Google Analytics a few months later, with such high demand that sign-ups had to be temporarily suspended. Adoption was massive: by 2010, the tool equipped about half of the ten thousand most popular sites. In 2012, Universal Analytics introduced cross-platform tracking and customization capabilities that strengthened an already dominant position.
Google Analytics 4 and the Google tag
Over the years, Google added mobile tracking, integration with Google Ads and Search Console, goal and conversion reports, which accelerated growth in e-commerce and brought the measurement tool closer to the advertising network.
Google Analytics 4 has completed this move: an event-based model, native integration with Google Ads, and a common tag, the Google tag, which also serves Ads and Floodlight. Despite a widely criticized migration, the tool still dominates the market, and the Web Almanac 2025 places google-analytics.com and googletagmanager.com among the ten most present third-party domains on the web.
This story demonstrates Google's ability to identify a need, integrate it into its ecosystem, and develop it for its advertisers as well as for webmasters. It also explains why the script has grown: a tool that only measured page views has become the entry point for all Google advertising, and it carries the weight of it.
Does Google Analytics slow down a site?
Yes, measurably. The gtag.js tag from Google Analytics 4 weighs approximately 419 KB uncompressed, measured in August 2026, and 135 KB compressed according to Plausible's measurements, compared to 2.5 KB for the latter. The real cost is mainly at execution: this JavaScript must be parsed, compiled, and executed on the main thread, the very one that displays the page.
A JavaScript tag, by choice
Since its early versions, Google has provided a JavaScript tag for tracking, and this seems logical: JavaScript works everywhere and allows for complex interactions. In terms of performance, this decision is not without consequences. Until Universal Analytics, the tag was a dynamic injection script, which created the library's <script> tag itself, which prevented any prioritization by the browser: the preloading scanner does not see what the JavaScript creates.
/* Ancien script d'injection asynchrone Google Analytics (Universal Analytics) */
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXXXXX', 'auto');
ga('send', 'pageview');Things have changed with Google Analytics 4, whose official documentation now provides a native HTML <script> tag. The browser can finally discover it as soon as the document is parsed. But it retains its async attribute, and the placement instruction has not changed: immediately after the opening of the <head>, on every page.
Async is not free
The official tag uses asynchronous loading, which means it is downloaded in parallel with HTML parsing, without blocking it, but it executes as soon as it is ready, at an unpredictable time. This is where the problem lies: although the script is loaded asynchronously, its execution interrupts the page rendering for several hundred milliseconds on an entry-level mobile. In its default implementation, the Google Analytics tag delays page display in multiple scenarios, especially when it arrives before the main image.
Google itself documents this cost in its best practices for tags and tag managers, regarding the Core Web Vitals responsiveness metric, the INP.
Interaction to Next Paint is sensitive to CPU contention on the main thread, and we have observed a correlation between the size of tag managers and poorer INP scores.
Katie Hempenius and Barry Pollard, engineers on the Chrome team, in the Best practices for tags and tag managers guide on web.dev, updated August 24, 2022
Google Tag Manager, an additional and separate layer
A confusion needs to be cleared up, because it is in almost every article on the subject. The GA4 Google tag is served from googletagmanager.com, but it is not a Google Tag Manager container, and GA4 is installed without GTM, via the manual snippet from the documentation.
When the site also uses a container, two separate scripts run, gtm.js then gtag.js, each with its own initialization. The container generates its own blocking time, re-evaluates its triggers with each event, and delays the execution of measurement code. Measurements from the third-party-web project, on Lighthouse audits of the HTTP Archive, quantify this cumulative effect: the container costs about ten times the measurement tool it deploys.
Google's Problematic Recommendation
Google advises placing its tag immediately after the opening of the <head>, which, from a performance perspective, is the worst possible location. The beginning of the <head> is valuable territory, where resources essential for the first render should appear: the critical stylesheet, the main font, the LCP image preload. Placing a 419 KB third-party script there, without technical justification, is asking the browser to measure before displaying.
Although Google Analytics offers valuable data on visitor traffic and behavior, its standard implementation therefore poses serious performance problems. For those who want fast pages while retaining this data, it is advisable to correct Google's proposal, and that is what we do in our interventions.
How to optimize the integration of Google Analytics?
Five levers reduce the impact without sacrificing measurement: replace the official snippet with a native script tag using defer with low priority, place it at the bottom of the page, prepare the connection without over-soliciting it, serve the script from your own domain, and defer its execution until the first interaction. None of these degrade the quality of the collected data, with collection delays measured in hundreds of milliseconds.
Implementing a measurement tool should not come at the expense of performance, and with a few technical adjustments, it is possible to minimize its impact while retaining the tool's benefits. The five levers are cumulative, and the first two are already sufficient on most sites :
- a native
<script>tag withdeferandfetchpriority="low", instead of the official asynchronous snippet ; - placement at the very end of the page, just before
</body>, with all other third-party scripts except the CMP ; - a
dns-prefetchto the collection domains, never a preconnect to everything that passes ; - serving the script from your own domain, via the Google Tag Manager or a proxy ;
- deferring execution until the visitor's first interaction, with a ceiling delay for those who do not interact.
Each of these levers has a measurable effect and a known trade-off, detailed below in the order we apply them. The only rule that precedes them all is to measure before and after, by blocking the domain, as explained in our guide on the real cost of third-party scripts : unmeasured gain is no gain.
A native script tag with defer and fetchpriority
Rather than relying on the default implementation, use a native <script> tag with the defer attribute. Unlike async, defer executes the script after the HTML document has been fully parsed, in tag order, and never in the middle of rendering. To deprioritize it further, the fetchpriority="low" attribute tells the browser that this file is not critical and can remain in the download queue as long as the first screen's images and fonts are not served :
<!-- Google tag (gtag.js), version corrigee -->
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){ dataLayer.push(arguments); }
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');
</script>
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX" defer fetchpriority="low"></script>The order of the two tags is reversed compared to the official snippet, and this is not a minor detail: the dataLayer queue and the gtag() function must exist before the library executes, and since the latter is deferred, the config commands pushed upstream are simply processed upon its arrival. No events are lost; they wait in the queue.
Load the script at the bottom of the page, before the closing body tag
For defer much more than for async, the order in which scripts are called matters. Even when deferred, a script called in the <head> executes before all those that follow it in the document, including your own interface scripts. To be sure of deprioritizing Google Analytics, the code must therefore be placed at the very end of the page, just before </body>, along with all other third-party scripts. The only exception is the CMP, which conditions the others and the visitor experience: it stays at the top, and only it, as detailed in our guide to choosing the right CMP.
Use resource hints sparingly
To anticipate the connection to Google domains, the dns-prefetch and preconnect resource hints allow the browser to resolve a domain, or even establish the connection, before the script is requested. The rule has changed since our initial recommendations: an unused preconnection is closed after ten seconds and competes with the first screen connections, and Lighthouse 13 has removed its preload audit due to the risk of over-recommendation. For a script deferred at the end of the page, a simple dns-prefetch is sufficient, and preconnection is reserved for the CMP:
<!-- Resolution DNS anticipee, sans ouvrir de connexion : cout nul -->
<link rel="dns-prefetch" href="https://www.googletagmanager.com">
<link rel="dns-prefetch" href="https://www.google-analytics.com">
<!-- Preconnexion : reservee a ce qui est charge tot et conditionne le reste -->
<link rel="preconnect" href="https://cmp.exemple.com" crossorigin>Serve the script from your own domain
Another approach is to serve the script directly from your domain, which saves all or part of the three steps of connecting to an external domain: DNS resolution, TCP connection, and TLS negotiation, commonly saving several hundred milliseconds on a mobile connection.
Google now offers an official way, the Google Tag Manager for Advertisers, which allows deploying the tag from your own first-party infrastructure, via your CDN, your load balancer, or your web server. In the WordPress ecosystem, several plugins offer local caching of the script, with the risk of serving an outdated version if the refresh is not managed.
Postpone execution until the first interaction
If your needs allow, the most effective solution is to delay script execution until the visitor interacts with the site, by clicking, pressing a key, or moving the pointer, with a time limit for those who never do. Browser resources are then fully dedicated to rendering the page, and collection occurs in a second window. This behavior can be activated in a few clicks on WordPress with WP Rocket, Perfmatters, or FlyingPress, and requires specific code elsewhere:
// Report de Google Analytics a la premiere interaction, avec plafond de 5 s
(function () {
var done = false;
function load() {
if (done) { return; }
done = true;
var s = document.createElement('script');
s.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX';
s.defer = true; s.fetchPriority = 'low';
document.body.appendChild(s);
}
['pointerdown', 'keydown', 'touchstart'].forEach(function (ev) {
addEventListener(ev, load, { once: true, passive: true });
});
setTimeout(load, 5000); // les visiteurs qui n'interagissent pas sont quand meme mesures
})();Scrolling is intentionally absent from triggers. Loading a script of several hundred kilobytes on the first scroll shifts its execution precisely into the window where INP is measured, trading a lab gain for a loss in the field. Clicking, on the other hand, is an interaction where the visitor explicitly expects something. If all this seems too complex, the competition may have a simpler answer.
Is your site as fast as your visitors expect?
Which alternative to Google Analytics to choose?
Three serious alternatives share the market: Plausible, the lightest with 2.8 KB of uncompressed script; Fathom Analytics, at 6.9 KB; and Matomo, the most complete, at 84 KB but self-hostable. All three work without cookies, which also eliminates the consent banner for audience measurement, and the data loss associated with refusals.
| Solution | Script weight | Cookies | Hosting |
|---|---|---|---|
| Google Analytics 4 | 419 KB | Yes | |
| Matomo | 84 KB | Optional | Cloud or self-hosted |
| Fathom Analytics | 6.9 KB | No | Cloud |
| Umami | 4.7 KB | No | Cloud or self-hosted |
| Plausible | 2.8 KB | No | Cloud or self-hosted |
These weights are for uncompressed scripts, recorded from each publisher in August 2026. Plausible, for its part, publishes a comparison of compressed weights: 135 KB for the Google Analytics script versus 2.5 KB for its own, which is 54 times less, and over 285 KB in total when Google Tag Manager and a consent banner are added. The most telling gap is between the two extremes: Google's tag weighs 150 times Plausible's, for a need that, on a showcase or editorial site, is most often limited to page views and traffic sources.
Weight is only the visible part. A light script is also a script that executes little code, does not set cookies, and therefore does not require a consent banner for measurement or data loss related to refusals. On a site where half of visitors refuse cookie placement, a cookie-less solution paradoxically measures better than Google Analytics, which only sees the other half, or anonymized signals in advanced consent mode.
Why are these alternatives paid?
The costs of collecting, processing, and storing tracking data are real. Handling millions of requests per day requires robust and scalable infrastructure. Unlike Google, which monetizes its services by exploiting data for advertising purposes, these players opt for a directly paid model to finance their infrastructure without reselling the audience, which is also the condition for their GDPR compliance without consent.
Matomo and Plausible, two philosophies
Formerly Piwik, Matomo is an open-source platform that offers a serious and complete alternative, down to funnels and heatmaps, with a focus on data control, whether self-hosted or in the cloud. Its script remains substantial, and its behavioral features come at a cost comparable to the tools they replace. Plausible takes the opposite approach: a few kilobytes tag, a single dashboard, no cookies, and an impact on TBT and INP so small it's hard to measure.
You probably didn't notice, but the page you're reading loads Plausible and gets a mobile PageSpeed Insights score of 100. It's not the script that makes the score, but the sum of the choices it's part of; however, it's a script that has never needed to be deferred, and that's the best compliment you can give a third party.
Privacy and regulation
The other major advantage of these solutions is regulatory. Without cookies or personal data collection, audience measurement can, under certain conditions, bypass consent, which removes a banner, or at least one purpose of the banner, and the data loss that comes with it. CMPs are not only heavy, they generate blocking time on the critical path, as our comparison shows. Eliminating the need for a CMP for measurement is therefore a performance gain in itself, and Google Analytics is just one example among others of what measurement costs.
What is the impact of third-party scripts on performance?
Every third-party script demands the same thing: to be loaded with priority. Since they can't all be prioritized, the question isn't whether one of them slows down the site, but which ones deserve to load before the content. The answer is short: no third-party script deserves to precede the page itself, except for the one that authorizes the others.
A universal demand for priority
Google Analytics is just the tip of the iceberg. Advertising, behavioral analysis, consent, A/B testing, chat, customer reviews: these scripts accumulate, and most of their providers recommend placing their tag as early as possible in the page, for tracking effectiveness reasons that are legitimate from their point of view. The visitor's point of view is different: the core of any site is the page itself, and first-party scripts that make the interface, menus, forms, and cart work should be the only ones to load before the content.
Delay to prioritize
The trick is therefore to reprioritize first-party scripts by delaying the execution of third parties, which directly improves FCP and LCP, and frees up the main thread during the window where INP is measured. The display gain largely compensates for the delay that these scripts undergo, which is generally a maximum of 500 milliseconds. No data is lost, it is shifted: the page view starts a few tenths of a second later, which changes neither the count nor the attribution.
This point of doctrine applies to the whole family, and each tool will have its guide on this blog, from the cost of anti-flicker in A/B testing to the cost of chat and review widgets. Only one family is an exception, A/B testing, which must remain a priority, otherwise its tests will be skewed, and that is precisely why it is so expensive.
How to reconcile audience measurement and performance?
By treating each measurement tool as a budgeted expense, not as a free add-on. Quantify its weight and execution cost before installation, by domain blocking, then check its actual impact on field Core Web Vitals in Search Console. An unmeasured tool always ends up costing more than it brings in, because no one knows what it brings in.
The ease of integration and the variety of available tools make it tempting to layer functionality on top of functionality: one tag for behavioral tracking, another for targeted advertising, a third for a campaign. Each addition, however appealing, must be considered in terms of impact: loading time, network latency, visitor CPU consumption. The question to ask is not only whether a tool brings value, but whether it justifies its performance cost, figure against figure.
In the turmoil of daily operations, tools that were once essential become obsolete or duplicated. Technical teams are not always informed of marketing or SEO priority changes, and unused scripts persist for years. Rigorous monitoring, with detailed performance metrics, highlights these imbalances and yields immediate gains by removing redundant tools. This is an issue we systematically address in our performance monitoring services, where the number of third-party domains is tracked as a metric in its own right.
It is not enough to think about adding new features; their maintenance and removal must be planned, which requires collaboration between development, marketing, and SEO, and a end date set when each tag is implemented. This early consideration prevents problems before they arise and ensures the site remains fast and aligned with its goals.
Quantifying the cost of each measurement tool and relating it to its benefits is the starting point for a web performance audit; then, resetting, deferring, or replacing tags is part of performance optimization. In this delicate game, performance and measurement are not enemies, but partners that require arbitration, and arbitration begins with a number.
