The Loader & Performance
The ConsentLayer banner is delivered by a single script — the loader — that
you drop into your site's <head>. This guide explains what it is, why it runs
the way it does, and why that design protects your Core Web Vitals.
What the loader is
The loader is dependency-free vanilla JavaScript. It's generated per site and served from the CDN:
<script src="https://b.consentlayer.com/<your-key>/banner.js"></script>Because it's built for one site, banner.js already contains that site's
categories, banner design, and blocking rules — there's no second request to
fetch configuration, and no framework runtime to boot. It's regenerated and
re-published every time you save a change in the dashboard, so the served file
always matches your current configuration. If the CDN copy ever isn't
available, the same file is served from the API origin as a permanent fallback.
Why it runs synchronously in <head>
The loader tag has no defer and no async — and that's deliberate. To
stop a tracker from setting cookies before the visitor has consented, the loader
has to be running before that tracker does. A synchronous tag in <head>
executes the moment the browser parses it, ahead of any analytics, pixel, or
tag-manager code lower in the page. Add defer/async and the browser is free
to run trackers first — consent is lost before it's asked for.
This is why every install snippet places the tag as the first script in
<head>. When Google Consent Mode is enabled, banner.js also installs the
gtag/dataLayer stub and pushes the default denied state itself — which
only lands ahead of Google's tags if the loader runs first.
Load order
banner.jsruns first (synchronous). It sets default consent to denied, arms script blocking, and prepares the banner.- Your HTML keeps parsing. The loader does its work and returns; the browser continues to your content and largest contentful element.
- Trackers stay gated. Analytics and marketing scripts are held until the visitor consents to their category, then released.
The one thing the loader blocks is other trackers — not your content, images, or layout.
Core Web Vitals
Gating trackers is what keeps ConsentLayer light on the metrics Google measures:
- LCP — trackers don't compete with your main content for the network while the page is painting.
- CLS — the banner renders in a fixed position and doesn't reflow your content.
- INP — third-party scripts that would otherwise tie up the main thread don't run until (and unless) consent is given.
The honest trade-off: the loader itself is synchronous, so it occupies a small slice of main-thread time up front. It's a single, self-contained file with no blocking network dependency of its own, and the cost of running it is far smaller than the tracker execution it defers — which is the whole point.
Relationship to script blocking
The loader is how the banner gets on the page; script blocking is what it does while it's there. The blocking mechanism — intercepting dynamically created script tags so trackers can't slip through — is covered in Concepts → Script Blocking.
