CMP Performance Benchmarks 2026: How Cookie Consent Scripts Affect Your Core Web Vitals

Cookie consent scripts run before anything else on your page. They load before your hero image, before your analytics, before your fonts. If your CMP is slow, your entire site is slow — and Google notices.

Since 2021, Core Web Vitals have been a confirmed ranking signal in Google Search. A consent script that adds 200 milliseconds to your page load doesn’t just annoy visitors — it pushes your LCP score into a worse bracket, degrades your INP, and can trigger layout shifts that tank your CLS. The result: lower rankings, fewer visitors, less revenue.

We tested six of the most widely used consent management platforms to measure their real-world impact on page performance. This post presents what we found, explains why the differences matter, and gives you the tools to run these tests yourself.

Methodology

We wanted results that reflect what actual visitors experience, not best-case lab conditions. Here’s how we structured the tests.

Test environment

Each CMP was installed on an identical test page: a standard marketing landing page with a hero section, three content blocks, two images, and a footer. The page itself (without any CMP) scored 98 on PageSpeed Insights for both mobile and desktop.

We tested each CMP in its default configuration — the setup a new customer would get after basic installation without additional optimization. This matters because many CMPs can be tuned for performance, but most users never change the defaults.

Tools used

• Chrome DevTools (Network tab, Performance tab, Lighthouse): For measuring transfer sizes, request counts, JavaScript execution time, and Core Web Vitals scores.
• PageSpeed Insights: For field data (Chrome User Experience Report) and lab data on both mobile and desktop.
• WebPageTest: For waterfall analysis, filmstrip comparisons, and detailed timing breakdowns from multiple geographic locations.

Connection throttling

All tests were run under two conditions:

1. Fast connection: Cable (5 Mbps down, 1 Mbps up, 28ms RTT) — representing a typical desktop user.
2. Slow connection: Regular 4G (9 Mbps down, 1.5 Mbps up, 170ms RTT) — representing a mobile user, which accounts for over 60% of global web traffic.

The 4G throttled results are what we focus on throughout this post, because that’s where CMP performance differences become most visible. On fast connections, even a heavy script loads quickly enough that the differences are hard to notice. On 4G, every kilobyte and every additional request is felt.

What we measured

For each CMP, we recorded:

• Transfer size (gzipped): The total bytes sent over the network for all CMP-related resources.
• Number of requests: How many HTTP requests the CMP makes during initial page load (script files, configuration fetches, tracking pixels, font files).
• JavaScript execution time: How long the browser’s main thread spends parsing and executing CMP JavaScript, measured via the Performance tab’s “Bottom-Up” view.
• INP impact: The responsiveness delay when a user clicks the “Accept All” button, measured as the time between the click event and the next paint.
• LCP delta: The difference in Largest Contentful Paint between the page with no CMP and the page with each CMP installed.
• CLS contribution: Whether the CMP caused measurable layout shift on page load.

Each measurement was repeated five times and averaged to reduce variance from network jitter or background processes.

Results

Here are the results from our 4G throttled tests. All numbers represent the median across five runs.

CMP	Transfer Size	Requests	JS Execution	INP Impact	LCP Delta	CLS
CookieBoss	~10 KB	1	<20 ms	Minimal (<50 ms)	+45 ms	0.000
Osano	~60 KB	2	40–60 ms	Low (50–80 ms)	+120 ms	0.000
Termly	~80 KB	2–3	50–80 ms	Low-Moderate (80–120 ms)	+180 ms	0.002
CookieYes	~90 KB	2–4	60–100 ms	Moderate (100–160 ms)	+220 ms	0.003
Cookiebot	~130 KB	3–5	80–120 ms	Moderate (120–200 ms)	+310 ms	0.005
OneTrust	~200 KB+	5–8	150–250 ms	Significant (200–400 ms)	+480 ms	0.012

Results vary by configuration and site context. These figures represent typical ranges observed during testing with default CMP configurations. Your results may differ based on the features enabled, banner design, number of cookie categories, and geographic proximity to CDN edge servers.

A few things stand out.

The size gap is enormous

