Cookie Banner Performance and Page Speed

Does a cookie banner slow down your site?

Yes, a little, and anyone who tells you otherwise is selling something. A consent banner is a file your visitors did not previously download, run by code that did not previously run. The useful question is not whether it costs anything but how much, where, and whether any of it lands on the part of the page your visitor is waiting for.

Three things are inside a vendor's control: how large the file is, how many further requests it has to make before it can show anything, and whether the browser has to stop and wait for it. Everything else on this page is those three, with numbers attached.

Cost one

Bytes across the wire

Each new visitor downloads the script once, then it is cached and costs nothing again. The size matters least on office broadband and most on a mid-range phone with a weak signal, which is exactly the visitor most likely to give up on a slow page.

Cost two

Round-trips before anything happens

This is the one people underestimate. A script that has to ask a server for its own settings cannot start that second request until the first has finished, so the two delays add up rather than overlap. Bytes you can compress. Latency you cannot.

Cost three

Interference with the page itself

A banner that injects stylesheets into your page, or that pushes your content down when it appears, damages how the page feels rather than how it scores. Visitors notice content that jumps long before they notice a slow number in a report.

There is also an effect that runs the other way, and it is worth knowing about. For a visitor who refuses, a consent layer usually removes more requests than it adds, because the analytics and advertising tags it holds back never load at all. That is how script blocking works, not a promise about your particular site, and the only way to know the net effect on yours is to measure it.

The specification, measured on the file we actually ship

Almost every consent vendor describes its script as lightweight, which is a word rather than a measurement. Here is ours, taken with ordinary command line tools on the exact file your visitors receive.

Measured size and loading characteristics of the Kukie cookie banner script
Measurement	Value	What it means for your page
Script, uncompressed	about 83 KB	The size on disk. Nobody downloads this, and it is listed because quoting only the flattering number is how vendors avoid being checked.
Transferred, gzip	about 25 KB	What a visitor downloads on a connection that negotiates gzip. This is the figure to compare against other vendors.
Transferred, Brotli	about 21 KB	What a visitor downloads where the browser accepts Brotli, which most current browsers do.
Loading strategy	async	The browser fetches it alongside your page rather than stopping to wait, so it is never render-blocking.
Configuration requests before render	none	Your settings are compiled into the bundle at build time. There is no settings endpoint left to call.
Delivery	per-site bundle on a global CDN	Your own file, cached close to your visitors rather than fetched from one origin server on the other side of the world.
Style isolation	closed Shadow DOM	No stylesheet is added to your page, and your theme cannot reach inside the banner. Isolation runs both ways.
Installation	one script tag	No build step, no bundler, no package to keep up to date. Updates arrive through the bundle.

Your file is this file, plus your settings

The figures above are the base script. Your bundle is that script with your own configuration written into it, so it is slightly larger in proportion to how much banner text, how many languages and how many catalogued cookies you have. A busy configuration adds bytes; it never adds a request.

Measured in July 2026, and corrected when it moves

Software gains weight as it gains features, and a size published once is stale within a release or two. When these numbers change, this page is corrected to the new measurement rather than quietly rounded down to the old one.

Script, then render. Not script, then config, then render.

This is the single biggest difference between one consent script and another, and it is invisible in a size comparison. Most consent scripts are generic: the same file goes to every customer, so on arrival it has to ask the vendor's servers which settings belong to this site. Kukie builds a separate file per site with the answer already in it.

Two round-trips

The common pattern

The page asks for the consent script.
The script arrives and asks a server which settings this site uses.
The settings arrive. Only now can a banner be drawn.

Step two cannot begin until step one has finished, so the two waits are stacked end to end rather than overlapping. Whatever the visitor's connection costs in latency, they pay it twice.

One round-trip

How a Kukie bundle loads

The page asks the CDN for your site's own bundle.
Your settings are already inside it, so the banner can be drawn the moment it arrives.

There is no step three, and there is no endpoint behind it. The configuration endpoint this product once had was removed entirely in July 2026, so it cannot be called by accident, by an old cached script, or by a future change.

