Some speed problems cannot be solved on the server, however well it is set up. Google Analytics, advertising pixels and live chat widgets are loaded from other companies’ servers and run in the visitor’s browser, after our server has already delivered the page. If a speed test shows these scripts as the slow part, the place to change them is usually Google Tag Manager. This article explains where the server’s job ends, which GTM settings you can change yourself, and when it is worth opening a ticket.
Where the server’s work stops
When someone visits your site, the server builds the page (or serves it from cache) and sends the HTML. The browser then reads that HTML and fetches everything it references: your theme’s files, images, and any third-party scripts. Our server has no part in downloading or running a script that comes from Google, Facebook or a chat provider. Server caching, PHP versions and database tuning make the HTML arrive sooner, but they cannot make someone else’s JavaScript lighter.
That is why a site can have a fast server response and still feel slow to load. If a speed test report lists render-blocking or third-party scripts from services such as Google Analytics, a pixel or a chat tool, the delay is happening in the browser.
Why tags load early by default
If your tracking runs through Google Tag Manager, most tags are probably attached to the default All Pages trigger. That trigger fires as soon as the browser starts loading the page, and since the GTM container normally sits in the head of the site, the tags start downloading while the page itself is still being drawn. They compete for the visitor’s bandwidth and processing time with the content you actually want them to see.
Two trigger changes you can make yourself
GTM is in your own Google account, so these changes are yours to make. The video shows both on a live container.
Window Loaded for analytics and marketing tags
In GTM, go to Triggers, click New and choose the Window Loaded trigger type. Name it clearly, for example “All Pages Window Loaded”, and save. Then open each analytics or marketing tag, swap the All Pages trigger for the new one, and submit the container. The tags now fire after the page and its images have finished loading. They still run on every page and still collect the same data; they just start later.
A Timer trigger for live chat
Live chat widgets are heavy because they are a small application running inside your site. The video uses a Timer trigger with an interval of 7000 milliseconds, a limit of 1 so it fires once, and a condition that the page URL contains your domain. The chat appears after seven seconds, by which time the visitor is reading the page and is more likely to want help anyway.
This does not suit every chat tool. Some, HubSpot being the example in the video, manage their own loading and a timer can interfere with that. Test the chat after the change.
Before you change anything
- Use GTM’s Preview mode to check each tag still fires on its new trigger before you publish.
- Leave conversion tags on order confirmation or thank-you pages on a trigger that fires when the page loads, not on a timer, so a customer who closes the page quickly is still recorded.
- Avoid combining several triggers in complicated ways. The video mentions these combinations exist but sticks to the two simple triggers because they are reliable. A site with broken tracking or a broken widget is worse off than a slightly slower one.
- If your scripts are added by a plugin or pasted into the theme rather than through GTM, these triggers do not apply. Moving them into GTM first is a reasonable project, but it is a change to your site rather than to the hosting.
When to open a ticket
Third-party scripts are managed in your accounts with those providers, so we cannot change them on your behalf. A ticket is still worthwhile when:
- You are not sure whether the slowness is the server or the scripts. We can check server response times and caching for your site and tell you which side the delay is on.
- The server response itself looks slow in your speed test, which is our area to investigate.
- Something stopped working after a tag change and you want to rule out a caching or server cause.
Open it from the client area and include the page URL you tested, a link to or screenshot of the speed test result, the tools loaded on the site (analytics, pixels, chat), whether they run through GTM or a plugin, and what you have already changed. That lets our support team look at the right layer straight away.