A look back at almost 20 years of history
Google Analytics, in its current incarnation, is the product of a constant and fascinating evolution. Its history goes back to 2005, the year it was launched by Google, although its roots go back even further.
Origins: Urchin Software Corporation
Before it was called Google Analytics, the tool was known as Urchin. Google acquired Urchin Software Corporation in March 2005. This was the cornerstone on which Google built what would become the world’s most popular analytics service.
Launch of Google Analytics (2005)
Just a few months after the acquisition of Urchin, Google launched Google Analytics. Demand was so high at the time that Google had to temporarily suspend new registrations just after the launch.
Mass adoption and rapid growth (2005-2010)
Google Analytics has quickly become one of the most widely used website analysis tools. According to various studies, in 2010 it was used by around 50% of the 10,000 most popular websites worldwide.
Introduction of Universal Analytics (2012)
In 2012, Google introduced Universal Analytics, a major upgrade. This enabled better integration between platforms and offered more personalised tracking capabilities, further strengthening Google’s dominant position in web traffic analysis.
Continuous evolution and advanced functionalities (2010-2022)
Over the years, Google has added many new features to Analytics, including mobile tracking, integration with AdWords and Search Console, and advanced reporting on goals and conversions, ensuring even faster growth in the e-commerce segment.
Google Analytics 4 (2023)
Today, despite a much-criticised migration to GA4, Google Analytics dominates the market in Web analytics tools. According to BuiltWith figures, in 2023 Google Analytics will be used by 63% of the 100,000 most visited sites, demonstrating its massive hold on the online analytics landscape.
This story is a testament to Google’s ability to identify a market need, integrate it into its ecosystem and develop it to meet the changing needs of webmasters, marketers and business owners around the world.
Performance problems with the tag supplied by Google
Since the earliest incarnations of Google Analytics, Google has provided users with a JavaScript tag to enable tracking. At first glance, this seems logical: JavaScript is a universally accepted language, works on virtually all browsers and allows complex interactions.
However, in terms of performance, this decision is not without consequences. Let’s take a look at what’s wrong with the way the Google Analytics tag works.
JavaScript tag vs native script
Until very recently (Universal Analytics), Google provided a JavaScript tag rather than a call based on the native html <script> tag, which limited our ability to prioritise its loading. In the web world, prioritisation is a crucial issue. Ideally, ‘third-party’ scripts should be de-prioritised in relation to ‘first-party’ scripts.
/* Old Google Analytics asynchronous injection script */
(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');This prioritisation ensures that the essential content and functionality of the site is loaded and rendered first, providing a better user experience. A JavaScript dynamic injection tag as formerly provided by Google offers no technical flexibility. Fortunately things have changed with the introduction of GA4, which finally takes advantage of html standards… but still retains its asynchronous behaviour.
Async vs. Defer loading
The tag supplied by Google uses an “async” loading mechanism, which means that it is downloaded at the same time as the page is rendered, in a non-blocking manner, but is executed as soon as it is ready.
This poses a problem because, although the script is loaded asynchronously, its execution can interrupt and block the rendering of the page. In its default implementation, the Google Analytics tag prevents pages from being displayed quickly in multiple scenarios.
Google Tag Manager: an extra layer of complexity
The fact that the Google Analytics 4 script must be encapsulated in a Google Tag Manager (GTM) container accentuates these problems even further. GTM generates blocking time, requires connections to several third-party domains, which leads to additional network latency, and ultimately delays the execution of the tracking code.
This leads to a scenario where GTM can block the rendering of pages, but Google Analytics can also do the same, as it is also executed asynchronously in the process. The result is pages with a degraded User Experience and high TBT and INP metrics.
Google’s problematic recommendation
Google advises placing its tag at the beginning of the <head> tag, which, from a performance point of view, is problematic. The beginning of the is precious territory where resources essential to the rapid representation of the page should be prioritised. Placing the Google Analytics tag here, especially without solid technical justification, is an invitation to performance problems.
Ultimately, although Google Analytics offers invaluable insights into user traffic and behaviour, its standard implementation poses serious challenges in terms of web performance. For professionals looking to deliver fast, fluid web experiences while benefiting from Google’s data, it’s important to optimise Google’s proposition. That’s what we’re going to look at next.
Optimising Google Analytics tag integration
Implementing a robust analytics solution like Google Analytics should not be at the expense of your site’s performance. Fortunately, with a few technical tricks, it’s possible to minimise its impact while retaining the benefits of the tool. Here’s how to optimise your integration.
Using a native <script> tag with “defer” and “fetchpriority”
Rather than relying on the default implementation, use a native <script> tag associated with the “defer” attribute. This ensures that your script doesn’t block page rendering because, unlike ‘async’, ‘defer’ allows scripts to be executed once rendered.
To further de-prioritise it, adding a fetchpriority="low" attribute tells the browser that this script is not crucial and can remain in the download queue as long as necessary. Here is an example of optimal code incorporating these two optimisations:
<!-- Google tag (gtag.js) -->
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX" defer fetchpriority="low"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');
</script>Load the script in the footer, before </body>.
For defer much more than for async, the order in which JavaScript resources are called matters. Even when associated with a defer attribute, a script called in the <head> will have a good chance of being executed before the scripts that follow it.
To be sure of de-prioritising Google Analytics, the code should be placed at the very end of the page, just before the html </body> tag. It should also be accompanied by all third-party scripts, with the exception of the CMP, which needs to be given higher priority.
Using resource hints
To anticipate and optimise network connections to Google Analytics, you can use resource hints such as dns-prefetch and preconnect. These resource hints allow the browser to resolve domains and establish upstream connections, speeding up the process when the script is actually called.
<link rel="dns-prefetch" href="https://www.googletagmanager.com">
<link rel="dns-prefetch" href="https://www.google-analytics.com">The code above anticipates the first connection step to the two domains required to load the Google Analytics script, which will then load with lower latency.
Loading the script from your own domain
Another powerful approach is to serve the Google Analytics script directly from your domain. This can be done via a proxy or through caching orchestrated by your CMS or a dedicated extension. In the WordPress ecosystem, many extensions offer such functionality, including the excellent WP Rocket.
By anticipating all or part of the 3 steps involved in connecting to an external domain (dns resolution, initial connection and SSL negotiation), you can save between 650 milliseconds and one second with a 3G+ connection, which is a significant saving in terms of network latency.
Postpone execution on user action
If your analytical needs allow, consider delaying the execution of the Google Analytics script until a user interacts with your site, for example by clicking, scrolling or typing.
This ensures that the browser’s resources are initially devoted entirely to rendering the page and activating its functions. Data is only collected in a second execution window, once the user is ready to engage. Such behaviour can easily be implemented in WordPress (WP Rocket, Perfmatters, etc.), but requires specific code elsewhere:
["keydown", "mousedown", "mousemove", "touchmove", "touchstart", "touchend", "wheel"].forEach(function(e) {
window.addEventListener(e, firstInteraction, {
once: true,
passive: true,
});
});
var userInteracted = false;
function firstInteraction(event) {
if (event && !userInteracted) {
let load_on_interaction = [
"https://www.googletagmanager.com/gtm.js?id=G-XXXXXXXXXX",
];
let head = document.getElementsByTagName("head")[0];
load_on_interaction.forEach(function(e) {
var script = document.createElement("script");
script.setAttribute("src", e);
script.setAttribute("defer", "defer");
script.setAttribute("fetchpriority", "low");
head.appendChild(script);
});
userInteracted = true;
}
}Ultimately, although Google Analytics is a powerful tool, it is essential to approach its integration with a careful eye to performance. If it seems too complex, you may find a solution tailored to your needs among the competition.
Alternatives with less impact on performance
Tracking user behaviour on a website is essential for understanding interactions and optimising the user experience. Although Google Analytics is widely used, it is far from the only solution available. There are alternatives that offer advantages in terms of privacy and performance.
Why do these alternatives have to be paid for?
The costs associated with collecting, processing and storing monitoring data are high. Supporting thousands or even millions of network requests every day requires a robust and scalable state-of-the-art server infrastructure.
Unlike Google, which monetises its services by exploiting data for advertising purposes, many other analytics players opt for a direct pay model in order to finance their infrastructure and guarantee user privacy.
Matomo and Plausible Analytics: major players
Matomo
Formerly known as Piwik, Matomo is an open-source web analytics platform that offers a serious alternative to Google Analytics. While providing a rich range of features, Matomo insists on privacy and data control.
Plausible Analytics
Younger on the market but very promising, Plausible stands out for the lightness of its tag, weighing just 1kb. This has a direct impact on performance, because a lighter tag means less blocking time, less bandwidth usage, and therefore improved Core Web Vitals metrics such as TBT (Total Blocking Time) and INP (Input Delay).
You probably haven’t seen it, but the current page, for example, loads a Plausible Analytics synchronously while benefiting from a mobile PageSpeed Insights score of 100%.
Benefits in terms of privacy and regulation
Another major advantage of Plausible is its compliance with the RGPD. It does not use cookies and does not collect personal data without consent. This means that with Plausible, there is no need to install a CMP (Consent Management Platform).
Not only are CMPs a concern in terms of privacy, they are also often cumbersome and generate ‘blocking time’. By eliminating the need for a CMP, we achieve a significant improvement in performance.
Now that the question of alternatives has been raised and developed, we need to look at the issue from a broader angle: Google Analytics is unfortunately just one example among many.
Beyond Google Analytics: the challenge of third-party scripts
Google Analytics is just the tip of the iceberg when it comes to managing web performance in the presence of third-party scripts. Whether they’re used for advertising, user behaviour analysis, cookie consent or A/B testing, these scripts can quickly accumulate and impact on the user experience. Here’s how to tackle this challenge.
Prioritisation: a universal request from third-party scripts
Most third-party script providers recommend setting their tags as early as possible in the page lifecycle. Whether for reasons of tracking efficiency or user interaction, this logic may seem sensible from their point of view. But this prioritisation can become problematic.
The essentials: the page itself
In the frenzy of adding features and analyses, it’s easy to forget that the heart of any website is the page itself. The ‘first-party’ scripts, the ones that are an integral part of your site and enable the user interface to function (drop-down menus, sliders, accordions, etc.), should be the real stars of the show.
Delaying to prioritise: the real challenge
The trick is therefore to re-prioritise first-party scripts by delaying the execution of third-party scripts. This is not only logical, it also benefits the user experience.
By focusing on the elements that really make up the content and functionality of your site, you can significantly improve key metrics such as FCP (First Contentful Paint) and LCP (Largest Contentful Paint).
Minimal impact on third-party scripts
By combining this de-prioritisation of third-party scripts with other optimisations, you can achieve a balance where nothing is lost in terms of the functionality of third-party tools.
In fact, the gain in performance on the FCP and LCP more than compensates for any delay that these scripts may suffer, bearing in mind that the fork we are talking about is generally 500 milliseconds maximum.
The importance of a global vision
The challenge posed by Google Analytics and other third-party scripts requires a global vision. Instead of prioritising each tool in isolation, a holistic approach that considers the whole site and the user experience is not only possible but essential.
By adopting this philosophy, you can enjoy the benefits of analytics and marketing tools without sacrificing web performance and user engagement.
Balancing performance and insights
In the digital age, where the ease of integration and variety of tools available can be seductive, it’s tempting to layer feature upon feature on our websites. A tag here for tracking user behaviour, another there for targeted advertising; and before you know it, your site’s performance has been compromised.
The hidden cost of third-party functionality
The addition of each new feature, no matter how attractive, needs to be considered in terms of its impact on performance. With every tag you add to your site, you also run the risk of adding loading time, network latency and increased CPU resource consumption.
The question to ask is not just whether a tool adds value, but also whether it justifies the cost in terms of web performance.
Rigorous monitoring for effective management
In the hustle and bustle of day-to-day operations, once-essential tools can quickly become obsolete or duplicated. Development teams are not always aware of changes in the needs or priorities of marketing or SEO departments, leading to the persistence of unused scripts that undermine performance.
Rigorous monitoring, using detailed web performance metrics, can highlight these imbalances and offer immediate performance gains when redundant or unnecessary tools are removed. These are issues we often discuss with our customers as part of our performance monitoring services.
The key words: “anticipatory thinking” and “collaboration”
It’s not enough to think about adding new features; it’s just as crucial to plan their maintenance and, eventually, their withdrawal. This requires close collaboration between the development, marketing and SEO teams.
Thinking ahead about which tools to integrate and their impact on performance can prevent problems before they arise, ensuring that your site remains efficient, up-to-date and aligned with your business objectives over the long term.
Ultimately, the aim is to strike a balance between gathering useful insights and maintaining a high-performance website. And this balance is only possible if every addition, every modification, is made with thought and in close collaboration between all the stakeholders.
In this delicate game, performance and insight are not enemies, but partners who, when properly managed, can coexist harmoniously.
