Why do tags fire before the cookie banner loads
Another tag is sharing the trigger your cookie banner was supposed to have to itself. Putting the banner on Consent Initialization is necessary and not sufficient, because that trigger releases everything attached to it at once rather than in order, so a lighter tag beside it can reach the network first while the banner is still fetching its configuration.
The trigger is a starting gun, not a queue
Consent Initialization exists so consent defaults are registered before anything else evaluates, and every guide telling you to put your consent tool there is right. What they leave out is what happens when a second tag is placed on the same trigger. The trigger does not become a queue. It releases everything attached to it, and from that instant the tags race each other over the network.
Tag firing priority looks like the answer and is not. Tag Manager's own help page on firing priority says that tags with higher priority values fire before those with lower values, and then adds the line that matters here: tags will still fire asynchronously. Priority decides the order in which requests start. It does not make the container wait for one to finish. A consent tool that has to fetch its configuration over a network can therefore start first and still arrive second, which is exactly the case that costs you.
What we measured on a live estate
The reported symptom was an advertising request leaving the browser before any consent state existed, on a site whose consent work was otherwise in good order. Denied defaults present, the signal on the outgoing analytics request reading as denied, and the consent tool's template on Consent Initialization exactly as documented.
A remarketing tag was on that same trigger. Read in the network panel in the order requests started rather than in preview, the advertising request went out ahead of the consent tool's own loader on every load we captured, by a margin of roughly two milliseconds. Treat the ordering as the finding and the margin as an illustration: a browser network panel is not a sub millisecond instrument, and the number would move with connection and cache. What does not move is which request went first, and why. This is not a slow banner. It is two things released together, one of which had less work to do.
Why every audit of the consent tool came back clean
Because every audit was an audit of the consent tool, and the consent tool was doing its job. Checking it the way we normally recommend, by reading the consent signal on the outgoing request, returns a pass, because the request you are reading is the one that behaved.
Preview mode does not settle it either. It tells you which tags fired and in which event, which is not the same as which of two requests released in the same instant reached the network first. A container that looks correct in preview can sit alongside a page that is not.
Four causes, one symptom
A tag firing before the banner has loaded has more than one cause, and they are cheap to tell apart once you know they are different things.
Another tag is sharing the trigger
The case above. The consent setup is correct, the offending tag is fast, and the race is invisible everywhere except the network panel. Consistent rather than intermittent, because the same tag wins every load.
The consent tool is on the wrong trigger
On All Pages it competes with the entire container rather than with one tag. This is the case the standard advice already fixes, so rule it out first. Correct placement is in installing a cookie banner with Google Tag Manager.
The consent tool loads outside the container
If the banner is in the page source and the container loads separately, which request wins depends on the page rather than on any tag setting, and varies by template and cache state. Intermittent behaviour points here.
The tag has no consent check at all
Not a race. A tag with no consent check never consults the consent state, so denied defaults do not restrain it and no ordering will. It fires first because it was never waiting.
How to see the order for yourself
This takes one page load and no debug mode. The whole trick is to stop reading the container and start reading what left the browser.
Load the site in a clean profile and click nothing
A session that has already accepted tells you nothing: the state is restored from a stored choice before the race happens.
Sort the network panel by when each request started
The default view groups requests in ways that hide this. You want the timeline, not the list.
Find the consent tool's own request, then read upward
Anything above it from an advertising or analytics vendor went out before consent existed. That names the tag for you.
Open the container and list every tag on Consent Initialization
There should be two at most: the consent tool and the tag registering your denied defaults. Everything else there is a candidate.
Reload twice more before concluding anything
Consistent order means a shared trigger. An order that changes between loads means the consent tool loads outside the container, which is a different fix.
The fix, and why priority is not it
Take the offending tag off Consent Initialization and give it All Pages or its own event. The race ends because there is no longer a race, and it is a two minute change. If a tag genuinely has to run early, tag sequencing is a more precise instrument than priority, because it names which tag fires before which rather than expressing a preference.
Resist the two tempting non fixes. Raising priority leaves both tags on the trigger and asks an asynchronous system for a synchronous guarantee it does not offer. Adding a second defaults tag gives you two things issuing consent defaults, which is a new problem rather than a fix. For genuine belt and braces, put a small inline denied defaults snippet in the page head above the container snippet, so a denied state exists before the container is parsed.
Then measure it again the way you found it. A real fix shows the consent tool's request arriving first on every clean load, with the advertising request either waiting or carrying a denied signal. If the numbers moved but the order did not, you fixed something else. Conversions that shifted around the same date deserve the same reading: why GA4 conversions drop overnight.
Velo is built to take the fetch out of this race: the denied state is set inline as the page parses, before the container is reached, so it does not depend on a configuration request arriving in time. Placement still matters, and so does keeping other tags off that trigger. The mechanism is on the product page.
Common questions
What people ask about this topic.
Why do tags fire before the cookie banner loads?
Most often because another tag is sharing the trigger that runs first. Consent Initialization fires everything attached to it at once rather than in a queue, so a lightweight advertising tag placed there can complete before the consent tool, which usually has to fetch a configuration over the network. The consent setup itself can be entirely correct and still lose that race.
Does raising the tag firing priority fix a consent race?
Not reliably. Google's documentation is explicit that tags with higher priority values fire before those with lower values but that tags will still fire asynchronously, so priority controls the order requests start and not the order they finish. A consent tool can start first and still arrive second. Taking the other tag off the trigger is the fix; priority is a preference.
How do I tell which request actually went out first?
Read the network panel rather than the tag manager preview, on a clean profile with nothing clicked, sorted by the time each request started. Preview mode reports which tags fired and in which event, not their wall clock order over the network, so a preview that looks correct sits happily alongside a page that is not.
Which tags are safe to put on Consent Initialization?
Only the consent tool and the tag that registers your denied defaults. That trigger exists so consent state is established before anything evaluates, and every extra tag placed there is a tag competing with the thing it is supposed to wait for. Everything else belongs on All Pages or on its own event.
Can a tag fire before consent even when the defaults are denied?
Yes, and this is the case that confuses teams. Denied defaults only govern tags that read the consent state. A tag with no consent check attached does not consult it, so it fires regardless of what the defaults say. That is a missing check rather than a race, and the two look identical from the outside.
Your banner, your consent,
your data — all in one place.
