Cookie banners are the only part of a website designed by three groups who want different things. Legal wants coverage. Marketing wants the accept rate. Design wants it gone. The result is usually a heavy pop-up that annoys visitors, slows the page, and still does not do what the law asks.
We inherit these constantly. A banner bolted on in an afternoon, wired to a script that loads before anything else on the page, blocking the hero image while a visitor stares at a grey box. It is the worst first impression a site can make.
Worth saying plainly up front: we build websites, we are not lawyers, and nothing here is legal advice. What we can do is show you what the regulators have actually published, and how to implement it without wrecking your load time.
The core requirement is real consent, not a notice. The GDPR defines consent in Article 4(11) as "any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data."
Read that definition slowly, because every word does work. "Freely given" rules out banners where accepting is the only real path forward. "Specific" rules out one switch covering every purpose at once. "Unambiguous" and "clear affirmative action" rule out treating a scroll or continued browsing as a yes.
The practical consequence is the one most sites get wrong. Consent has to come before the cookies are set, not alongside them. The French regulator CNIL lists exactly this as a violation, describing cookies subject to consent that "were automatically deposited on the user's terminal before acceptance by the user, upon arrival on the site."
Enforcement is not theoretical. In its own reporting on the campaign, the CNIL says it has issued around 90 orders since May 2021, gives organisations one month to comply, and notes that violations can draw fines of up to 2% of annual worldwide turnover.
Cookies that are strictly necessary to deliver the service the visitor asked for generally do not need consent. Everything else does. A session cookie keeping someone logged in, or a cookie remembering what is in a shopping cart, is doing the job the visitor came for. An advertising pixel is not.
Analytics is where teams argue, and it is worth being honest about it. Analytics is not necessary to deliver a web page to a visitor. It is necessary for you. That is a real distinction, and it is why most European guidance treats analytics as something requiring consent rather than something exempt.
Our advice is to inventory before you implement. Open the browser tools, load your site in a clean profile, and write down every cookie and every domain that gets contacted. Most teams find scripts nobody remembers adding, which is a security question as much as a privacy one, and something we cover in our guide on keeping a business website secure.
Once you have the list, sort it into what the site genuinely needs and what somebody once wanted. The second pile is usually larger. Deleting a tracker is faster than getting consent for it, and it makes the site quicker at the same time.
The most common failure is making refusal harder than acceptance. The CNIL states the principle directly in the title of its own enforcement notices: refusing cookies should be as easy as accepting them. If accepting is one click and refusing takes three, the banner has a problem.
The second failure is a refusal button that does not work. The CNIL specifically calls out mechanisms where a refusal option exists but "cookies subject to consent are still deposited after the refusal expressed by the user." A banner is not a compliance artifact. It is a control, and the control has to be wired to something.
The third failure is setting cookies before anyone clicks anything. This is the default behaviour of most tag managers unless you configure them otherwise, which is why a banner installed without touching the tag setup usually changes nothing about what actually fires.
The fourth failure is treating consent as permanent. People change their minds, and withdrawing consent is supposed to be as simple as giving it. In practice that means a persistent way back into the settings, not a one-time banner that never returns.
Dark patterns are design choices that push people toward accepting without technically removing the choice. Regulators have moved from describing them in general terms to naming them precisely, which means the design decisions on your banner are now the compliance question.
The CNIL's formal notice to website publishers, issued on 12 December 2024, is the clearest list we have seen. It calls out banners where "the reject option is presented in the form of a clickable link whose choice of color, font size, and font style disproportionately emphasizes the acceptance option over the reject option."
The same notice names three more. A reject option "so embedded in the information that it is not readily apparent". A reject option placed next to other paragraphs "without sufficient spacing to visually distinguish it". And banners where "the accept option is presented multiple times in the banner, while the reject option is presented only once and in non-explicit terms."
The European Data Protection Board has also worked on this ground, publishing its Report of the work undertaken by the Cookie Banner Taskforce on 18 January 2023. The broader point for anyone designing a banner is that the styling is not cosmetic. A grey text link next to a bright button is a documented enforcement target.
Our design rule is simple and it removes the whole argument. Give accept and reject the same size, the same weight, the same colour treatment, and the same position in the layout. If someone on the team objects that this will lower the accept rate, that is the objection the regulators are describing.
A consent platform is a third-party script that has to run before almost anything else, which makes it one of the most expensive scripts on a site by position alone. It blocks, it renders a large overlay, and it often pulls a configuration file from another domain before it can decide what to show.
The cost is not just the file size. The banner usually appears above your hero content and shifts the layout when it loads, and it delays the scripts waiting behind it. That combination hits the metrics Google actually measures, which is why we treat the consent tool as a performance decision and not just a legal one.
There are practical ways to reduce the damage. Self-host the script where the vendor allows it, so you are not paying for a fresh connection to another domain. Preconnect to that domain if you cannot. Make sure the banner is styled with CSS you control rather than waiting on a remote stylesheet. Our guide on fixing render-blocking resources covers the sequencing in more depth.
The deeper fix is to have fewer things to consent to. Every tracker you remove is one less script, one less consent category, and one less thing to explain. We have never seen a site get slower by deleting trackers, and the broader cost of these scripts is something we broke down in our piece on how third-party scripts slow down your website.
Consent Mode is how you tell Google tags what a visitor agreed to, so those tags change their behaviour instead of being blocked outright. Google's own tag platform documentation describes it as a way to control data collection based on user consent for advertising and analytics purposes.
There are four parameters to know. Google documents ad_storage for advertising cookie storage, analytics_storage for analytics collection, ad_user_data for sending user data related to advertising to Google, and ad_personalization for personalised advertising. The last two were added when consent mode was updated in November 2023.
If you run Google Ads or Google Analytics and you have visitors in the European Economic Area, this is the mechanism Google expects you to use, and its documentation ties it to Google's EU user consent policy. Your consent platform almost certainly supports it, but support is not the same as being configured.
One implementation detail matters more than the rest. Google's guidance recommends setting your default consent states by region rather than globally, and applying a denied default only to visitors from the region that requires it. Setting everything to denied worldwide is a common overcorrection that quietly costs you measurement everywhere else.
Use an established platform if you operate in Europe or handle anything sensitive. Build your own only if your needs are genuinely simple and you are prepared to maintain it. The reason is not technical difficulty. It is that the rules keep moving, and a vendor's job is to track that.
Tools like OneTrust, Cookiebot, and Usercentrics handle the parts that are tedious to build correctly: scanning your site for cookies, keeping a record of what each visitor consented to and when, and updating the categories as regulations change. The consent record is the part homegrown solutions almost always skip, and it is the part a regulator asks for.
A homegrown banner is defensible in narrow cases. A small site with no advertising, no third-party analytics, and only strictly necessary cookies may not need a banner at all, which is by far the best outcome available. The fastest, cleanest, most compliant cookie banner is the one you do not have to show.
What we would not do is pick a platform on price alone and leave it on defaults. Most of these tools ship with a configuration that is convenient rather than compliant, and the default styling is usually the exact accept-emphasising design the CNIL described.
Test in a fresh browser profile with no history, because your own browser already has consent stored and will lie to you. Load the site, open the browser tools, and look at what has already been set before you touch anything. If advertising or analytics cookies are present at that moment, the banner is decorative.
Then click reject and check again. Reload the page and check a third time. The pattern we see most often is a banner that honours the refusal on the first page and quietly forgets it on the second, usually because the tag manager was never wired to the consent state.
Check the accept path too, since a banner that blocks everything even after consent is its own kind of broken. Marketing teams discover this months later when they notice a conversion tracking gap, and by then the data is gone.
Run this test after every significant site change. Consent breaks silently. Nobody files a bug report saying the cookie banner stopped blocking things, because from the outside it looks exactly the same as when it worked.
Start with an inventory, not a banner. List every cookie and third-party domain your site touches, delete the ones nobody can justify, and only then decide what needs consent. Most sites can cut this list meaningfully, and every deletion makes both the compliance and the performance problem smaller.
After that, fix the two failures regulators name most often. Make reject exactly as easy and as visible as accept, and make sure nothing that needs consent fires before someone gives it. Those two changes cover most of what the published enforcement notices describe.
Then treat it as maintenance. Re-scan a few times a year, because new tools get added and each one arrives with its own cookies. A consent setup that was correct at launch drifts out of date the same way everything else on a site does.
If your banner is slowing your site down, or you are not sure whether it is doing anything at all, we are happy to take a look. Get in touch at phoenix.studio and we will tell you what is actually firing on your site, and what it is costing you in load time.
Tell us where you want to go. We'll tell you how we'd get you there.