<script src="https://cdn.kukie.io/s/YOUR_SITE_KEY/c.js" async></script>

One line. That is the whole installation.

Per-region behaviour is handled the same way. Every rule you have written is compiled into the same bundle and matched in the browser, so no region ever downloads a second, region-specific configuration. A site using geo-targeted rules does make one short lookup to establish which country the visitor is in, because a browser cannot supply that on its own, and if that lookup does not answer promptly the banner falls back to your default rule instead of waiting.

What is a Shadow DOM, and why does it matter here?

A Shadow DOM is a sealed fragment of a web page with its own styles. Styles declared inside it do not escape into the surrounding page, and styles from the surrounding page do not get in. The whole Kukie banner is built inside one.

It is a browser feature rather than a trick, so the isolation is enforced by the browser instead of by a wall of overrides in someone's stylesheet.

Your theme cannot break the banner

A global rule that makes every button uppercase, a CSS reset, an inherited line height, a framework that restyles every list: none of it reaches inside. The banner looks the same on a hand-built site as it does on a heavily themed one.

The banner cannot break your theme

Nothing is added to your stylesheet, no font is imported into your page and no element of yours is restyled. This is the half site owners forget to ask about, and the half that creates work for a designer six months later.

Less style matching for the browser

The banner's rules are scoped to its own root, so the browser is not testing them against every element on your page. A consent layer that ships broad global selectors makes work for every element you have, not just its own.

Drawn over your page, not into it

The banner is positioned above your content rather than inserted into the flow of it, so your text and images are not pushed down the page when it appears. Nothing you had already laid out moves to make room.

Isolation is not the same as being stuck with our design. Colours, typography, your own logo, dark mode and right-to-left layouts are all set from inside your dashboard and travel into the shadow root as theme values. That side of it is covered on the customisation page, and the accessibility work that goes with it on the accessibility page.

Which Core Web Vitals can a cookie banner actually touch?

Core Web Vitals are three measurements Google takes from real visits to your site: how soon the main content appears, how much the layout moves about while it loads, and how quickly the page answers when someone interacts with it. A consent script can influence each of them, by different mechanisms and by very different amounts.

Largest Contentful Paint

How soon your main content appears

An async script does not hold up your page, but it does share the visitor's connection with the hero image or headline that decides this measurement. The lever here is file size, which is why the number at the top of this page is stated rather than described.

Cumulative Layout Shift

How much your content jumps

Layout shift happens when something is inserted into a page and pushes what was already there. The banner is drawn over your content at a fixed position instead, so appearing does not move anything you had laid out.

Interaction to Next Paint

How quickly the page answers a click

The busiest moment in a consent layer is the click on accept, when every held-back tag is released at once. On a page with a lot of tags that is real work, and it is worth checking on a mid-range phone rather than on your laptop.

None of that adds up to a promise, and you should be wary of any consent vendor who offers one. Core Web Vitals belong to a page, not to a script: they are measured on your layout, your images, your hosting and your other third parties, on the real devices your real visitors use. That is why this page gives you a file size and the shape of the loading sequence instead of a score taken on somebody else's website.

How to check every claim on this page yourself

None of this requires a testing tool or a developer. Four checks in your own browser will confirm or contradict everything above, and they work just as well on a competitor's banner as on ours.

1

Read the real transferred size

Open your site, open your browser's developer tools, choose the Network panel and reload the page. Find the consent script in the list and read the transferred column. That is the number your visitors actually pay, compression included.
2

Confirm nothing is waiting for it

View the page source and find the consent script tag. If it carries the word async, the browser downloads it in parallel and never pauses your page for it. If it carries neither async nor defer, your page is waiting.
3

Count what the script asks for next

In the same Network panel, look at what the consent script requests after it loads and before the banner appears. A settings or configuration request there is a second round-trip your visitors wait through on every first visit.
4

Measure your own page, before and after

Test the page with whatever tool you already use, add the banner, and test it again on the same device and connection. That comparison is worth more than any vendor's published figure, ours included.