The lightest CMP in our test (CookieBoss at ~10 KB) is 20 times smaller than the heaviest (OneTrust at 200 KB+). That’s not a rounding error — it’s the difference between a script that downloads in one TCP round-trip and a script that requires multiple round-trips, competes with your page’s own resources for bandwidth, and keeps the browser’s parser busy for a quarter of a second.

Request count compounds latency

Every additional HTTP request adds latency. Even with HTTP/2 multiplexing, each request carries overhead: DNS lookups (if the request hits a different domain), TLS handshakes, and server processing time. CookieBoss makes a single request for a single file. OneTrust makes five to eight requests across multiple domains — configuration files, script bundles, stylesheet fetches, and tracking pixels.

On a 4G connection with 170ms RTT, each additional request to a new domain can add 200–500 milliseconds of latency. Three extra requests to three different domains can push your total CMP load time past one second.

INP tells the real story

Transfer size and request count matter at load time. But INP — Interaction to Next Paint — matters after the page has loaded, when the visitor actually tries to use it.

When a visitor clicks “Accept All,” the CMP has to do several things simultaneously: store the consent preference, update the consent state, and fire every third-party script that was waiting for consent (analytics, ad pixels, remarketing tags, heatmaps). On a heavy CMP, this burst of activity can lock the main thread for 200–400 milliseconds. During that time, the page is frozen — scrolling stops, buttons don’t respond, animations stutter.

Google considers any INP above 200 milliseconds to “need improvement” and anything above 500 milliseconds to be “poor.” A CMP that adds 400 milliseconds to the accept interaction can single-handedly push your site into the “poor” INP bracket.

CookieBoss keeps this under 50 milliseconds because there’s almost no JavaScript to execute — the consent state update is a lightweight operation that doesn’t block the main thread.

Why script size matters more than you think

A common reaction to these numbers is: “My visitors have fast internet. A few hundred kilobytes doesn’t matter.”

This is wrong for three reasons.

Parse time scales with size

Downloading a JavaScript file is only half the cost. The browser also has to parse and compile it before execution begins. On a mid-range Android phone — the kind used by the majority of mobile users globally — the parse cost is roughly 1 millisecond per kilobyte of uncompressed JavaScript.

A 200 KB gzipped script decompresses to roughly 600–800 KB of raw JavaScript. That’s 600–800 milliseconds of parse time on a mid-range phone, before a single line of code executes. And this happens on the main thread, blocking everything else.

A 10 KB gzipped script decompresses to roughly 25–30 KB. Parse time: under 30 milliseconds. The difference is not marginal — it’s an order of magnitude.

Bandwidth is shared

Your consent script isn’t the only thing loading. The browser is also fetching your HTML, CSS, fonts, images, and other JavaScript. Every byte your CMP consumes is a byte that isn’t available for your actual content.

On a 4G connection with effective throughput of around 4 Mbps, a 200 KB script consumes approximately 400 milliseconds of download time. During those 400 milliseconds, your hero image, your web fonts, and your above-the-fold CSS are competing for the same bandwidth. The result: everything loads slower, not just the consent banner.

A 10 KB script consumes approximately 20 milliseconds of download time. It’s so small that it effectively doesn’t compete with anything.

The compounding effect

Performance costs compound. A heavy CMP doesn’t just add its own load time — it delays everything that comes after it. If your consent script takes 400 milliseconds to load and execute, your analytics scripts, ad scripts, and tracking pixels are all delayed by 400 milliseconds too. The total page load time increase is larger than the CMP’s individual contribution.

This is particularly damaging for consent scripts because they intentionally load early. A consent script that loads at the end of the page would have less impact (though it would also fail to block unconsented scripts). Because consent scripts must load first, their performance cost is multiplied across every other resource on the page.

The edge-compiled advantage

The reason CookieBoss is able to deliver a ~10 KB consent script while competitors ship 60–200 KB+ is architectural, not cosmetic. It’s not about minification or tree-shaking — it’s about fundamentally rethinking how consent scripts are built and delivered.

Traditional CMP architecture

Most consent management platforms work like this:

