A CMP installed too late cannot correct what has already happened.
This sentence probably summarizes one of the most common mistakes in consent management implementations.
The banner may appear immediately. The “Reject” button may work perfectly. The configuration may look correct. But if Google Analytics or another service has already sent a request before the CMP could intervene, that initial collection has already happened.
The browser processes the page in an order
When a browser receives an HTML document, it starts reading it and processing resources as they are encountered.
It discovers stylesheets, scripts, images, iframes and various external resources.
A third-party script encountered early enough can therefore be downloaded and executed while the rest of the document has not yet been processed.
From the page’s perspective, the CMP does not exist yet if its own script appears later.
A network request is irreversible
Imagine a page that directly loads Google Analytics before tarteaucitron.
The browser downloads the Google script. It executes and may make its own requests.
A few milliseconds later, tarteaucitron loads and displays the banner.
At that point, the CMP may be able to prevent future actions, but it cannot recall network packets that have already been sent to an external server.
There is no JavaScript function that can tell the browser: “undo what was transmitted 100 milliseconds ago”.
Removing the script afterwards changes nothing
It is also possible to remove a <script> element from the DOM after it appears.
That does not undo its previous execution.
Once JavaScript has been downloaded and executed, removing its tag is a little like throwing away an envelope after the letter has already been sent.
This distinction is important for understanding why automatic detection needs to intervene early enough.
The same problem exists with iframes
A YouTube or Google Maps iframe directly present in HTML may begin loading its content as soon as the browser encounters it.
Replacing that iframe with a placeholder afterwards cannot undo requests that have already occurred.
To genuinely condition its loading, the external resource needs to be prevented from being requested before the visitor’s choice.
This is the principle used by tarteaucitron when external content is correctly integrated.
Manual mode solves the problem at its source
With tarteaucitron open source in manual mode, the approach is quite easy to understand.
The service’s direct tag is removed from the website. The service is then declared in tarteaucitron.
Google Analytics, for example, therefore no longer exists as an independent script loaded directly by the template. tarteaucitron decides when its integration should execute.
There is no need to intercept a script that is already present because it simply is not added before authorization.
Automatic detection needs to run before the service
With tarteaucitron Pro, the principle is different because the objective is precisely to preserve many existing integrations.
The Pro script therefore needs to load very early so it can detect supported elements before their effective execution.
This is why the marker should be placed as high as possible in the <head>, before the services it needs to control.
Automatic detection is not a time machine. It works because it arrives before what it needs to detect.
async can make order unpredictable
The async attribute asks the browser to download a script without blocking document parsing and execute it as soon as it becomes available.
Two async scripts therefore do not necessarily preserve their order of appearance in HTML.
If a CMP and tracker are both loaded this way, simply placing the CMP visually before the tracker in the source no longer guarantees that it will execute first.
Arbitrarily adding async or defer to the main tarteaucitron script can therefore break the expected behaviour.
defer also changes execution timing
defer preserves relative order more reliably between affected scripts, but delays their execution until after HTML parsing.
This behaviour can be useful for many conventional scripts intended to improve page loading.
It is much less logical for a script whose role is specifically to intervene as early as possible on other elements.
Optimizing a few milliseconds of loading should not move the CMP behind the services it is expected to control.
Google Tag Manager adds another layer
GTM can itself load many services.
If the CMP loads after the container, tags configured in GTM may have had time to fire before the CMP intervenes.
I therefore prefer a simple architecture: the CMP first, followed by tag managers and services it needs to control.
I discuss this case in my article about GTM and cascading consent.
The visible banner says nothing about actual loading order
This is probably what makes the mistake deceptive.
A banner can appear almost instantly while an analytics request was sent a few milliseconds earlier.
To the naked eye, both events appear simultaneous.
The only reliable way to verify the order is to inspect network requests and actual execution using browser tools.
The method is explained in my guide to testing a CMP with DevTools.
Browser cache does not change the principle
The fact that a third-party script is already in the browser cache does not solve the problem.
Even when a JavaScript resource does not need to be downloaded again from the network, its execution may trigger new requests and processing.
The issue is therefore not only downloading the JavaScript file itself, but everything its execution subsequently triggers.
Dynamically injected scripts also need to be controlled
Not every service is directly present in the initial HTML.
A plugin, tag manager or another JavaScript file may dynamically create a <script> tag or iframe after loading.
Automatic detection can specifically observe this type of behaviour, provided it is already active when the element is created.
Again, timing is the key.
Why not simply load the CMP absolutely first?
In practice, some technical elements may naturally precede the CMP: metadata, styles or essential internal scripts depending on the website architecture.
The important rule is not to win a competition for the first JavaScript byte on the page.
The CMP mainly needs to be active before the third-party services it is responsible for controlling.
That ordering relationship is what matters.
Correct order simplifies the entire architecture
The clearer the loading order, the less need there is to build complicated mechanisms to catch services afterwards.
In a simple architecture, the CMP takes its place early, knows the visitor’s choices and then allows or blocks the relevant elements.
Third-party services come afterwards.
This organization is much more robust than a system where all trackers load freely and an attempt is then made to neutralize them afterwards.
One simple rule to remember
For each service requiring consent, the final question is simple: which one executes first?
If the third-party service can operate before the consent mechanism is able to control it, the implementation is fragile or incorrect.
If the CMP controls the point at which that service can load, behaviour becomes much more predictable.
Consent needs to be prior. Technically, this means the mechanism responsible for enforcing it also needs to be in place early enough.
