Consent management platforms and Cookie Banners, which we will refer to by the acronym "CMP" throughout this article, can have a significant impact on performance of web pages. Several Core Web Vitals metrics can thus be degraded depending on the technical choices of their publishers:
- Increase in TBT and FID due to JavaScript execution and DOM manipulations during initial page load.
- Increase in INP due to DOM manipulations, JavaScript Event Listeners, and asynchronous data exchanges.
- Increase in LCP, where the final candidate becomes a CMP element to the detriment of the site's own UI elements.
When choosing a tool, it is essential to consider the impact of CMPs on performance, regardless of their ability to bring you into compliance with various regulations (GDPR, ePR, CCPA, LGPD, CNIL, etc.) or their price. It is in response to this question that we have established this comparison.
Why did the Web Performance Agency conduct this comparison?
As part of our audit, optimization, and web performance support services, CMPs almost systematically constitute a focus point in their own right. We are regularly asked by our clients to provide them with recommendations on the choice of tool for cookie management to adopt in order to ensure an optimal performance level.
However, no existing comparison provides relevant answers: most of them are content to repeat the arguments put forward by one player or another. Or, when they adopt a technical approach, they only include two or three comparison points, completely missing certain critical factors that a web performance expert simply cannot ignore.
With this CMP performance comparison, our goal is to provide as many people as possible with an objective comparison based on concrete elements. This requires several prerequisites:
- The Web Performance Agency is not affiliated or partnered with any CMP: it has no financial interest in promoting one tool over another.
- For maximum transparency, we have taken care to detail the methodology implemented in the following section.
What is the methodology used and how are the scores calculated?
The methodology deployed for this comparison is derived from that used in our performance audit and optimization services. Given the specificity of CMP tools, only 12 control points were selected compared to more than a hundred usually.
In order to obtain a performance score as a percentage for each tool, the different areas were prioritized taking into account their impact on overall performance. This distribution is probably the most "debatable" aspect of our work: assigning a weight to a criterion in an overall score necessarily requires making a decision, which we have done after careful consideration.
Here are some additional details regarding the methodology implemented:
- The tests were carried out on the tag as provided by the CMPs, not on integrations via Tag Managers. They thus reflect performance with a standard installation, as recommended by the publishers. The scores therefore do not reflect the maximum potential of each tool, particularly in the JavaScript area where all tools can be loaded asynchronously.
- The tests were carried out on Google Chrome 113 with a standard configuration. This choice is justified by the browser's popularity compared to its competitors Firefox, Safari, and Edge.
- The tests were carried out from a French IP address, allowing the CMPs to geolocate us in France, and thus to trigger the corresponding functionalities and apply the translations.
The 12 control points
Each control point is associated with a percentage. We have taken care to share, for each control point, the scoring scale that allowed us to calculate the scores for the different tools. This ensures maximum transparency on how the final scores are structured.
The list is sorted in descending order, from the most impactful criterion (a quarter of the score) to the least impactful (only 2%).
Volume of asynchronous JavaScript
The volume of JavaScript executed by a CMP is one of the key factors of its performance. Asynchronous loading is the norm within the panel tested at the end of May 2023, so it was prioritized more heavily than synchronous loading, even though it is obvious that the latter degrades performance more.
When this weight increases, two bottlenecks come into play:
- Network side: the resource takes longer to download
- User resources side: script execution is longer and more CPU-intensive
Tant que le téléchargement et l’exécution n’ont pas eu lieu, la CMP n’est pas en mesure d’être affichée. Nous avons évalué le poids du fichier en kilo-octets avec la compression d’origine, Gzip ou Brotli.
Notons au passage qu’aucune CMP ne conseille l’utilisation de defer, qui offrirait un niveau de performance encore bien supérieur à l’async (cf. cet article qui détaille les différences). Les scripts ne seraient plus en mesure de bloquer le rendu des pages, améliorant sensiblement la performance globale.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | <= 20 | <= 40 | <= 60 | <= 80 | <= 100 | <= 120 | <= 140 | <= 160 | <= 180 | > 180 |
Volume de JavaScript synchrone
La logique applicable au script principal l’est également aux éventuels JavaScript appelés en synchrone (via une balise <script> sans attributs async ni defer), à la différence près que ces derniers bloquent le rendu au téléchargement et à l’exécution. Leur impact sur les métriques de performance liés au temps de chargement (FCP, LCP, Speed Index…) et sur le Blocking Time est ainsi bien supérieur.
Fort heureusement, rares sont les CMP à fournir un code synchrone. À l’inverse, l’une d’entre elles réclame une intégration du code synchrone fourni tout en haut du <head>, ce qui constitue le scénario le plus pénalisant pour les temps de chargement.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | <= 10 | <= 20 | <= 30 | <= 40 | <= 50 | <= 60 | <= 70 | <= 80 | <= 90 | > 90 |
Poids du CSS
Les CMP testées adoptent toutes la même approche en matière de mise en forme : le CSS est injecté via JavaScript dans une balise <style> en inline. C’est effectivement la solution la plus pertinente, et l’utilisation de feuilles de styles externes ou bien d’attributs style="..." sur les éléments du DOM se seraient soldés par une diminution du score.
Nous n’avons donc retenu que le critère du poids, en comparant le volume de CSS généré par chaque CMP. Nous aurions pu aller plus loin en évaluant le nombre de sélecteurs CSS et leur complexité, mais il semble là aussi y avoir une forme de consensus : on retrouve généralement des sélecteurs CSS sous la forme #identifiant-cmp .classe-cmp.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | <= 10 | <= 20 | <= 30 | <= 40 | <= 50 | <= 60 | <= 70 | <= 80 | <= 90 | > 90 |
Utilisation d’un cdn
Pour un script aussi critique qu’une CMP, forcément hébergé sur un domaine tiers, l’utilisation d’un cdn fait sens. Les CMP se plient à cette exigence à de rares exceptions près, en se reposant sur les infrastructures réseau d’acteurs comme Akamai, Cloudflare, Cloudfront, Google ou BunnyCDN.
Loading scripts from a simple web server under NGINX or Apache is highly detrimental to this factor. Performance will be much more fluctuating depending on user geolocation, degrading their experience quality if they connect from a significant distance from the server.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| Yes | – | – | – | – | – | – | – | – | – | No |
Browser cache policy
A high browser cache lifetime is a relevant lever for improving CMP performance. If the latter is too low, users will have to re-download the script regularly, adding latency related to the connection (DNS resolution / TCP connection / TLS negotiation) and download.
A good half of the players in this comparison opted for the implementation of a http cache-control header of 3600 seconds, or one hour. Others settle for a few tens of minutes while the most daring go up to a week. It is naturally these last ones who obtain the best scores for this part.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| >= 2624400 | >= 874800 | >= 291600 | >= 97200 | >= 32400 | >= 10800 | >= 3600 | >= 2700 | >= 1800 | >= 900 | 0 |
DOM Volume
Injecting DOM into a page via JavaScript is never trivial in terms of performance. The larger and deeper the manipulated DOM, the worse the performance. We therefore counted the number of DOM nodes present in the initial interface of each of the CMPs. The latter can increase with the opening of additional panels or windows.
The result is generally consistent with expectations: the panel ranges from 40 to 200 nodes. To go further, we could have analyzed how the DOM is injected via JavaScript, but this choice was not retained due to its complexity.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| <= 30 | <= 40 | <= 50 | <= 60 | <= 70 | <= 80 | <= 90 | <= 100 | <= 110 | <= 120 | > 120 |
HTTP Protocols
Using modern HTTP protocols guarantees full advantage of improvements in terms of HTTP header compression and multiple download parallelization. HTTP2 is the standard in this comparison, with a bonus for resources loaded in HTTP3 and, conversely, a penalty for those sent via HTTP/1.1.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| HTTP3 | – | – | – | – | HTTP2 | – | – | – | – | HTTP/1.1 |
JSON and XHR Exchanges
By their very nature, CMPs are designed to exchange data between users' browsers and the tool's servers. As these exchanges can vary greatly depending on interactions with the interface, we chose to measure the data exchanges occurring during initial loading, even before any consent validation or refusal.
While most players are content with a few kilobytes, some download translation or configuration files of several tens of KB, which must then be interpreted via JavaScript to display the customized interface in French. This penalizes overall performance.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | <= 2.5 | <= 5 | <= 7.5 | <= 10 | <= 12.5 | <= 15 | <= 17.5 | <= 20 | <= 22.5 | > 22.5 |
DOM Insertion Method
As we could not analyze how the DOM is injected into pages, we chose a simpler criterion with an equally significant impact: the use of Shadow DOM, also known as DOM encapsulation, versus a more classic injection into the document's DOM.
This modern method, used by a handful of CMPs, ensures significantly higher performance. It consequently impacts the scores for this aspect significantly.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| Shadow DOM | – | – | – | – | – | – | – | – | – | Classic |
Image Weight
Few CMPs display images within the interface by default, which is an excellent point. For those that do use them, we have downgraded the score by considering their total weight, and therefore indirectly their number.
It should be noted that for most CMPs using images, the SVG format is preferred. Being vector-based and compressible, it is the most relevant choice compared to Jpeg, PNG, and especially Gif.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | <= 10 | <= 20 | <= 30 | <= 40 | <= 50 | <= 60 | <= 70 | <= 80 | <= 90 | > 90 |
Number of Distinct Domains
Each connection to a new domain generates additional latency as it requires going through DNS resolution, initial connection, and SSL negotiation phases. This represents between 500 milliseconds and one second on a mobile connection. Loading scripts from different domains thus mechanically delays the display of the CMP.
CMPs that have adopted a centralized approach around a single domain consequently obtain the maximum score. Those that use two, three, or four see their score negatively impacted. The average for the 11 tools tested is 2.5.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | – | 2 | – | 3 | – | 4 | – | 5 | – | >= 6 |
Compression Algorithms
The weight difference between the same file compressed in Gzip and Brotli can reach 25%, which has a direct impact on its download time. Even though the two most important criteria already include the impact of compression (weight of asynchronous and synchronous JavaScript), we chose to carry over this choice as a complementary criterion.
Since most CMPs use Gzip, it seemed logical to highlight the providers that have implemented the Brotli algorithm, which is more modern and more efficient.
| 100% | 90% | 80% | 70% | 60% | 50% | 40% | 30% | 10% | 10% | 0% |
|---|---|---|---|---|---|---|---|---|---|---|
| Brotli | – | – | – | – | Gzip | – | – | – | – | None |
Factors not selected
While 12 checkpoints were selected, we considered including others to obtain even more exhaustive performance scores. Here are the ones that seemed interesting at first glance, but were not selected due to lack of relevance.
Fonts
We expected to find at least one underperformer using remotely hosted fonts, but this was not the case. All CMPs in this comparison display their text by relying on CSS inheritance mechanisms (the ideal solution), or with "Safe Fonts" available on all browsers like Arial or Helvetica.
Although this makes a checkpoint with potentially major impact obsolete, it is excellent news for the performance of the tools compared.
Repaints/reflows on interaction
We also expected to observe unwanted repaint and/or reflow behaviors when hovering over or clicking on elements like buttons, toggles, etc. This was not the case for any of the tested CMPs: all of them take care to inject their DOM as a direct child of the <body>, eliminating any risk of style recalculation that would propagate up the DOM tree.
This is also an excellent point, as these issues are very common and can negatively impact page interactivity, particularly the INP metric.
Is your site as fast as your visitors expect?
How were the CMPs for the comparison chosen?
We decided to include 11 tools in our comparison. To compile this list, we used several complementary sources:
- The tools used by our clients, whose varied profiles logically reflect the variety of what can be found more broadly on French websites.
- The Core Web Vitals Technology Report published by HTTP Archive, which reflects the variety of tools implemented on hundreds of thousands of websites worldwide.
- Multiple CMP comparisons to identify those considered essential.
If a major player is missing, feel free to let us know in the comments, and they may be added later as part of an update.
What are the best-performing CMPs (results)
We will now detail and analyze the ranking of CMPs established from our scoring grid incorporating the 12 criteria. The list is sorted from best performing to worst performing.
Osano, the big winner
The Cookie Consent tool developed by Osano is clearly the surprise of this CMP performance comparison. Its score, above the rest, is not explained by a particularly performance-oriented approach, but rather by a transversal technical mastery: unlike its competitors, Osano makes no costly mistakes in terms of points.
Combined with some clever choices that are still too rare, such as a high browser cache lifespan (one day) and the systematic use of Brotli compression, this is enough for it to stand out clearly. Finally, it should be noted that Osano does not take advantage of Shadow DOM to inject its CMP, which is a cutting-edge technique used by only two of its competitors in this comparison.
CookieYes, Didomi, Iubenda, and Quantcast Choice, the challengers
Several CMPs share the second step of the performance podium, with very close scores that would not justify an individual ranking: a reduction of a few kilobytes on the JavaScript side would be enough to change their positions. This quartet remains interesting insofar as it offers a wider choice at an equivalent performance level.
The four tools demonstrate good technical maturity on most subjects, but generally falter on one critical point which costs them crucial points. CookieYes misses out on DOM volume, injecting nearly 140 nodes while competitors average 84.
On Didomi's side, CSS volume is the most problematic, with a <style> tag that includes 80 KB of CSS (uncompressed). Quantcast Choice, for its part, multiplies JSON data exchanges (83 KB). Iubenda, finally, displays a more multi-factorial profile with an accumulation of small point losses on several essential factors.
All of them can, in any case, be considered with confidence: installing their CMP will not mean a major degradation in the performance of your pages.
Axeptio, One Trust, and UserCentrics, the outsiders
A second group of CMPs breaks away from the rankings, with again very close scores that make them interchangeable within the context of this comparison. These players generally have the same profile, with uneven technical mastery of front-end issues. Axeptio and UserCentrics are, for example, the only two CMPs in the ranking to take advantage of Shadow DOM. And yet, they make unforgivable mistakes in other key areas.
Axeptio, for example, loads three images, for a total weight of 51.6 KB. One Trust and UserCentrics, on the other hand, load a significant volume of asynchronous JavaScript: 124.1 KB for the first and 206 KB for the second. This legitimately raises questions about the content of these files.
Cookie Law, Cookiebot, and Sirdata, the losers
As in any ranking, there are winners and losers, and this last group includes three players whose tools revealed technical weaknesses. As their scores are once again quite close, grouping them seemed obvious to us.
Cookie Law is penalized by a high DOM volume (208 nodes) and multiple data exchanges (42.4 KB). Cookiebot provides 34 KB of synchronous integration code, injects 209 nodes into the DOM, and sends a cache-control header of only 11 minutes (the shortest in the ranking).
Sirdata, to conclude, provides partially blocking integration code and, more seriously, only very partially uses HTTP2: it is the only player in the ranking to load 146 KB of resources from a domain not hosted on a CDN and which uses the old HTTP/1.1 protocol. An unforgivable oversight that negatively impacts its final score.
Conclusion of the ranking
This comparison of CMP web performance is not intended to push you unquestioningly towards one provider or to point out any "bad students." Our hope is that it will serve as an aid in your decision-making process, in addition to other criteria specific to your organization.
But our greatest hope is to see the cited players react by embracing the performance issues presented and evolving their tools. CMPs and Cookie Banners being inherently impactful for web performance and User Experience, any effort by publishers will benefit the entire Internet.
We are of course available to discuss and answer your questions: do not hesitate to post a comment below or send us an email via the contact form. We will be sure to get back to you by leveraging our expertise as front-end web performance specialists.
