Improving website page speed with the help of server-side Google Tag Manager

Website page speed optimization was one of the essential benefits marketers and web developers saw when the first version of Google Tag Manager server-side was released. It was supposed to happen because tracking scripts would no longer be hardcoded but would be added through Google Tag Manager. 

In this article, we'll show you how moving tags from the GTM web container to a server container affects your GTM PageSpeed, what the data actually looks like, and which approach makes more sense depending on your setup.

As early as 2016, Google established that the ideal website loading time is 3 seconds. At the same time, on average, it takes 22 seconds to load the mobile page fully. 

We live in a time when people use watch phones more than desktop devices, and smartphones account for more than 50% of all Internet traffic. However, according to Google, mobile phone conversion rates are lower than desktops. That is why the website loading speed plays an essential role in meeting performance standards.

It is no secret that users expect a fast site experience. If the landing page is too slow, they’ll close the page or abandon the cart and move on to the competitors’ site. Today, in the mobile-first world, creating fast-loading sites is critical. Users want to have the ability to open any blog quickly and read articles, buy new clothes, check hotel reviews, and so on.

According to Amazon’s research, a 1-second delay in page response results in a 1% loss in conversions. That is equivalent to a loss of $1.6 billion in annual revenues for them.

As you can see, waiting for heavy pages to load can cost a lot for any company. 

Every tag you add through Google Tag Manager runs as JavaScript in the user's browser. Each script needs to be downloaded, parsed, and executed before or after the page loads, and that takes time.

Not every GTM setup behaves the same way, and this is where most of the confusion comes from. How the container is implemented — web or server — decides whether GTM adds load to the browser or takes it away. In the web container, every tag you add (analytics, ad pixels, chat widgets, heatmaps) is a script that loads and executes directly in the visitor's browser.

Each one competes for the same limited resources: the main thread, bandwidth, and rendering time. The more tags you stack, the more Google Tag Manager's performance impact compounds, even though GTM itself is a lightweight container.

Server-side GTM changes where the tag execution happens. Instead of dozens of third-party scripts running client-side, your server container receives the data and forwards it on to your marketing and analytics platforms from the cloud. The browser only has to talk to your own server, not to a dozen different third-party domains. That's the core reason the Google Tag Manager PageSpeed gap between web and server setups tends to be so wide.

2020, Google released a server container for Google Tag Manager and Tag Manager 360. It enables advertisers to move third-party tags from their sites to a new server container hosted in the сloud servers. This way, the website can load faster, tracking can be more accurate, and data can be safer. Moving tags to the server container can help solve this Google PageSpeed error: "Reduce the impact of third-party code — Third-party code blocked the main thread for 550 ms".

If you move tags from the web to the server container, tags will be loaded directly into the server container, not inside the browsers. This way, the page will load faster, and it will have a positive effect on the user experience. As you see, it can provide faster page load times, more security for your customer data, and more data management tools. This is one of the clearest examples of how server-side Google Tag Manager can improve website performance without sacrificing tracking accuracy.

Tags in the server container only have access to information sent to the server. They cannot access other information that users enter on the site. And since these tags are placed in your server container, you can understand which data tags are collecting information and where the information is sent.

Not all tags impact pagespeed equally, and this is an important nuance to keep in mind before assuming a migration will fix every performance issue. A lightweight analytics snippet and a heavy ad-retargeting pixel don't cost the same in load time, even though both are "just a tag." The tags with the biggest footprint tend to be the ones firing multiple network requests, loading additional scripts, or running on every page load rather than on specific events.

The most reliable way to see this for yourself is checking your Google Tag Manager PageSpeed Insights report before and after a migration, comparing the third-party code section of the results directly.

For this experiment, I used a demo website and compared Google PageSpeed results when tags were added via the GTM web container vs. the GTM server container. Not all tags have the same impact on Google PageSpeed. While doing this experiment, I decided to choose the most popular tags used by my client and the tags that can be moved to the server container: Facebook, Bing, and Active Campaign.

GTM server container has native tags for GA4. Here you can find detailed information on how to set up GA4 tracking using GTM server-side container. We also created a custom template to help you move Facebook pixel to the server environment. 

Below are the results of the Google Speed Test. Google page speed showed 95 points on mobile and 100 on the desktop. 

We have these tags installed on the server container: GA4, Facebook (base and conversion tracking), Hubspot, and Klaviyo tag.

When we moved the pixel to the web container, Google PageSpeed results decreased to 56 points. 

If you move tags to the Google Tag Manager server container, it will speed up your site. The level of its impact will depend on the tags you are using. In this test, the most popular tags among clients (GA4, Facebook, and Active Campaign ) showed a clear, measurable difference once they were moved server-side.