QA Ultimate Stack

See how long each Google tag takes to load, client-side and server-side

Turn on Google tag checks in a page config to time gtm.js, gtag.js, GA4 collect and Google Ads requests, see when each loaded after navigation, and compare client-side with server-side setups.

Time every Google request on the page

Turn on Check Google tags in a Performance Test page config and the run also records every outbound Google tag request: GTM's gtm.js, gtag.js, GA4 collect hits, and Google Ads and DoubleClick requests. Each one shows its own network duration and how long after navigation it fired.

Offsets are a practical guide ("did GTM load in the first second or the eighth?"), not a micro-benchmark.

gtm.js at 0.6s, GA4 at 1.9s, and a Google Ads request arriving late at 4.7s.

Bars showing when each Google tag request fired after navigation, with the Google Ads request flagged as late.

Client-side and server-side in one toggle

The same toggle covers tags loaded straight from Google's domains and tags proxied through the brand's own domain by server-side GTM or first-party mode. That makes it a direct way to compare the two setups on the same page. GA4 hits are labelled v=2, so an old Universal Analytics request sharing the same path isn't miscounted as GA4.

The same container loaded from Google and from the brand's own server-side endpoint.

A table of Google tag requests with client or server side, host and duration, including a legacy Universal Analytics request.

Beacon hits may show as failed

A GA4 hit sent as a beacon around page unload often shows a failed status here, even when the browser delivered it, the same behaviour described in Read delivery verdicts. For delivery questions, use the Network Requests Inspector; use this timing view for when and how long.

Failed in the timing view, usually delivered anyway.

Two panels explaining that aborted beacon requests at unload are usually delivered.

Tests fire real tags

Unlike the form test, the Performance Test doesn't block anything, because blocking would make the timings meaningless. Every run is a real page load with real tags firing and real pageviews sent. The volume is low and easy to filter: add the test machine's IP to GA4's internal-traffic rules if you test production often.

Real loads mean real pageviews: low volume, easy to filter.

A checklist noting that page-speed runs fire tags, are low volume, and can be filtered by IP.

ODDVX for Windows

From the page to the hit, proved.

Start free with one saved form, one page and one parity check. Premium adds batch runs, exports and scheduled QA.