{"id":13471,"date":"2026-10-07T07:35:00","date_gmt":"2026-10-07T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13471"},"modified":"2026-09-25T09:45:53","modified_gmt":"2026-09-25T07:45:53","slug":"checking-a-consent-banner-which-tracking-scripts-load-before-anyone-clicks","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/data-privacy\/tutorials-en\/checking-a-consent-banner-which-tracking-scripts-load-before-anyone-clicks\/","title":{"rendered":"Checking a Consent Banner: Which Tracking Scripts Load Before Anyone Clicks"},"content":{"rendered":"

A consent banner looks like a gate. It covers the page, it asks a question, and nothing seems to happen until a button is pressed.<\/p>\n

That appearance is drawn, not enforced. The banner is an element on the page like any other, added by a script that runs with all the other scripts. Whether the measurement tags wait for the answer is a separate arrangement – and it is entirely possible to have the question without the waiting.<\/p>\n

\n\"Two
Same banner, same moment of clicking – the difference sits between them.<\/figcaption><\/figure>\n

A banner is not a barrier<\/h2>\n

The order of events on a page is fixed and short. The browser fetches the HTML, works through it from top to bottom, and starts every script it meets on the way. Somewhere in that sequence is the script that draws the banner.<\/p>\n

Everything above it has already started. Everything below it starts regardless, unless something specifically prevents it. The banner covering the screen does not pause the page behind it – a visual overlay has no effect on what is loading underneath.<\/p>\n

So the question is never whether a banner exists. The question is what happens to the tags in the seconds before anyone touches it.<\/p>\n

The three ways a script is actually held back<\/h2>\n

Only three arrangements genuinely delay a script, and each leaves a different trace in the source.<\/p>\n

The type is changed.<\/strong> A script marked type=\"text\/plain\"<\/code> is not executed by the browser at all – it is treated as text. The consent tool rewrites the type after a decision, and only then does the script run. This is the most common approach and the easiest to spot.<\/p>\n

The address is moved.<\/strong> The real address sits in an attribute the browser ignores, such as data-src<\/code>, and gets moved into src<\/code> after the decision. Same principle, different attribute.<\/p>\n

The script is never in the page.<\/strong> Nothing about the tag appears in the delivered HTML; the consent tool inserts it after the answer. This is the cleanest arrangement and the hardest to verify from outside, because a page in this state looks identical to a page with no measurement at all.<\/p>\n

What all three have in common: they are decisions made when the page is built, not settings inside the banner. A consent tool that was installed but not wired into the tags produces a perfect banner and holds nothing back.<\/p>\n

What Consent Mode sets before the first tag<\/h2>\n

Google’s tags have a separate mechanism for this, and it works the other way around: the tag loads immediately and is told beforehand what it may do.<\/p>\n

That instruction is a consent default. Set before the tag loads, it says whether storage is permitted, and the tag behaves accordingly from its first moment. Without a default, the tag applies its own – and measures under it until the consent tool corrects the state.<\/p>\n

The gap between page load and correction is usually short. It is not always short, and it is never nothing.<\/p>\n

A default set to granted<\/code> is worth a second look. It treats a visitor as consenting before anything was asked, which is a decision rather than an oversight – though it is often an oversight in practice, copied from an example that was written for a region where the rules differ.<\/p>\n

\n\"Two
\n<\/figure>\n

The cookies that arrive with the first answer<\/h2>\n

Scripts are only one route. The server can set cookies in the response itself, before a single line of the page has been drawn.<\/p>\n

Those cookies appear in the response headers, and they are set whatever the banner later says, because they were sent before the banner existed. Session cookies for a shopping basket belong in that group and are usually unproblematic. Analytics cookies set the same way are not.<\/p>\n

Whether a cookie needs consent depends on what it does, not on when it is set. But the moment of setting decides whether a consent tool could have prevented it at all – and for a cookie in the first response, the answer is no.<\/p>\n

What the source shows, and what it cannot<\/h2>\n

An honest limit belongs here, because it decides how a result should be read.<\/p>\n

The delivered HTML is what the server sends. It does not include what a script loads afterwards. A page that inserts all its tags after the decision therefore shows almost nothing – which is the correct behaviour and looks identical to a page that has no tags at all.<\/p>\n

That ambiguity cannot be resolved from the source alone, and a tool that pretends otherwise is guessing. What the source does show reliably is the opposite case: a tag that sits in the HTML unblocked is a tag that loads regardless.<\/p>\n

Which is the finding that matters. A page with a banner and unblocked tags has the appearance of a decision and the behaviour of no decision.<\/p>\n

Four things a look at the source settles<\/h2>\n

Which measurement and advertising services are wired in, and under which identifiers. Whether a consent tool is present at all. Whether any script in the page is held back, by any of the three routes. And which cookies the very first response already sets.<\/p>\n

The tracking and consent scanner<\/a> answers all four for any address. It fetches the page once, reads the delivered source, and separates what is wired in from what is held back – and it says plainly when a result means “nothing visible here” rather than “nothing there”.<\/p>\n

The verdict worth having is not a score. It is the sentence that follows from the four answers: whether the banner on that page is a question with consequences, or a question without.<\/p>\n

\n

Questions and answers<\/h2>\n

Does a script with async or defer wait for consent?<\/h3>\n

No. Both attributes only change when a script runs, not whether it runs: async executes it as soon as it has loaded, defer after the HTML has been parsed. In both cases this usually happens long before the first click on the banner, so in the source such a script counts as unblocked.<\/p>\n

A Google tag sits unblocked in the source, but Consent Mode is set up. Is that a finding?<\/h3>\n

To begin with, it is a design choice. Consent Mode does not hold the tag back: the tag loads at once and follows the default set beforehand. An unblocked tag is therefore to be expected there, and it loads in any case. What matters is what comes before it in the source.<\/p>\n

Three things can be read there:<\/p>\n

    \n
  1. Whether a consent default is set at all, usually through a call to gtag('consent', 'default', \u2026)<\/code>. Without one, the tag’s own default applies until the consent tool corrects the state.<\/li>\n
  2. Whether it comes before the tag. A default that only runs after the tag is too late for the first requests.<\/li>\n
  3. Which values it sets, for example for analytics_storage and ad_storage. If they are set to granted, a visitor counts as consenting before being asked.<\/li>\n<\/ol>\n

    Even with a correct default, it remains open whether loading the tag and the requests it sends without cookies are permissible without consent. That is a legal question a look at the source cannot answer.<\/p>\n

    Does a single fetch show what every visitor receives?<\/h3>\n

    Not necessarily. A fetch sees the page as it was delivered for exactly that request: without a stored decision, from one particular location and possibly from a page cache. Some consent tools deliver different versions depending on where a request comes from, and Consent Mode supports defaults per region; a default with a region setting sits in the source and can be read there, a switch on the server cannot. Strictly speaking, an unremarkable result therefore only holds for the region the check was made from.<\/p>\n<\/div>\n

    \n

    Sources<\/h2>\n