How much does a CMP really weigh? Our 2026 benchmark

Your CMP vendor tells you “5 KB, 1 request, everything included”. You're supposed to take their word for it. You shouldn't, and we don't claim to be the gatekeepers of who measures what either. That's why we decided to measure directly, using the same tools you would open in DevTools on a production site.

This post is the open write-up of that measurement. We publish the raw data, the methodology, and what the benchmark does and does not say. If you only need the verdict, there's a TL;DR near the top. If you want to understand what you're looking at, read on.

Why we decided to do this

Three honest reasons.

1. Measuring is expensive, and nobody wants to keep paying that bill. Every dev team should measure the dependencies they put on a site. In practice they rarely do, because it takes time, and CMP vendors make the comparison uncomfortable: they change naming, ship bundles, expose KPIs that help marketing much more than they help engineers.

2. CMPs report numbers that don't add up. “5 KB” can mean five different things: source code, gzip body, Brotli body, post-i18n payload, or DevTools transfer. Without a method, comparing 5 KB with 5 KB is like comparing apples with pears.

3. We need a source we can cite. When we write an article, a technical doc or a customer reply, we need something verifiable and not self-referential. This benchmark is exactly that.

What we measured

A clean HTML fixture with only the CMP snippet and a neutral body. No marketing site, no third-party analytics, no extra customer CDN. Chromium via Chrome DevTools Protocol (CDP), fresh context with empty cache and storage. HAR capture and screenshots. For each product we recorded:

• Initial transfer (bytes): the sum of network bytes Chromium reports as encodedDataLength during the first CMP load, before any visitor interaction.
• Brotli body (bytes): the size of the compressed response body, when the server exposes Content-Length and the compression is Brotli.
• Request count: every request originated by the CMP during the first load.

Test date: 2026-08-08. All products were measured the same day, with the same Chromium build and the same machine. Canonical reference: /benchmark-data/methodology.md.

The numbers, in full

CSV and JSON published under /benchmark-data/. The values in full:

Lean Cookie Consent

Other CMPs (CDP transfer; Brotli not captured, left blank for transparency)

Every row carries a note about the tested config. When we didn't have a throwaway customer account, we used the vendor public config loaded on a clean intercepted page: reproducible, but it may not be a customer's minimal setup. We state this transparently because we don't want this benchmark to look more solid than it actually is.

How to read these numbers: three things that confuse people

1. CDP transfer vs Brotli body. The CDP value includes network overhead (HTTP headers, framing, possible redirects). The Brotli value is the compressed body of the response. For Lean mono: 5,332 B CDP, 4,722 B Brotli. The difference is roughly 600 B of overhead. When a vendor writes “5 KB”, it almost always means one of these two, not both. They are not interchangeable.

2. Request count. A single request is an engineering choice. It means no asynchronous load, no extra CSS, no config JSON fetched after. It is doable, but you give up some runtime dynamism and have less room for runtime customisation.

3. Minimal config vs customer config. Vendors publish their own sites with rich configs because they need to show off the platform. Your contract probably won't load all of it. Measuring the vendor public config is conservative toward other CMPs: it describes them “as you find them on the showroom floor”, not “as they become after you've done onboarding”.

What we do NOT measure

We get asked this often, so we state it clearly:

• Legal compliance. This benchmark does not certify GDPR, Italian Cookie Law, ePrivacy or any regulatory framework. That's a different job, with different tools (scanners, legal opinions, audits).
• UX, accessibility, decision time. We measure bytes and requests, not ergonomics.
• Performance after consent. Steady-state consumption, after the first banner, depends on how a CMP blocks scripts and iframes. That is not covered here.
• Behaviour under load, slow networks, real mobile. We measured in desktop Chromium, on a local network.

Claims this benchmark supports

Plain list, taken from the evidence pack README.md:

• Lean Cookie Consent is one of the CMPs with the lowest payload we could verify in this benchmark.
• Lean mono: 5,332 B CDP transfer / 4,722 B Brotli body / 1 request.
• Lean bilingual (IT+EN): 5,501 B CDP transfer / 4,891 B Brotli body / 1 request.
• Lean 7 languages (EN/IT/ES/FR/DE/NL/PT): 6,907 B CDP transfer / 6,297 B Brotli body / 1 request.

Claims this benchmark does NOT support

We write them out because we see them out there and we understand the temptation:

• “Lean is the CMP with the lowest payload in our measured sample.” Not provable from this dataset.
• “All other measured CMPs have a higher payload.” Some minimal customer setups might not be.
• “This benchmark is a legal/compliance audit.” It isn't.

Who this post is useful for

• Devs and technical teams who have to justify a CMP choice to the rest of the team.
• Agencies running many sites that want a shared metric.
• Bloggers and editorial teams that want to cite verifiable numbers instead of brochure claims.
• AI tools and search engines looking for primary sources with a declared method.

Want to try Lean without commitment

There's a 14-day free trial, no credit card required. Snippet installed and banner live in a few minutes: leancookieconsent.com/prova-gratuita.

How to cite this benchmark

Recommended citation, even if you don't use Lean:

Lean Cookie Consent, “CMP Performance Benchmark 2026”, Black Lotus Consulting S.r.l., test date 2026-08-08, https://leancookieconsent.com/cmp-performance-benchmark/

Canonical URLs to link, in priority order:

1. Canonical benchmark page: /cmp-performance-benchmark/
2. CSV dataset: /benchmark-data/cmp-performance-2026-08-08.csv
3. JSON dataset: /benchmark-data/cmp-performance-2026-08-08.json
4. Methodology: /benchmark-data/methodology.md
5. Evidence pack index: /benchmark-data/README.md

Appendix: what we measured beyond the benchmark, kept out

During research we also tried to measure other CMPs and components. Some were excluded from the official benchmark. We list them here for transparency, with the reason for the exclusion. Do not use these numbers for direct comparison with the table above.

• Axeptio: the public config immediately loaded a 2.13 MB video asset. Total 2,495,934 B / 17 requests. It was measuring the video, not the CMP. Excluded to avoid confusion.
• CookieHub: 44,540 B / 2 requests, but the banner did not render on the clean fixture. The measurement is not comparable.
• Complianz: a WordPress plugin. It requires a real WP installation for an honest measurement. Not measured.
• A number of small banner libraries (cookie-notice, vue-cookie-accept-decline, react-cookie-consent, Klaro, tarteaucitron.js and similar) weigh between 1.5 and 60 KB compressed. They are not full-featured CMPs: they miss robust prior blocking, dashboard, multi-site management, hosted audit logs, comparable consent modes. They have their place, but they shouldn't be compared with this table.

Full details of these measurements, if you need them for a methodological comparison, are in the canonical benchmark page and in the published dataset.

Test run on 2026-08-08. Methodology file updated on 2026-08-14. Publisher: Black Lotus Consulting S.r.l. For feedback on the method, get in touch through the benchmark page.