Consent management platforms, which we will refer to by the acronym "CMP" (Consent Management Platform) throughout this article, occupy a unique position in the loading of a web page: they are the first element a new visitor sees, even before your content. As soon as a site deploys a tracker that is not strictly necessary, their presence is imposed by the RGPD / ePrivacy framework, and they therefore appear on almost all European sites.
This privileged position comes at a cost: a CMP loads early, executes before the marketing scripts to which it transmits the consent status, and overlays all entry pages. Depending on the technical choices of its provider and how it is integrated, it can degrade all Core Web Vitals metrics:
- LCP, when its script blocks rendering or when the banner itself becomes the LCP element of the page.
- INP, the consent click often being the slowest interaction of the entire session.
- CLS, when the banner inserts itself late into the page flow or animates awkwardly.
- The overall health of the DOM, with some tools injecting hundreds of nodes to list their advertising partners.
In 2023, we published a comparison here of the performance of 11 CMPs, rated on 12 technical checkpoints. Three years later, this ranking no longer makes sense: the INP joined the Core Web Vitals in March 2024, Google's Consent Mode v2 and IAB's TCF v2.2 have reshuffled the deck, and most publishers have thoroughly reworked their scripts. We have therefore completely rewritten this page in a more sustainable way: understanding the mechanisms by which a CMP degrades performance, in order to be able to evaluate any tool, today and tomorrow.
Why is a CMP not like any other third-party script?
A chat or heatmap script can be delayed without functional consequence. A CMP, no: it must execute before the scripts it conditions. This is the whole principle of Google's Consent Mode v2, mandatory since March 2024 for European advertisers: as long as consent is not known, advertising and analytics tags function in degraded mode. Similarly, the __tcfapi API of the IAB Europe TCF must be available as early as possible for the programmatic advertising chain to function. Result: the CMP is mechanically placed in the critical loading path.
It also concerns 100% of new visitors, on their entry page, precisely the one where LCP and the first impression are decided. Where a site builds loyalty, the impact is diluted; where acquisition dominates (SEO, Discover, campaigns), a major part of sessions begins with the display of the banner. It is also the experience that Lighthouse and PageSpeed Insights measure by default, as they always test a first visit without any consent.
Finally, a CMP loaded from a third-party domain constitutes a single point of failure (SPOF): SpeedCurve documents the case of a synchronous consent script whose timeout froze the page rendering for several seconds. When the publisher's infrastructure coughs, it's your site that turns white. This risk, common to all external scripts, is amplified here by the CMP's position in the loading process. We detailed it in our article on the impact of third-party JavaScript.
Six mechanisms by which a CMP degrades performance
To choose a tool with full knowledge, you need to understand where the degradation comes from. Here are the six mechanisms we systematically encounter in audits, from the most obvious to the most insidious.
1. A blocking script delays everyone
Some CMPs still recommend integration via a synchronous <script> tag, sometimes placed at the very top of the <head>. The browser then interrupts the page construction to download and execute the script: FCP and LCP are pushed back accordingly, even for visitors who have already consented and will never see the banner. The official recommendation from web.dev is unambiguous: asynchronous loading (async attribute), direct call in the HTML, and early connection to the CMP's domain via preconnect.
Blocking can also be indirect: many tools work in cascade, with a first "stub" script that loads the full SDK, which in turn loads a JSON configuration, translations, sometimes a stylesheet. Each link adds its latency, and the banner only appears at the end of the chain. DebugBear illustrates this phenomenon with the otSDKStub.js / otBannerSdk.js pair from OneTrust, where the second, low-priority request considerably delays the banner's appearance.
The worst-case scenario, however, remains loading the CMP via a tag manager. A script injected by Google Tag Manager is only discovered after GTM itself has been downloaded and executed: it escapes the browser's pre-parser, inherits a lower network priority, and is added at the end of the dependency chain. The CMP, which should be one of the first scripts on the page, ends up deprioritized on the critical path it nevertheless conditions. web.dev puts it bluntly: the consent script is called directly in the document's HTML, never via a tag manager or an intermediate script.
This detour is sometimes imposed by the organization: CMP managed from Google Tag Manager, or an inline snippet that injects the <script> tag asynchronously. In both cases, the script's URL does not appear in the initial HTML, and the browser's preload scanner cannot discover it. A <link rel="preconnect"> to the CMP's domain then allows opening the connection even before the script is requested: DNS resolution, TCP connection, and TLS negotiation are already paid for when the request is sent, subtracting that much latency from the banner's display. This is the safety net that web.dev recommends, in addition to the direct call, never instead of it.
2. The overlay can become your LCP
The LCP measures the display time of the largest visible element in the viewport, whether it's an image or a text block. However, a CMP displayed as a central overlay often contains several paragraphs of legal text: on mobile, where it occupies a significant portion of the screen, this text block frequently becomes the page's LCP element, at the expense of your own content.
The consequences are doubly perverse. First, as the banner appears at the end of the request chain, the measured LCP degrades: DebugBear shows a case where it goes from 1.43s to 3.61s when the OneTrust text surpasses the main image in size. Second, your measurement becomes blind: as long as the "official" LCP is that of the banner, no optimization of your hero image will appear in the numbers. SpeedCurve rightly speaks of a "bad LCP element": you think you're measuring your site, but you're measuring your CMP.
At the time of choice, this mechanism argues for a compact banner, of the discreet strip type at the bottom of the screen rather than a full-screen modal saturated with text. An element significantly smaller than your main content will never be an LCP candidate.
3. Late insertions cause layout shifts
When a banner inserts itself into the page flow (typically at the top of the screen) after the surrounding content has been displayed, everything below it is brutally pushed down: this is one of the most common causes of poor CLS. web.dev recommends either reserving space in the DOM before rendering or displaying the banner as an overlay (sticky footer or modal), which doesn't move anything. Appearance animations are the second pitfall: an animated "slide-in" using the top or left properties generates layout shifts on each frame, whereas an animation using transform produces none.
4. The consent click, often the slowest interaction of the session
The INP penalizes the slowest interaction of a session (at the 75th percentile of users). However, clicking "Accept All" is structurally costly: within the same event handler, the writing of consent, the encoding of the TCF string, the notification of dozens of third-party callbacks, the burst triggering of all pending marketing tags, and then the closing and removal of the interface from the DOM are chained together.
As long as this long task is not completed, the screen does not update: the banner appears frozen, the user clicks again, and the INP skyrockets. This is all the more detrimental as this click is, for many visitors, the first interaction with the site, the very one that has a good chance of becoming the INP retained for the session.
This problem is fixable by publishers, and some have demonstrated it. The case study published by Google with PubTech details the techniques used: breaking down long tasks with scheduler.yield() and scheduler.postTask() to let the browser paint between steps, and "lazy de-rendering," which consists of immediately hiding the banner with display: none and then only removing its DOM nodes later, via requestIdleCallback. Result: INP reduced by up to 64% for their clients, and long tasks attributable to the TCF library reduced by 85% on mobile.
The lesson for your choice of tool: ask the publisher what they do with your click. A vendor unable to answer "we hand control back to the browser before processing tags" has likely never measured their INP.
5. Hundreds of partners in your DOM
Sites monetized by programmatic advertising rely on the TCF, whose Global Vendor List references several hundred companies. TCF v2.2 also requires announcing the number of partners on the first screen. Some CMPs draw a disastrous conclusion for performance from this: they pre-build, from the initial load, the secondary panel listing each partner with its checkbox, name, and purpose text. Hundreds of hidden lines, but present in the DOM.
And the DOM size is never free: each node increases style recalculations, layout, and memory usage, and directly degrades interactivity. Lighthouse considers that beyond approximately 1,400 nodes, a page enters a critical zone. A CMP that injects several hundred nodes on its own can push a healthy page into the red.
During our 2023 comparison, the initial interfaces ranged from 40 to 210 nodes, a factor of 5 between the most minimalist and the most verbose, even before opening the partner panel. Best practices do exist: build the partner list on demand, when the user opens the panel, paginate or virtualize it, and ideally encapsulate the interface in a Shadow DOM to isolate its styles from those of the page.
6. Weight, domains, cache, and compression : the fundamentals remain
The fundamentals of any third-party script remain, where the gaps between CMPs are still considerable. JavaScript volume first: for equivalent functionality, we measured in 2023 a ratio of 1 to 10 between tools, some exceeding 200 KB compressed. Every kilobyte is downloaded, parsed, and executed on the often modest mobile CPU of your visitors.
The ancillary exchanges then: configurations and JSON translation files of several tens of Ko, obese stylesheets injected inline. The delivery finally: a single domain served by a CDN in HTTP/2 or HTTP/3, Brotli compression and a browser cache policy of at least one day should be obvious. However, in 2023, we noted cache durations of 11 minutes, requiring the script to be re-downloaded almost every session.
The paradoxical effect: a CMP also postpones the execution of third-party scripts
Not everything is a burden, and it must be said clearly: a CMP also has a beneficial effect on initial loading. As long as the user has not expressed their choice, it blocks or postpones the execution of third-party scripts that it conditions. Some are entirely absent from the page (no bytes downloaded, no tasks executed), while others, driven by Consent Mode, are only partially loaded, in degraded mode without cookies. The first visit is therefore mechanically lighter: fewer requests, less JavaScript, fewer long tasks, as long as the banner is on the screen.
This relief, however, has a downside in terms of measurement: synthetic tests precisely reproduce this state. Lighthouse and PageSpeed Insights test a first visit without consent, during which a large portion of third-party scripts has simply disappeared. SpeedCurve quantifies the difference on a real-world case: the "consented" experience of the same site loads 73 additional third-party requests, along with the associated CPU activity and long tasks. The test report therefore describes a site that is significantly more performant than it actually is for the majority of your visitors, who browse in a consented state.
The solution is always the same: test both states (before and after opt-in, by scripting the click or pre-setting the consent cookie) and, above all, trust the field data. RUM and CrUX aggregate all sessions, consented or not: it is here, and not in a Lighthouse report, that the real impact of your CMP and your third-party scripts can be seen.
Is your site as fast as your visitors expect?
What our 2023 comparison highlighted
Our 2023 comparison evaluated 11 tools (Axeptio, Cookiebot, Cookie Law, CookieYes, Didomi, Iubenda, OneTrust, Osano, Quantcast Choice, Sirdata, Usercentrics) on 12 control points. Osano came out on top with 72%, and no tool exceeded three-quarters of the maximum score. Most importantly, each player failed on a different point, illustrating each of the mechanisms described above:
- Cookiebot provided a synchronous integration code of 34 KB, injected 209 nodes into the DOM, and served its script with an 11-minute cache, the shortest in the panel.
- Sirdata loaded 146 KB from a non-CDN domain, over HTTP/1.1, the only player in the panel in this case.
- Usercentrics and OneTrust downloaded 206 KB and 124 KB of asynchronous JavaScript, respectively.
- Didomi injected 80 KB of CSS into a
<style>tag, Quantcast Choice exchanged 83 KB of JSON upon loading, before any interaction. - Cookie Law and CookieYes bloated the DOM (208 and nearly 140 nodes, with a median of 84), while Axeptio loaded 51.6 KB of images in its banner.
At the end of 2023, we completed this "laboratory" snapshot with RUM data collected from a large sample of sites, ranking CMPs by INP at the 75th percentile: from 26 ms for Usercentrics to 241 ms for Cookiebot, including CookiePro (49 ms), Cookie Law (58 ms), CookieYes (60 ms), Consentmanager (171 ms), and Funding Choices (200 ms). Two lessons learned: the field ranking did not match the laboratory ranking (Cookie Law, poorly rated in the lab, performed honorably in the field), and the positions shifted as publishers updated their scripts.
This is precisely why we do not republish a fixed ranking. A score assigned on day X photographs a version of the script that the publisher may replace the next day, and several actors mentioned above have indeed largely corrected the situation since then. And your own configuration (integration mode, language, partner list, graphic customization) weighs as much as the tool itself. A ranking becomes obsolete; a set of criteria can be reused.
The selection grid: 10 criteria for evaluating a CMP
Here is the grid we use for audits and coaching. It is directly derived from the mechanisms described above, and each criterion can be objectively verified, with testing tools to support it.
| Criterion | What to demand |
|---|---|
| Loading method | Asynchronous script (async), called directly in the HTML, never synchronously or via a tag manager |
| Connections | A single domain, served by a CDN, compatible with preconnect |
| JavaScript weight | A few dozen Ko compressed maximum, in Brotli |
| Request chain | Banner displayable in one to two requests, without cascading configurations or bulky translations |
| Browser cache | Cache-Control of at least one day |
| Display | Compact banner (bar or reduced modal), overlay or placeholder, animations using only transform |
| Injected DOM | Initial interface of a few dozen nodes, partner list built upon panel opening, Shadow DOM appreciated |
| Interactions | Immediate visual feedback on click, split tag processing (scheduler.yield), deferred DOM deletion |
| Consent signals | Consent Mode v2 and, if your monetization requires it, TCF v2.2 (__tcfapi) correctly exposed |
| Graphic sobriety | No images or fonts loaded from remote domains; inheritance of site fonts |
How to test it yourself?
Three manipulations are enough to differentiate candidates. First, compare the first visit and the "consented" visit: WebPageTest allows you to script the click on the banner or pre-set the consent cookie, and the difference between the two recordings reveals the real cost of the tool.
Second, profile the "Accept All" click in the Performance panel of DevTools: the processing time of the interaction, and the list of scripts running during it, do not lie. Third, in production, monitor INP and long frames (Long Animation Frames API) in RUM: if your CMP script ranks among the blocking scripts, you've found your culprit.
Finally, keep in mind that synthetic tools only test the first visit: only field data reflects the reality of traffic that has mostly already consented.
Don't let the CMP blind your measurement
Last blind spot: the CMP also conditions your measurement tools. If your RUM or analytics solution requires consent, every refusal is an invisible session: your performance data only describes consenting visitors. web.dev reminds us that performance measurement technically requires no cookies (the web-vitals library is an example), and that it may be relevant to isolate audience measurement in a separate consent category, or even opt for a solution exempt from consent according to CNIL. One more criterion to consider when choosing.
The WordPress case: the CMP as a plugin, without remote script
WordPress allows for a structurally different approach: the CMP installed as an extension, which generates the banner from your own domain, without depending on a remote service. Complianz is the most advanced example (the extension claims to operate fully self-hosted, without external API calls), and the French open source tarteaucitron follows the same logic.
Performance benefits are direct. No more DNS resolution or TLS negotiation to a third-party domain, no more external SPOFs: the script is served by your server, with your cache policy, your compression, and your HTTP protocol, alongside your other resources. The embedded weight is generally an order of magnitude less than that of a SaaS CMP. And since the banner can be rendered in the initial HTML, space can be reserved from the first display: no late appearance, no layout shift, no request chain.
Three limits, however, deserve to be set. First, an extension remains code executed on each PHP request and assets added to the front: its quality is verified like that of a theme.
Second, configuration requires a technical profile: tarteaucitron, for example, embeds dozens of service configurations that must be pruned to avoid loading unnecessary JavaScript, and cache or optimization extensions must be configured not to defer the consent script; Complianz documents these exclusions for WP Rocket or LiteSpeed.
Finally, a programmatic ad-monetized press editor will need a complete TCF registration that local extensions do not all cover: for a fleet of heterogeneous sites or advanced legal needs, SaaS CMP remains relevant.
For a showcase site, an e-commerce store, or a WordPress blog where trackers are limited to analytics and a few marketing pixels, our position is clear: a well-configured local extension is the most performant option, quite simply because it eliminates most of the degradation mechanisms described in this article instead of mitigating them.
Key takeaways
A CMP is a regulatory necessity, not a performance fatality. The gaps between tools are major, degradation mechanisms are known, and each is objectively tested:
- Demand asynchronous and direct loading, without going through a tag manager, from a single domain on CDN, with long cache and minimal weight.
- Prefer a compact banner that can neither become your LCP nor cause a layout shift.
- Profile the consent click: this is what will determine your INP for new visitors.
- Reject interfaces that dump hundreds of partners into your DOM upon loading.
- On WordPress, seriously consider the option of a local extension without remote scripts.
- Beware of flattering synthetic scores: without consent, a large portion of third-party scripts do not load.
- Measure in RUM, before and after any tool change, and re-challenge your CMP at each contract renewal.
As in 2023, let's finally recall that performance is only one criterion among others, alongside regulatory compliance, features, and cost: this guide sheds light on a blind spot, it does not replace your lawyer or your marketing team. We remain available to discuss and answer your questions: feel free to post a comment below or contact us via the contact form.
