Brendan Tully0 Comments
October 7, 2026
Marketing teams add tags and developers get blamed for the slow site. GA4, the Facebook Pixel, ad conversion tags and live chat widgets are some of the heaviest JavaScript on a typical page, and most of them load the moment Google Tag Manager does. Changing when those tags fire is one of the simplest ways to make pages lighter without removing any tracking. The catch for marketers is knowing which tags can safely wait and what changes in the reports when they do.
The video shows the two Google Tag Manager triggers used on a live account: a Window Loaded trigger for analytics and marketing tags, and a seven-second Timer trigger for a live chat widget. Here is how to apply them without damaging your data.
Most containers use the built-in All Pages trigger, which is a Page View trigger. Google’s own documentation says it fires immediately when the browser begins to load a page. The GTM container usually sits in the site’s head, so every tag attached to that trigger competes with the page’s own files while the visitor is still waiting to see something. Speed tools such as PageSpeed Insights then report render-blocking resources.
For search, a heavy page is a slower page in Google’s real-user data and a worse first impression for every visitor arriving from a result or an ad. Tracking scripts are rarely critical to drawing the page, so they are the easiest weight to move.
A Window Loaded trigger fires after the page has fully loaded, including images and scripts. By then the visitor can usually see and use the page. The analytics or marketing tag still runs on every page view and still records the visit. It simply starts a second or two later.
As the video puts it, an analytics tool does not care whether it loads immediately or two seconds later, but the page’s rendering does. To set it up, create a new trigger of type Window Loaded, name it something like “All Pages Window Loaded”, attach it to the tags in place of All Pages, and submit the container.
Delaying a tag has one honest side effect. A visitor who leaves before the page finishes loading was counted under the old trigger and may not be counted under the new one. For most sites that is a small group, and they are the least engaged visitors you have, but it can nudge sessions down slightly and engagement figures up. Annotate the change date in GA4 so nobody mistakes the shift for a traffic drop.
Live chat widgets are effectively a web app inside your website, and they are heavy. When someone clicks quickly through several pages, a chat widget reloading on each one can slow navigation and hurt Interaction to Next Paint, the responsiveness metric in Core Web Vitals.
The video uses a Timer trigger instead: interval 7000 milliseconds, limit 1 so it fires once, and a condition that the page URL contains the site’s own domain so it only runs there. The chat loads after seven seconds. Someone who has stayed that long is reading and is the person most likely to start a chat. Very few people open a chat within seven seconds of arriving, so the widget loses almost nothing.
The video names Tawk.to as a widget this works well for. It also warns that some tools, such as HubSpot, have their own loading optimisation that a timer could break, so test before relying on it.
The video also mentions combined approaches, such as waiting for window load and then a timer, or firing on the first user interaction. They exist, but the two triggers shown are the dependable ones. A tracking setup that occasionally fails costs more than the speed it saves.
Comments are closed.