
#GTMTips: How To Load Google Scripts From A Server Container
On June 30, 2025, Google announced that they are consolidating how Google’s script libraries for the web (e.g. gtm.js
and gtag.js
) are loaded when using a server-side Google Tag Manager container.
Before, you had the Web Container Client for loading the gtm.js
file, and you had the Google Analytics 4 Client for loading the gtag.js
file.
Now, you only use the former.
There is also the Google Tag Gateway option, which might be a better idea in case you really want to load Google’s scripts from a first-party context. Server-side Google Tag Manager isn’t necessarily the best content delivery option. Read more about the Google Tag Gateway here.
In this article, I’ll explain how the Web Container Client can be used to load your Google scripts.
XGoogle Analytics 4 Clients created before June 2025 still have the configuration options for script serving. This is to prevent the change breaking existing setups.
The Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
Tip 141: Configure the Web Container Client for serving Google scripts
Prior to June 2025, the Google Analytics 4 Client was the one you would use to load gtag.js
from your Server container.
No doubt because gtag.js
and gtm.js
technologies are converging, script serving has now been consolidated to just the Web Container Client.
For example, to use the Web Container Client to solely serve allowlisted Google Tags, you would configure it like this:
In this case, each individual Google Tag library has been allowlisted, and you can proceed to load them in the site code with something like this:
<script async src="https://sst.yourdomain.com/gtag/js?id=G-12345678"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
...
</script>
There’s an even smoother way of orchestrating everything, but you must load your web container via SGTM, too. If you configure the Web Container Client to serve your Google Tag Manager web container and you check the Automatically serve all dependent Google scripts
option, then any Google Tag loaded through that web container will automatically get loaded through SGTM!
The Google Tags in the web container do still need the
server_container_url
option set to the SGTM endpoint, though.
This is by far the simplest way to load Google Tags through server-side Google Tag Manager, and it really incentivizes loading your gtm.js
web container that way, too.
Just to wrap things up, let’s take a quick look at the use cases.
Only load Google Tags via SGTM
If you are not using Google Tag Manager for the web, or if you want to, for some reason, only load Google Tags and not the web container through server-side Google Tag Manager, here’s what you need to do.
In the Web Container Client, you only list the Google Tag measurement IDs and tag IDs.
Then, you load the individual libraries by updating their script loaders accordingly. There’s an example of this above.
Only load the web container via SGTM
If you only want to load the web container via SGTM and not all Google Tags within (or only some of the Google Tags), then you can uncheck the Automatically serve all dependent Google scripts option:
When you uncheck this option, only the listed containers are given permission to load through SGTM. All other library load requests fail with a 400 HTTP
error. If you want to allow the web container and maybe one or two Google Tags, you would add the Google Tag IDs to the list in the Client, too.
The problem with Google Tag Manager (web)
There’s a special caveat when it comes to “partial” loading of scripts via the server-side Google Tag Manager container.
If you are loading the web container through SGTM and you’ve allowed dependent serving, you are good to go with your Google Tags, too. The server_container_url
option automatically ensures that the Google Tags are loaded successfully through the server-side Google Tag Manager endpoint.
HOWEVER! Let’s say you have this use case in mind:
- You want to load the Google Tag Manager web container through SGTM.
- You do not want to load individual Google Tags through SGTM.
- You want those Google Tags to still send their requests to SGTM.
This is practically impossible to do with the Google Tag template in the web container. If you load the web container through server-side Google Tag Manager, then any Google Tags loaded within will automatically try to load their libraries from the server container if server_container_url
is used. As far as I know, there’s no way to configure a Google Tag to load its library from Google’s CDN but send their requests to your server-side endpoint if the web container is loaded through SGTM.
But this is probably quite a rare use case. If you are loading one Google library through SGTM, it would make sense to load all of them that way, too.
Compress response
If you want the server-side Google Tag Manager application to consume some extra computation resources in order to reduce the size of the library in the HTTP response, you can check the Compress HTTP response option.
Some cloud services automatically compress responses. With App Engine, for example, you do not have to check this option. With Cloud Run, you do.
Make sure you evaluate first if the responses are already compressed before checking this option.
Summary
By far the simplest approach to script loading through server-side Google Tag Manager is this:
Use the Web Container Client and list your web container GTM ID there (GTM-XXXXXXX
). Load all Google Tags through this web container, using the server_container_url
option to instruct the location of the server-side Google Tag Manager endpoint. Make sure the dependent serving option is checked.
Doing it like this ensures that all related Google scripts are loaded through your server-side tagging endpoint.
If you uncheck the dependent serving option or if you want to exclude some Google Tags but not others, it gets quite complicated, especially when using Google Tag Manager for the web. The server_container_url
just doesn’t seem to support the nuances of separating script loading from the data collection endpoint.
In general, I think this way of consolidating script loading makes a lot of sense. The term Web Container might throw some folks off, though. I don’t think many people still understand that Google Tag is on a technical and on a functional level a real, Google Tag Manager web container, just tailored for a specific purpose.