Why This Website Has No Cookie Popup (And Yours Might Not Need One Either)
Web Applications 8 min read

Why This Website Has No Cookie Popup (And Yours Might Not Need One Either)

admin
admin
Plausible Analytics dashboard showing website traffic data collected without cookies or personal data

You’ve probably noticed something missing from this website. No cookie popup. No consent banner sliding in from the bottom of the screen. No “Accept All” button competing for your attention before you’ve read a single word.

That’s deliberate. And it’s entirely legal.

Cookie popups have become so ubiquitous that most people assume they’re a universal legal requirement — that every website must show one. They don’t. The requirement depends on what your website actually does, and if you make the right technical choices, you can avoid needing one entirely.

Here’s exactly how we did it, and why more websites should do the same.

Why Cookie Popups Exist in the First Place

Cookie consent banners exist because of two overlapping pieces of European legislation: the ePrivacy Directive (2002, updated 2009) and the General Data Protection Regulation (GDPR, 2018). In the UK, the relevant implementation is the Privacy and Electronic Communications Regulations (PECR), which works alongside the UK GDPR.

The rules are actually more specific than most people realise. You need consent before placing cookies on a user’s device — but only non-essential cookies. The legislation explicitly exempts cookies that are “strictly necessary” for the service the user has requested. Session cookies that keep you logged in, shopping basket cookies, load-balancing cookies — these don’t require consent.

The cookies that do require consent are the ones most websites don’t think twice about adding: analytics tracking cookies, advertising cookies, social media pixels, personalisation cookies, and any third-party cookies that track users across sites.

The moment you install Google Analytics, you’ve placed a cookie that tracks user behaviour across sessions and potentially across websites. That triggers the consent requirement. Which triggers the cookie banner. Which triggers the JavaScript for the cookie management platform. Which triggers the irony of making your website slower and more annoying in order to track how people use your website.

Everyone Hates Them. The Data Proves It.

Cookie popups are one of the few things that unite the entire internet in shared frustration.

A 2020 study published at CHI (the leading academic conference on human-computer interaction) found that less than 0.1% of users actively engage with cookie consent settings in a meaningful way. The overwhelming majority either click “Accept All” immediately — defeating the purpose of informed consent — or ignore the banner entirely and navigate around it.

Subsequent research has been even more damning. Users report cookie banners as one of the most frustrating elements of web browsing. They don’t read them. They don’t understand them. They click whatever makes the popup go away fastest. The banners have trained users to perform a mechanical dismissal action rather than make an informed choice about their privacy.

And the technical cost is real. A typical cookie consent management platform (OneTrust, Cookiebot, CookieYes) adds 30–80KB of JavaScript to your page. That script needs to load and execute before other scripts can fire, because it needs to block analytics and advertising scripts until consent is obtained. It adds latency to every single page load. For what? A dialogue box that almost nobody reads and that creates a worse first impression of your website.

There’s a deeper problem too. The cookie consent ecosystem has created a false sense of compliance. Many implementations are technically non-compliant — they use dark patterns (“Accept All” is a big green button, “Manage Preferences” is a small grey link), they load tracking scripts before consent is given, or they treat continued browsing as implicit consent (which is not valid under GDPR). The ICO has been increasingly clear that these patterns don’t meet the standard.

So the industry’s collective response to privacy legislation has been to annoy users with a consent mechanism that doesn’t actually protect their privacy, while adding technical overhead that makes websites slower. Brilliant.

How We Avoided It: The Plausible Approach

Our approach was simple: don’t set non-essential cookies in the first place.

The biggest cookie culprit on most websites is analytics. Google Analytics — which is installed on an estimated 55% of all websites — sets multiple cookies (_ga, _gid, _gat) that track individual users across sessions. These are non-essential cookies. They serve the website owner’s interests, not the user’s. Under PECR and GDPR, they require explicit, informed, freely-given consent before they can be set.

We use Plausible Analytics instead.

Plausible Analytics dashboard showing website traffic data — all collected without cookies or personal data

Plausible is fundamentally different from Google Analytics in its approach to tracking. It doesn’t use cookies at all. It doesn’t collect personal data. It doesn’t track users across sessions or across websites. It doesn’t generate a unique user identifier. Every data point it collects is aggregate, not individual.

