A cookie banner can slow your site, but the banner is rarely the expensive part. The script that draws it is small. The cost arrives the moment someone accepts, when every analytics, advertising and session tool the banner was holding back fires at once, on one main thread, after your page has already painted.
Two different things get called "the banner"
When somebody says their cookie banner slowed the site down, they are usually describing one of two different costs, and the difference decides what to do about it.
The first is the consent layer itself: one script that decides whether to show a dialogue, draws it, stores the answer and broadcasts it. That work is genuinely small. A consent script is a dialogue and a bit of state, and the well built ones load asynchronously and reserve their own space.
The second is everything the consent layer was gating. Your tag manager, analytics, advertising pixels, session replay, chat widget. None of it ran while the visitor was deciding. All of it runs the instant they accept, and because the release happens after the page has painted, it lands on a main thread the visitor is already trying to use.
Which means something most performance advice skips: a visitor who rejects gets a materially faster page than one who accepts. You are not serving one site. You are serving two, and your monitoring is averaging them.
The four ways a banner genuinely costs you
The mechanisms are well documented, and all four are fixable.
Render blocking. A consent script loaded without async or defer holds the parser while it fetches. That delay lands before your page can paint anything, including on repeat visits where the answer is already stored and the banner will never appear.
The banner becomes your Largest Contentful Paint. If it covers a large share of the viewport and arrives later than your hero, the browser measures the banner instead of your content. Google's threshold is 2.5 seconds, and a banner painting at 3 seconds has just decided your score.
Layout shift. A banner injected into the document flow rather than laid over it pushes everything below it down. Cumulative Layout Shift is supposed to stay under 0.1, and a full width bar appearing half a second late will spend that budget on its own.
The accept click itself. When the consent handler initialises four vendors synchronously, the click that dismisses the banner freezes the page. Interaction to Next Paint is meant to stay under 200 milliseconds. People notice this one without knowing its name, because it is the one that feels broken.
Why your PageSpeed score cannot see the expensive path
Here is the gap in almost every article on this subject. Lighthouse and PageSpeed Insights load your page in a clean profile with no stored consent, take their measurements, and stop. They never click anything. So the state they measure is the pre choice state: your page, plus a banner, with the entire tag stack still gated behind a button nobody pressed.
That is a legitimate view of a first time visitor. It is also the cheapest page you serve. The accept path, the heaviest state your site has, never appears in the lab score at all, so teams optimise the one number they can see while the expensive path goes unmeasured for years. You have to go and look at it deliberately, and it takes about ten minutes.
How to measure your own banner, both paths
Get a baseline with the banner switched off
Trace the page with the consent script blocked entirely, in your browser's request blocking panel. This is the floor. Without it you cannot tell the cost of consent apart from the cost of what consent releases.
Measure the state a first time visitor sees
The default PageSpeed Insights run: fresh profile, no stored choice, banner on screen. The difference from the floor is the honest cost of the banner itself, and on a well built one it is small.
Record the accept path by hand
Open the performance panel, start recording, load the page, click accept, and keep recording for a few seconds. Now you can see what actually lands: how many requests the choice triggers and how long the main thread stays blocked. No automated score will show you this, which is why so few people have looked at it.
Record the reject path too
Repeat the trace and click reject. On a site with Consent Mode v2 wired you should still see Google requests leaving, carrying no identifiers. That is the design working as intended, not a leak, and it is worth confirming with your own eyes before anyone tells you otherwise.
Split your field data by consent state
Lab traces tell you what can happen; field data tells you what does. Monitoring blended across all visitors averages a fast reject path with a slow accept path and hides both. If yours can carry a custom dimension, stamp the consent state onto it and read the two populations apart.
What Consent Mode changes, and what it does not
Much guidance still describes consent as a hard switch: no script runs until the visitor says yes. That is how a blocking consent layer behaves, and not how a site running Consent Mode v2 behaves at all. Under advanced Consent Mode, Google's tags load on every page regardless of the answer; the signal changes what they may store and send, not whether they exist. So if your plan for a faster site was to gate Google's tags behind consent, the weight does not go away. Only removing a tag removes its cost.
The trade is worth naming honestly, because it is the actual reason to accept that weight. Wiring the v2 signals is what lets Google model the conversions a rejection would otherwise erase, which in Amplio Data's client work recovers somewhere in the range of 20 to 40 percent of the measurement a consent banner costs you. Those are measured ranges across Amplio Data client implementations, not a guarantee. Recovery depends on your traffic mix, regions and how your tags are configured. A blocking setup is a slightly faster page that reports less of what happened on it.
The floor you cannot optimise away
Some of this cost is permanent, and pretending otherwise is how vendors promise things they cannot deliver. You will always pay for the script that decides whether to show a dialogue, for reading the stored answer before your tags initialise, and for the tags you genuinely need.
What you can remove is the rest: the synchronous load, the late injected bar with no reserved space, the four vendors initialising on one click, the tag nobody has looked at since 2023. In our experience that last one is usually the biggest win available, and it has nothing to do with consent.
Speed matters for a second reason too, which we cover in raising accept rates without dark patterns: a banner that lags gets dismissed out of impatience rather than preference.
Velo's own approach is the boring one. Serve the consent layer from the edge, keep it asynchronous, reserve its space so nothing moves, and hand the choice to your tags fast enough that nothing downstream waits. The interesting engineering belongs in what happens after the answer, not in the dialogue that collects it.
Common questions
Do cookie banners slow down your website?
A cookie banner can slow your site, but the banner script is rarely the expensive part. Most of the cost arrives after someone accepts, when the analytics, advertising and session tools the banner was holding back all initialise at once on the main thread. A small banner loaded asynchronously, with reserved space so it does not push content around, adds very little on its own.
Do cookies themselves slow down a website?
No. Cookies are a few hundred bytes travelling on requests you were already making. What people experience as cookie slowdown is the third party JavaScript that sets them: tag managers, analytics, advertising pixels and session replay. Removing a cookie changes nothing about page speed; removing the script that writes it changes a lot.
Does a cookie banner hurt SEO or Core Web Vitals?
It can affect Core Web Vitals, which are a ranking signal. A banner injected after the page paints causes layout shift, a synchronously loaded one delays paint, and a heavy consent handler on the accept click hurts responsiveness. None of those are inevitable. Crawlers are not shown a banner and never click one, so the banner itself does not block indexing.
Can a cookie banner become the LCP element?
Yes, and more often than people expect. If the banner covers a large share of the viewport and paints later than your hero content, the browser measures the banner as your largest contentful paint. The fix is to keep it small enough or early enough that it never becomes the biggest thing on screen at the wrong moment.