TL;DR
- "Zero-load" means zero tracking requests transmitted before the user makes a consent choice — not just visible-banner-present
- The standard comes from DPA enforcement practice and WP29/EDPB guidance, not from GDPR's literal text
- Any configuration where the CMP loads but trackers fire before interaction is a zero-load failure — regardless of banner design
- The test is purely network-level: what requests reached a third-party server before the first click?
Verdict
If any request to a tracking domain reaches a server before the user’s first interaction with the consent UI, you have a zero-load failure. The banner’s design, copy, and legal text are irrelevant to this determination. The network trace is the only evidence that matters.
Where the term comes from
“Zero-load” doesn’t appear verbatim in GDPR or the ePrivacy Directive. It emerged from the enforcement practice of European Data Protection Authorities — particularly the CNIL, the DSK (Germany), and the Datatilsynet — as shorthand for the compliance standard implied by Article 5(3) of the ePrivacy Directive and Article 6(1)(a) of GDPR.
The underlying logic: if consent must precede processing, and processing includes the act of transmitting identifiers to a third party, then anysuch transmission before a consent signal is generated violates the lawful-basis requirement. There is no grace period. There is no “technical necessity” exemption for advertising or analytics cookies.
The EDPB’s 2023 Cookie Banner Task Force report and multiple national DPA guidelines make the operative standard explicit: the default state must be no tracking, and tracking must begin only after an affirmative consent signal is received from the user.
What “before consent” means precisely
The moment a consent signal exists is the moment the user clicks Accept, Reject, or any equivalent unambiguous action. The banner being rendered does not constitute a consent signal. The page loading does not constitute a consent signal. A previously stored cookie preference may constitute a valid signal — but only if it was obtained through a prior valid consent interaction.
This has a concrete implication: a user on their first visit to your site has no stored consent. Until they interact with the banner, the consent state is undefined — not denied, not granted. Any processing that requires consent during this undefined window is non-compliant.
Many sites treat “undefined” as a permissive default. The WP29 guidelines and subsequent EDPB positions make clear it is the opposite: no signal means no lawful basis for processing.
Your site is leaking data before consent.
Free headless-browser scan. Catches GA4, Meta Pixel, TikTok and more firing before the click. Results in 10 seconds.
Run a free scan →What actually passes the test
A zero-load compliant configuration produces exactly one observable state when a new visitor arrives: zero requests to third-party tracking domains until a consent action is recorded.
Specifically:
- No requests to
google-analytics.com,connect.facebook.net, or any other tracking domain appear in the network log before the first user click. - No tracking cookies are written to the browser before the first user click.
- After clicking Accept, the blocked tags fire and cookies are set normally.
- After clicking Reject (or closing without choosing), no tracking requests appear.
That last point is increasingly scrutinised. Post-decline firing — trackers that activate after a user explicitly rejects — is a separate and equally enforced violation. A zero-load pass on page load does not mean the site is compliant if it fires trackers after rejection. The banner-blocking test covers both phases.
Four configurations that silently fail
1. The tag has no consent trigger in GTM
A GA4 or Meta Pixel tag set to fire on All Pageswith no consent condition fires on every page load. The CMP is present and the banner looks correct, but GTM doesn’t consult it. The network trace shows the request at ~100ms — before the banner initialises.
2. Consent Mode “Advanced” without a default deny
Google’s Consent Mode v2 in “Advanced” mode still sends cookieless pings before consent. Whether these pings fall under the zero-load requirement depends on jurisdiction and DPA interpretation. French and German regulators have treated them as requiring consent; others have not yet issued a definitive position. Treating Advanced mode as a compliance safe harbour is a legal opinion, not a technical fact.
3. The CMP CDN loads slower than GTM
The CMP is technically wired to block tags. But GTM is hosted on Google’s CDN and loads in 80ms. The CMP is hosted on a third-party CDN and loads in 350ms. GTM fires its tags before the CMP has initialised its blocking logic. The configuration is correct; the timing is not. This is a race condition, and it is a real-world failure mode that produces genuine violations. See the pre-consent tracker breakdown for how race conditions appear in the network log.
4. First-party analytics exempt by policy
Some DPOs classify first-party analytics as “strictly necessary” and configure the CMP to allow them without consent. This is a legal interpretation that most DPAs do not support for standard analytics cookies. Plausible or Fathom in cookieless mode may qualify; GA4 with its _ga cookie does not under current CNIL and ICO guidance.
Verifying zero-load compliance
Open Chrome DevTools Network tab. Disable cache. Hard-reload your page. Filter by third-party domains — google-analytics.com, connect.facebook.net, bat.bing.com, and any other tracking vendor you use.
If any request appears before you interact with the banner, you have a zero-load failure. The timestamp column shows you exactly when the request fired relative to page load.
For multiple URLs, multiple trackers, or a result you can hand to a client, the automated scan runs a headless browser, intercepts all pre-consent network activity, and returns a timestamped report with GDPR exposure classification — in 10 seconds, no DevTools required.