1. They ship a generic JavaScript bundle that handles every possible configuration: every banner layout, every language, every legal framework, every integration.
2. When the script loads in the visitor’s browser, it makes additional requests to fetch the site-specific configuration: which cookies to block, which categories to show, what text to display, which legal framework applies.
3. The script processes the configuration at runtime, dynamically builds the consent UI, and sets up the event listeners for consent interactions.

This approach is flexible — one script handles every customer — but it’s inherently heavy. The browser downloads code for features the site doesn’t use, fetches configuration that could have been embedded, and builds UI that could have been pre-rendered.

How CookieBoss works differently

CookieBoss takes the opposite approach: compile once, serve forever.

When a site owner configures their consent banner in the CookieBoss dashboard — choosing their banner layout, languages, cookie categories, and legal framework — that configuration triggers a compilation step on the server side. The compiler assembles only the code fragments needed for that specific configuration into a single, self-contained JavaScript file.

Here’s what happens during compilation:

1. Fragment selection: The compiler picks only the code modules required by the configuration. If the site doesn’t use IAB TCF, the TCF encoder and CMP API aren’t included. If the site uses one language, the multi-language switcher code is excluded. If the site uses a bottom-bar layout, the modal and top-bar code is excluded.
2. Configuration embedding: The site’s configuration (cookie categories, banner text, styling) is embedded directly into the compiled script as static data. No runtime configuration fetch is needed.
3. Dead code elimination: Because the configuration is known at compile time, code paths that can never execute for this specific configuration are removed entirely.
4. Single-file output: The result is a single JavaScript file — no separate stylesheets, no configuration endpoints, no additional requests. One file, one request, done.

The compiled script is then stored and served from Cloudflare’s R2 object storage, cached at 300+ edge locations worldwide. When a visitor loads the page, they get a single, pre-compiled file from the nearest edge server. No configuration fetch. No runtime assembly. No wasted bytes.

Why this matters for performance

The architectural difference explains every row in the benchmark table:

• Transfer size: CookieBoss ships ~10 KB because the compiled script contains only the code needed for that specific site. Competitors ship 60–200 KB because their script must handle every possible configuration.
• Requests: CookieBoss makes 1 request because everything is in one file. Competitors make 2–8 requests because they need to fetch configuration, stylesheets, and additional modules separately.
• JS execution: CookieBoss executes in under 20 milliseconds because there’s no runtime configuration parsing, no dynamic UI construction, and no unused code paths. Competitors spend 40–250 milliseconds doing work that CookieBoss did at compile time.
• INP: CookieBoss’s accept handler runs in under 50 milliseconds because the consent state update is a lightweight operation on a small codebase. Competitors have more JavaScript running, which means more work on every interaction.

The CDN layer

The compiled script is served from Cloudflare’s global network — over 300 points of presence in more than 100 countries. This infrastructure provides:

• HTTP/3 with QUIC: Eliminates TCP handshake overhead and handles packet loss more gracefully, particularly benefiting mobile users.
• 0-RTT TLS resumption: Returning visitors save a full round-trip on TLS negotiation, shaving 50–100 milliseconds on subsequent page loads.
• Brotli compression: More efficient than gzip, reducing transfer size by an additional 15–20% compared to gzip alone.
• Edge caching with long TTLs: The compiled script doesn’t change until the site owner modifies their configuration, so it can be cached aggressively at the edge. Most requests are served from edge memory without touching the origin server.

The combination of a tiny script and an optimized CDN means that the typical CookieBoss consent script loads and executes before competitors have even finished their first HTTP request.

How to test your CMP’s performance

You don’t have to take our word for it. Here’s how to measure your own CMP’s performance impact using free tools.

Step 1: Chrome DevTools Network tab

1. Open your site in Chrome.
2. Open DevTools (F12 or Cmd+Option+I on Mac).
3. Go to the Network tab.
4. Check “Disable cache” to simulate a first-time visitor.
5. Set throttling to “Fast 4G” or “Slow 4G.”
6. Reload the page.
7. Filter requests by your CMP’s domain (e.g., cookiebot.com, cdn.cookieyes.com, cookieboss).