How does it work without cookies? Plausible generates a daily-rotating hash from the visitor’s IP address, the website domain, and the User-Agent string. This hash is used to count unique visitors on a given day, but it cannot be used to identify an individual, track them across days, or correlate their activity across different websites. The hash changes every 24 hours and is never stored in a retrievable form.

The result: Plausible is compliant with GDPR, PECR, CCPA, and ePrivacy by design. The European Data Protection Authorities have confirmed that privacy-preserving analytics tools that don’t use cookies and don’t collect personal data do not require consent. No cookies means no consent requirement. No consent requirement means no cookie banner.

The Plausible script is also less than 1KB — compared to 45KB for Google Analytics. It makes a single request to log the pageview. No external CDN dependency. No render-blocking behaviour. The performance difference is measurable.

What We Gave Up (Almost Nothing)

The natural question is: what analytics data do we lose by not using Google Analytics?

Plausible gives us pageviews, unique visitors, bounce rate, visit duration, referral sources, UTM campaign tracking, entry pages, exit pages, device types, browser breakdown, operating system, and geographic location at country level. We can set up custom events and goals.

What we don’t get: individual user journey mapping across sessions, demographic data (age, gender, interests), cross-device tracking, remarketing audience building, and the 400 other reports in Google Analytics that we never looked at.

We used approximately 5% of what Google Analytics offered. We use approximately 90% of what Plausible shows us. The data we actually act on — which pages are popular, where traffic comes from, whether a blog post or campaign drove visits — is all there. The data we lost was data we had but never used, collected at the cost of our visitors’ privacy and our site’s performance.

For most business websites, this trade-off is identical. Unless you’re running large-scale advertising campaigns that require remarketing audiences and cross-device attribution, Google Analytics is collecting data you don’t need at a cost you don’t realise you’re paying.

The Full Picture: Our Zero-Cookie Stack

Analytics was the biggest piece, but we reviewed every technology choice on this site through the lens of “does this set a non-essential cookie?”

  • Analytics: Plausible (no cookies)
  • Fonts: Self-hosted (no Google Fonts request, no Google cookies)
  • Videos: No embedded YouTube or Vimeo players on key pages (these set tracking cookies)
  • Social media: No Facebook pixel, no Twitter widget, no LinkedIn Insight tag (all set tracking cookies)
  • Contact form: Custom-built, no third-party form service
  • Maps: No embedded Google Maps (sets cookies; we link to directions instead)
  • Chat widget: None (these typically set session and tracking cookies)

The site does use cookies — but only strictly necessary ones. WordPress sets a session cookie if you log in to the admin area. That’s essential for the service to function and doesn’t require consent.

Everything else is cookie-free by design.

Should Your Website Do This?

If your website uses Google Analytics, Facebook Pixel, embedded YouTube videos, Google Fonts loaded from Google’s CDN, or any advertising/remarketing tags — you legally need a cookie consent banner. And if you have one, it should be properly implemented: no pre-ticked boxes, no “Accept” without an equally prominent “Reject”, no loading tracking scripts before consent is granted.

But before you invest in making your cookie banner compliant, ask a different question: do you actually need the things that require the cookies?

For most SME business websites, the answer is no. You don’t need Google Analytics — Plausible or Fathom will give you everything you act on. You don’t need Google Fonts from Google’s CDN — self-host them. You don’t need embedded social widgets — link to your profiles instead. You don’t need a chat widget — a contact form works fine.

Strip out the unnecessary tracking, and the cookie banner goes with it. Your website loads faster. Your visitors aren’t annoyed before they’ve read your first paragraph. And you’re more compliant with privacy legislation than 90% of sites that do show a cookie banner, because you’re not collecting the data in the first place rather than asking permission to collect it and hoping users click the right button.

Privacy by design beats privacy by consent dialogue every time.

If you’re interested in switching to a privacy-respecting analytics setup or want to understand what your website is actually doing with cookies, get in touch. We can audit your current setup and recommend practical alternatives that keep you legal without annoying your visitors.

Progressive web app versus native app comparison
Web Applications

Choosing Between a PWA and a Native App in 2026

PWAs have matured significantly. For most business applications in 2026, a well-built PWA outperforms native on cost, speed to market, and maintainability. Here's when each makes sense.

7 min read

Let's build something great

Tell us about your project and we'll get back to you within one working day. Based in Exeter, Devon — working with businesses across the UK.

Start a conversation