While you have the Network panel open, it is worth seeing how much else your page loads. The free third-party script audit lists the third-party scripts running on a public page of your site, and on most sites the consent script is far from the heaviest thing in the list.

When the weight of a consent script is worth caring about

For a brochure site on a decent host, 25 KB is not the thing standing between you and a fast page. These are the cases where it genuinely is worth the attention.

Most of your visitors are on phones

A file that is invisible on office broadband is not invisible on a congested mobile network, and the round-trip point matters more than the size point there, because latency on a mobile connection is what hurts. Two sequential requests on a slow connection are noticeably worse than one.

Your page is already borderline

If your Core Web Vitals sit just inside the threshold, everything you add is a candidate for tipping them out. The right response is not to avoid consent, which is rarely optional, but to add it with your eyes open and re-measure afterwards.

You are ad-funded or conversion-sensitive

Publishers and shops already carry the heaviest third-party payload on the web. A consent layer changes the arithmetic in both directions at once: one more file for everyone, and a good many fewer for every visitor who refuses. Read that alongside the banner itself rather than in isolation.

You install the same script on many sites

An agency puts one decision in front of every client at once, and gets asked about it by every client whose developer notices a new script. A published measurement and a one-line embed answer that conversation faster than a support ticket. Multi-site management is on the agencies and teams page.

The bundle, the CDN delivery and the Shadow DOM isolation are how every Kukie site loads, on every plan, because there is no other embed to choose from. What differs by plan is how many sites, how many pages a scan covers and how long consent records are kept, which is set out on the pricing page. Kukie provides the technical infrastructure for consent management; whether your site is compliant depends on how you configure it and may need additional legal measures specific to your organisation.

Performance questions

What site owners ask before they add a consent script to a page they have spent months making fast.

Does a cookie banner slow down my site?

Every third-party script costs something, so the honest answer is that a consent banner is never free. What differs between vendors is how much. Three things decide it: the size of the file, whether the browser has to wait for it before drawing your page, and how many further requests it makes before it can show anything. Kukie ships about 25 KB gzipped, loaded asynchronously so nothing waits on it, with your settings already inside the file.

How big is the Kukie cookie banner script?

The base script is about 83 KB uncompressed, about 25 KB when the server sends it with gzip, and about 21 KB where the browser accepts Brotli. Your visitors download the compressed figure, once, and then it is cached. Your own bundle is that file plus your configuration, so it is slightly larger depending on how much banner text and how many cookies you have set up.

Does a cookie banner affect Core Web Vitals?

It can touch all three, in different ways and by different amounts. A large script competes for bandwidth with the images that decide how soon your main content appears. Anything inserted into the page can push content around and register as layout shift. Releasing held-back tags the moment a visitor accepts is real work on the main thread. How much any of that matters is measured on your page with your visitors, not quoted from a vendor page.

Is the Kukie consent script render-blocking?

No. The embed carries the async attribute, which tells the browser to fetch the file alongside the rest of the page instead of stopping to wait for it. Your HTML keeps parsing and your content keeps drawing while the consent script downloads in parallel. That is a property of how the script is loaded rather than a setting, so it applies to every Kukie installation.

Does the banner have to fetch its settings before it can appear?

No. Each site gets its own bundle from the CDN with the configuration compiled inside it at build time, so the sequence is script then render rather than script, then config, then render. The old configuration endpoint was removed entirely in July 2026, so there is nothing left to call. Sites using per-region rules make one short lookup to establish the visitor country, because a browser cannot supply that on its own, and the rules themselves are already in the bundle.

Will the cookie banner interfere with my own CSS?

No, and the isolation runs in both directions. The banner is rendered inside a Shadow DOM, a sealed fragment of the page with its own styles. Nothing your theme declares reaches inside it, and nothing it declares leaks out into your page. There is no global stylesheet added to your site, no reset applied to your elements, and no font override for your designer to work around later.

Cookie banner performance,
in numbers you can check yourself

Does a cookie banner slow down your site?

The specification, measured on the file we actually ship