This tracking tag didn't fire until 8 to 58 seconds into the visit

We were benchmarking a DTC apparel brand's product page this month and found their attribution tag didn't send anything until 8.1 seconds into the visit on Wi-Fi. On slow 4G it was 30.4 seconds, and on 3G it was 57.6 seconds. When we loaded the same tag in the page head instead, it fired at 0.3, 2.2 and 4.8 seconds.

The reason was the trigger. The store fired the tag from Google Tag Manager on the Window Loaded trigger, which waits until every image, font and third-party script on the page has finished. Anyone who leaves before that never gets counted. They don't show up as a bounce or as a visit, so the trigger you pick basically decides which visitors exist in your reports.

Why this matters for paid traffic

Paid visitors decide fast. On one brand's in-app ad traffic we looked at recently, most people were gone within about five seconds, and on four of five pages 81% to 90% never scrolled past the first screen (what in-app ad traffic does on a landing page).

So a tag that fires eight seconds in misses pretty much all of those early exits, and a few things follow from that:

• Your analytics shows fewer landings than your ad platform shows clicks.
• Your conversion rate looks better than it is, because the only people being counted are the ones patient enough to wait for the tag, and they buy more often.
• Heavier pages look better than lighter ones. They fire their window-load tags later, so they lose more of their early leavers from the count.

How we tested it

We took one live product page and a copy of the same page served from Lutiq's edge. The original fired the attribution tag from the brand's GTM container on Window Loaded (the gtm.load event). The copy loaded the same vendor's tag in the page head.

We loaded each page in Chrome with a Pixel 8 Pro profile (412 × 915 viewport, 2× CPU slowdown), three times per network profile, with the cache off and cookies cleared before every run. Then we recorded when the tag's first request started. These are medians:

The vendor's server answered all 24 of those first requests with a 200. So the tag worked fine. It just started late.

Most of the delay came from the trigger

The original page was also slower to respond. Its first byte showed up around 4.3 to 4.6 seconds in, against 0.1 to 0.2 seconds for the copy. But even if you take that out, the trigger still accounts for most of it. Counting from the first byte, the window-load tag went out about 3.5 seconds later on Wi-Fi, 26 seconds later on slow 4G and 53 seconds later on 3G. The head-loaded tag went out 0.1, 2.1 and 4.6 seconds after the first byte.

That's because the browser only fires its load event once everything the page asked for has finished downloading. On a fast connection that takes a few seconds. On a congested mobile connection, the slowest third-party script sets the time. In our runs, window load arrived at 30.4 seconds on slow 4G for the original page and 13.6 seconds for the lighter copy.

Faster HTML didn't make the product image faster on slow 4G

The copy painted its first content way sooner, 0.34 seconds against 5.2 on Wi-Fi. But on slow 4G, largest contentful paint (when the biggest thing on the screen shows up, usually the hero image) was almost the same: 11.9 seconds against 11.1.

On a slow connection the hero image is the bottleneck, and a faster HTML response doesn't change how long a big image takes to download. If most of your paid traffic is on phones, I'd pay as much attention to the size of that first image as to the server.

A few caveats

• We didn't measure how many visits actually get lost. A visitor who leaves during the gap can't be recorded by the late tag, but working out how many people leave in that window needs a live split with matched reporting.
• The trigger wasn't the only difference. The copy was lighter and served from an edge cache, and the vendor's bootstrap script was one minor version newer. So this test can't fully separate the trigger from the lighter page.
• It's a lab test: three runs per condition on an emulated phone, in separate batches rather than interleaved. The tracking timings were consistent from run to run. The paint timings were less consistent, and Chrome didn't report paint entries on some 3G runs, so I left 3G out of the second table.

Your QA tools might not see your popup either

While we were testing this store we found a related blind spot. A widely used SMS signup tool checks navigator.webdriver, the flag browsers set when automation software is driving them, and doesn't start up when it's true. So the automated QA and screenshot tools never saw the 15% signup popup that real shoppers were getting. When we drove an Android emulator by hand, the popup showed up about 8 seconds into the visit in single test runs.

That same popup was targeted by URL path. When the page ran on a different URL, shoppers got the store's general offer instead of the campaign offer until the original path was passed along. If you move a landing page to a subdomain or a landing page tool, check that your popup targeting still matches.

How to check your own store in about ten minutes

1. List your measurement tags and their triggers. In Google Tag Manager, open each analytics, attribution and ad platform tag and look at the firing trigger. If it says Window Loaded, the tag is waiting for the whole page.
2. Time the first request on a slow connection. In Chrome DevTools, set the network to Slow 4G, turn off the cache, reload a landing page and filter the Network panel by the vendor's domain. The start time of the first request is your answer.
3. Compare that with how fast people leave. If your analytics or session recordings show how long bounced visitors stay, put the two numbers side by side. Any overlap is visitors your reports can't see.
4. Move measurement tags earlier and keep them light. Fire analytics and attribution tags on the Initialization or Page View trigger and load their scripts asynchronously. Chat widgets, review carousels and anything else that isn't measurement can stay on later triggers, where they won't hold up the tags that count visitors.
5. Check popups in a real browser. Use a phone, or an emulator without automation flags, when you're checking what shoppers actually see.

FAQ

Does Google Tag Manager's Window Loaded trigger slow down the page?

Not directly. It holds the tags attached to it until the browser's load event, after everything on the page has downloaded. The page itself isn't slower. The tags just start late, and on slow mobile connections that can be tens of seconds.

Which trigger should analytics and attribution tags use?

If a tag needs to count every visit, fire it as early as you can: the Initialization or Page View trigger, with the vendor's script loaded asynchronously so it doesn't block rendering. Tags that don't affect measurement can wait.

Will loading tags earlier hurt page speed?

An asynchronous tag snippet in the head is small, and it doesn't stop the page from painting. The heavier parts of the vendor's code still load in the background. I'd still measure it: compare first contentful paint and largest contentful paint before and after the change on a throttled phone profile.

Why does my analytics show fewer visits than my ad platform shows clicks?

Late tags are one reason. Others are people closing the page before it loads, blocked scripts, consent settings and redirects between the ad and the page. I think the gap between clicks and recorded landings is worth measuring on its own, because every number downstream of it inherits it.

Related

• What in-app ad traffic does on a landing page
• Early signals for landing page tests
• Two ways people buy from an ad: includes a separate measurement of how often landings are confirmed on iOS versus Android
• Google's largest contentful paint definition

---

I'm Colin Behr, co-founder of Lutiq. Before Lutiq I spent years in mobile ad tech at AppLovin, Vungle and Branch. Lutiq predicts which on-brand landing page to show each paid click and measures the lift against a live holdout. The figures in this post are our own lab measurements from September 2026, and the brand isn't named.