Note the following for each CMP-related request:

• Size: The “Transferred” column shows the gzipped size over the wire.
• Time: The “Time” column shows total request duration (DNS + connect + TLS + TTFB + download).
• Initiator: Check whether the CMP script triggers additional requests. Click on each CMP-related request and look at the “Initiator” tab to see the chain.

Add up all the sizes and count the requests. This gives you the total network cost of your CMP.

Step 2: Lighthouse and PageSpeed Insights

1. In Chrome DevTools, go to the Lighthouse tab.
2. Select “Mobile” and check “Performance.”
3. Click “Analyze page load.”

Look for your CMP in these diagnostic sections:

• Reduce unused JavaScript: If your CMP appears here, it’s shipping code that your page doesn’t use.
• Minimize main-thread work: Shows how much main-thread time each script consumes.
• Reduce JavaScript execution time: Lists scripts by execution time. Your CMP should ideally be under 50 milliseconds.
• Avoid enormous network payloads: Flags resources over 100 KB.

You can also run the test at pagespeed.web.dev for the same analysis with an additional “Field Data” section showing real-world Chrome User Experience Report (CrUX) data.

Step 3: WebPageTest waterfall analysis

1. Go to webpagetest.org.
2. Enter your URL and select a test location close to your target audience.
3. Under “Advanced Configuration,” set the connection speed to “4G” and enable “Filmstrip View.”
4. Run the test.

The waterfall view shows exactly when each resource loads relative to every other resource. Look for:

• Where your CMP script appears in the waterfall: It should be early (within the first few requests), but how much time does it consume?
• Whether CMP requests block other resources: If the waterfall shows a gap where nothing else loads while CMP requests complete, the CMP is blocking your page.
• The filmstrip: Compare when the consent banner appears versus when your page content appears. If the banner shows up significantly after your content, your CMP is loading late — which may mean unconsented scripts are firing.

Step 4: Real User Monitoring with CrUX

Chrome User Experience Report (CrUX) data shows how real users experience your site, not just lab simulations. You can access CrUX data through:

• PageSpeed Insights: The “Field Data” section shows p75 LCP, INP, and CLS from real Chrome users over the past 28 days.
• Chrome UX Report BigQuery dataset: For detailed analysis of specific metrics and time-series trends.
• Google Search Console: The “Core Web Vitals” report shows which pages pass or fail CWV thresholds.

CrUX data is the most reliable way to measure real-world CMP impact because it reflects actual visitor experiences across different devices, connections, and locations. Lab tests show you what’s possible; CrUX shows you what’s actually happening.

Optimization tips for heavy CMPs

If you’re currently using a CMP that performed poorly in these benchmarks but can’t switch immediately, here are practical ways to reduce its performance impact.

Use async loading with inline consent defaults

Instead of loading your CMP script synchronously (which blocks rendering), use this pattern:

<!-- Set default consent state immediately (inline, no network request) -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied'
  });
</script>

<!-- Load CMP asynchronously -->
<script src="https://your-cmp.com/script.js" async></script>

This ensures Google tags respect the default “denied” state while the CMP loads in the background, preventing render-blocking without creating a consent gap.

Reduce cookie categories

Every additional cookie category adds weight to the CMP script: more UI elements, more event handlers, more configuration. If your CMP supports it, consolidate categories where legally permitted. GDPR requires distinguishing between strictly necessary and non-necessary cookies, but the additional subdivision into analytics, marketing, and preferences is a best practice, not a legal requirement. Some sites use two categories (necessary and non-necessary) and achieve full compliance with significantly less JavaScript.

Disable unused features

Most CMPs include features that many sites don’t use: A/B testing for banner layouts, consent wall functionality, advanced analytics dashboards, multi-language support for languages your site doesn’t serve. Each enabled feature adds code to the script. Audit your CMP configuration and disable everything you’re not actively using.

Preconnect to CMP domains

If your CMP makes requests to multiple domains, add preconnect hints to your HTML <head>:

