A lightweight Google Analytics 4 integration

Google Analytics 4 has been a let down in many aspects based on every discussion I’ve seen and had with professionals of all stripes – marketers, advertising specialists, CROs, GA professionals, online experimentation experts, etc. One of the less discussed issues it brought with it is the default heavyweight GTAG library integration it comes with. GA4’s GTAG compares quite unfavorably to the Universal Analytics’ analytics.js library and incurs a much heavier toll on website performance in terms of both page load speed and how script-heavy a page becomes.

The article starts with a comparison between the Universal Analytics integration and the Google Analytics 4 in terms of its effects on page performance, and then presents a lightweight solution for integrating GA4 on a website. This solution is suitable for cases where page performance is key and there are development capabilities similar to those required for a customized Universal Analytics setup.

The performance impact of GTAG (GA4) vs Analytics.js (UA)

The table below presents a comparison of the impact one can expect from switching from a Universal Analytics integration to a Google Analytics 4 integration in terms of their respective JavaScript libraries. Characteristics are as of Mar 2023.

Library	Transfer size	% change	Script size	% change
Analytics.js (UA)	20 kb	–	49 kb	–
GTAG.js (GA4)	134 kb	+670%	371 kb	+757%

The transfer size is compressed in both cases, and the script size is the uncompressed script that has to be parsed. The transfer size for the Google Analytics 4 library is 6.7 times larger, and the script to be parsed is 7.6 times larger.

To put the above numbers into perspective, the page you are currently reading this article on is generated through WordPress, one of the most popular CMSs out there. Its transfer size is about 400 kb, roughly 110 kb of which are scripts which are 380 kb uncompressed. Adding Google Analytics 4 tracking through its official GTAG.js integration would increase the network transfer size by 33% and the amount of scripts to parse by roughly 98%!

Take into account that WP is by no means the most lightweight platform out there. Many fully functional websites run by performance-minded web developers deliver their functionality and content with an even smaller footprint so adding GTAG there would hurt performance relatively more.

Obviously, the above do not necessarily translate directly into increases in page speed measured through timings such as page load time or page interactive time, but the detrimental impact is surely there. Even if one considers impact beyond the second page where the script is already cached, the impact of the JS parsing is still there, it is processor-heavy and impacts the time to interactive metric.

Do you need all the bells and whistles?

Depending on the purpose of your GA4 integration, you might actually have no way around it. If you need to use any of the automatically measured interactions such as scrolls, outbound clicks, and search interactions (so-called “enhanced measurement”), you need to rely on GTAG. If you are comfortable coding those in a similar fashion to what you did for Universal Analytics, then there might be a different way to do things.

Likewise, if you rely on additional functionality offered only through GTAG, then with the bells and whistles comes a price in performance.

However, a lot of things can be accomplished without GTAG, including event tracking of any kind, conversion tracking, ecommerce tracking, setting user properties, and campaign tracking. If you think this is sufficient for your needs and you have sufficient development capabilities, read on.

A performance-oriented Google Analytics 4 implementation

The solution proposed here utilizes GA4MP, an open-source Google Analytics 4 client-side protocol implementation developed by David Vallejo, a specialist in GA4 and TMS integrations.

Importantly, it is not a GA4 measurement protocol implementation since in GA4 the MP can only be used to augment your data instead of being a fully-capable replacement of your standard client-side tracking as it was with Universal Analytics.

Simply putting GA4MP on your site won’t provide you with proper user tracking and session handling. A bit of additional code is required to make it work as a capable replacement of the standard GTAG. In essence, this code needs to set and read cookies through which to keep track of user IDs and session IDs. What is labeled as GA4MP+ below is such an additional script I’ve written* for use on this and other websites I operate.

How lightweight is it?

In terms of both transfer size and script size, the lightweight integration blows past not only GA4’s GTAG script, but also the UA analytics.js library:

GA4 Library	Transfer size	% change	Script size	% change
GTAG.js	134 kb	–	371 kb	–
GA4MP	3.3 kb	-97.5%	8.5 kb	-97.7%
GA4MP+	3.9 kb	-97%	10.2 kb	-97.3%

With savings of up to 97% in transfer size and JavaScript amount to parse this lightweight GA4 integration is definitely worth the attention of performance-oriented developers.

Does it have sufficient functionalities?

Lightweight does not mean it lacks any of the core functionalities. With GA4MP one has the ability to perform:

• pageview and event tracking
• conversion tracking
• ecommerce tracking
• campaign tracking
• user properties
• virtual pageviews

The ability to set user properties is important if one plans to use Google Analytics to store A/B testing data as it could be used to store and segment users by their allocation to different experiment arms. In such a scenario, make sure to use BigQuery to extract your data for analysis to avoid the inaccuracy in cardinality estimates which will ruin most statistical analyses. This is the reason Analytics Toolkit no longer supports a direct GA integration.

Obviously, coding is required to make all of those work, just like it did with Universal Analytics before that. For some of these, e.g. ecommerce tracking and user properties, the amount of development involved should be equivalent to a GTAG integration.

Should I switch to a lightweight GA4 implementation?

If page load speed and the overall performance of a website are of high priority, then you should consider it. That is, unless there is a core GTAG functionality that you simply must have implemented, in which case there is no way but to add the big chunk of code that it is. Likewise if there are no capabilities and budget for development and deployment of custom code, one has to live with the default Google Analytics 4 integration.

* David Vallejo was kind enough to support me in debugging an issue with the initial version of the code, for which I’m thankful and I would recommend him for his demonstrated skills and kind attitude.

About the author