<link rel="preconnect" href="https://cdn.your-cmp.com">
<link rel="preconnect" href="https://config.your-cmp.com">

This tells the browser to start DNS resolution and TLS negotiation for those domains early, saving 100–200 milliseconds per domain when the actual requests are made.

Consider switching

If your CMP adds more than 100 milliseconds to your page load, consumes more than 100 KB of transfer size, or makes more than three HTTP requests during initial load, it’s worth evaluating alternatives. The benchmarks in this post show that lighter CMPs exist without compromising compliance features.

Switching CMPs is typically a 10-minute task: remove the old script tag, add the new one, configure your categories in the new dashboard, and verify that consent is being collected correctly.

Frequently asked questions

Does CMP size really affect SEO?

Yes, but indirectly. Google doesn’t measure your CMP’s size specifically — it measures your page’s Core Web Vitals. If your CMP degrades LCP, INP, or CLS beyond the “good” thresholds (LCP under 2.5s, INP under 200ms, CLS under 0.1), it hurts your rankings. A heavy CMP is one of the most common causes of degraded CWV scores because it loads early and blocks other resources.

The effect is most pronounced on mobile, where Google uses mobile-first indexing. A CMP that performs acceptably on desktop but adds 400 milliseconds on 4G mobile can push your mobile CWV into the “needs improvement” or “poor” range, directly affecting your search rankings.

Can I defer my CMP script to improve performance?

You can load it asynchronously (with the async attribute), but you should not defer it to load after other scripts. The consent script needs to run before any scripts that set cookies — if it loads late, those scripts may fire without consent, creating a compliance violation.

The best approach is the inline default pattern shown above: set a default “denied” consent state immediately with an inline script, then load the CMP asynchronously. This prevents render-blocking while maintaining compliance.

What’s a good INP score for a consent banner interaction?

Google considers INP under 200 milliseconds to be “good.” For a consent banner specifically, the accept interaction should complete in under 100 milliseconds. This includes storing the consent preference, updating the consent state, and triggering the visual confirmation (banner dismissal or animation).

Note that the scripts fired after consent (analytics, ads, pixels) will add their own main-thread work, but these should run asynchronously and not block the paint that confirms the user’s interaction.

How often should I re-test my CMP’s performance?

Test after every CMP update (providers push updates that can change script size and behavior), after every change to your CMP configuration (adding categories, enabling features, changing languages), and quarterly as a baseline check.

CMP providers occasionally make significant changes to their scripts between versions. An update that adds a new feature might increase script size by 20–30 KB. If you’re not monitoring, you won’t notice until your CWV scores drop.

Are these benchmarks representative of all configurations?

These benchmarks use default configurations for each CMP. Real-world results will vary based on the number of cookie categories configured, languages enabled, banner layout chosen, and features activated. A heavily customized OneTrust installation with minimal features could perform better than shown here, while a Cookiebot installation with many categories and languages could perform worse.

The relative ordering — lighter CMPs outperforming heavier ones — is consistent across configurations we tested, but the absolute numbers should be treated as representative ranges, not precise measurements.

Conclusion

Performance is a feature, not a luxury. A consent management platform that adds hundreds of milliseconds to every page load is costing you search rankings, visitor engagement, and revenue — every day, on every page, for every visitor.

The benchmarks in this post show a clear pattern: architectural decisions made by CMP providers have a direct, measurable impact on your site’s Core Web Vitals. CMPs that ship generic, one-size-fits-all scripts with multiple network requests consistently underperform compared to CMPs built with performance as a core design constraint.

CookieBoss’s edge-compiled architecture — pre-compiled per-customer scripts, single-request delivery, no runtime framework — delivers measurably faster consent experiences. At ~10 KB and a single HTTP request, it’s the lightest CMP we tested, with the smallest impact on LCP, INP, and CLS.

If you’re evaluating CMPs or considering a switch, start by measuring your current CMP’s performance using the tools and steps outlined above. The data might surprise you.

---

CookieBoss delivers edge-compiled consent scripts from 300+ Cloudflare locations. One request. Under 10 KB. No runtime framework. Start your free trial and see the performance difference yourself.