CMP / Cookie Banner et web performance : comparatif de 11 outils

Les plateformes de gestion du consentement et Cookie Banners, auxquelles nous ferons référence via l’acronyme « CMP » dans la suite de cet article, peuvent avoir un impact significatif sur la performance des pages web. Plusieurs métriques Core Web Vitals peuvent ainsi être dégradées en fonction des choix techniques de leurs éditeurs :

• Hausse du TBT et du FID dûs à l’exécution de JavaScript et aux manipulations de DOM au chargement initial des pages.
• Hausse de l’INP en raison des manipulations de DOM, des Event Listeners JavaScript et des échanges de données asynchrones.
• Hausse du LCP dont le candidat final devient un élément de la CMP au détriment des éléments d’UI propres au site.

Au moment de choisir un outil, il est essentiel de prendre en compte l’impact des CMP sur la performance indépendamment de leur capacité à vous mettre en conformité avec les différentes règlementations (RGPD, ePR, CCPA, LGPD, CNIL…) ou de leur prix. C’est pour répondre à ce questionnement que nous avons établi ce comparatif.

Pourquoi l’Agence Web Performance a-t-elle réalisé ce comparatif ?

Dans le cadre de nos prestations d’audit, d’optimisation et d’accompagnement à la web performance, les CMP constituent quasi systématiquement un point de focus à part entière. Nous sommes régulièrement sollicités par nos clients pour leur fournir des recommandations sur le choix de l’outil de gestion des cookies à adopter en vue d’assurer un niveau de performance optimal.

Or, aucun comparatif existant n’apporte des éléments de réponse pertinents : ils se contentent pour la plupart de reprendre les arguments avancés par tel ou tel acteur. Ou alors, lorsqu’ils adoptent une approche technique, ils n’intègrent que deux ou trois points de comparaison, passant complètement à côté de certains facteurs critiques qu’un expert en web performance ne peut tout simplement pas ignorer.

Avec ce comparatif de performance des CMP, notre objectif est de fournir au plus grand nombre une comparaison objective basée sur des éléments concrets. Cela nécessite plusieurs prérequis :

• L’Agence Web Performance n’est affiliée ou partenaire avec aucune CMP : elle n’a aucun intérêt financier à valoriser un outil plutôt qu’un autre.
• Pour une transparence maximale, nous avons pris soin de détailler la méthodologie mise en place dans la section suivante.

Quelle est la méthodologie utilisée et comment sont calculés les scores ?

La méthodologie déployée pour ce comparatif est dérivée de celle utilisée dans le cadre de nos prestations d’audit et d’optimisation de la performance. Étant donné la spécificité des outils de CMP, seuls 12 points de contrôle ont été sélectionnés contre plus d’une centaine habituellement.

Afin d’obtenir un score de performance en pourcentage pour chaque outil, les différents volets ont été priorisés en tenant compte de leur impact sur la performance globale. Cette répartition est probablement l’aspect le plus « discutable » de notre travail : attribuer un poids à un critère dans une note globale nécessite forcément de trancher, ce que nous avons fait après mûres réflexions.

Voici quelques précisions complémentaires relatives à la méthodologie mise en oeuvre :

• Les tests ont été réalisés sur le tag tel qu’il est fourni par les CMP, pas sur les intégrations via des Tag Managers. Ils reflètent ainsi la performance avec une installation standard, telle que recommandée par les éditeurs. Les scores ne reflètent donc pas le potentiel maximum de chaque outil, notamment sur le volet JavaScript où tous les outils peuvent être chargés de façon asynchrone.
• Les tests ont été réalisés sous Google Chrome 113 avec une configuration standard. Ce choix se justifie par la popularité du navigateur face à ses concurrents Firefox, Safari et Edge.
• Les tests ont été réalisés depuis une adresse IP française, permettant aux CMP de nous géolocaliser en France, et ainsi de déclencher les fonctionnalités correspondantes et d’appliquer les traductions.

Les 12 points de contrôle

Chacun des points de contrôle est associé à un pourcentage. Nous avons pris soin de partager, pour chaque point de contrôle, le barème nous ayant permis de calculer les scores des différents outils. Cela garantit une transparence maximale sur la façon dont les scores finaux s’articulent.

La liste est triée par ordre décroissant, du critère le plus impactant (un quart de la note) au moins impactant (2% seulement).

Le volume de JavaScript exécuté par une CMP constitue l’un des facteurs clés de sa performance. Le chargement asynchrone étant la norme au sein du panel testé fin mai 2023, il a été priorisé de façon plus importante que le chargement synchrone, même s’il est évident que ce dernier dégrade davantage la performance.

Lorsque ce poids augmente, deux goulets d’étranglement entrent en jeu :

• Côté réseau : la ressource met plus de temps à être téléchargée
• Côté ressources utilisateur : l’exécution du script est plus longue et plus consommatrice de CPU

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

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

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

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.

Charger des scripts depuis un simple serveur web sous NGINX ou Apache constitue un comportement hautement pénalisant pour ce facteur. La performance sera notamment beaucoup plus fluctuante selon la géolocalisation des utilisateurs, dégradant la qualité de leur expérience s’ils se connectent à une distance importante du serveur.

100%	90%	80%	70%	60%	50%	40%	30%	10%	10%	0%
Oui	–	–	–	–	–	–	–	–	–	Non

Une durée de vie de cache navigateur élevée constitue un levier pertinent pour améliorer la performance d’une CMP. Si cette dernière est trop basse, les utilisateurs devront re-télécharger le script régulièrement, rajoutant des latences liées à la connexion (résolution dns / connexion tcp / négociation tls) et au téléchargement.

Une bonne moitié des acteurs de ce comparatif a opté pour la mise en place d’une en-tête http cache-control de 3600 secondes, soit une heure. D’autres se contentent de quelques dizaines de minutes tandis que les plus audacieux vont jusqu’à une semaine. Ce sont naturellement ces derniers qui obtiennent pour ce volet les meilleurs scores.

100%	90%	80%	70%	60%	50%	40%	30%	10%	10%	0%
>= 2624400	>= 874800	>= 291600	>= 97200	>= 32400	>= 10800	>= 3600	>= 2700	>= 1800	>= 900	0

Injecter du DOM dans une page via JavaScript n’est jamais anodin en termes de performance. Plus le DOM manipulé est volumineux et profond, moins bonne sera la performance. Nous avons donc compté le nombre de noeuds DOM présents dans l’interface initiale de chacune des CMP. Ce dernier peut augmenter avec l’ouverture de volets ou fenêtres complémentaires.

Le résultat est généralement cohérent avec ce qui est attendu : le panel s’étend de 40 à 200 noeuds. Pour aller plus loin, nous aurions pu analyser la façon dont le DOM est injecté via JavaScript, mais ce choix n’a pas été retenu en raison de sa complexité.

100%	90%	80%	70%	60%	50%	40%	30%	10%	10%	0%
<= 30	<= 40	<= 50	<= 60	<= 70	<= 80	<= 90	<= 100	<= 110	<= 120	> 120

Utiliser les protocoles HTTP modernes garantit de tirer pleinement profit des améliorations en termes de compression des en-têtes HTTP et de paralléllisation des téléchargements multiples. HTTP2 constitue dans le cadre de ce comparatif la norme, avec un bonus pour les ressources chargées en HTTP3 et, à l’inverse, un malus pour celles envoyées via HTTP/1.1.

100%	90%	80%	70%	60%	50%	40%	30%	10%	10%	0%
HTTP3	–	–	–	–	HTTP2	–	–	–	–	HTTP/1.1

De par leur nature même, les CMP sont conçues de façon à échanger des données entre le navigateur des utilisateurs et les serveurs de l’outil. Ces échanges pouvant fortement varier selon les interactions avec l’interface, nous avons choisi de mesurer les échanges de données intervenant au chargement initial, avant même toute validation ou refus de consentement.

Si la plupart des acteurs se contentent de quelques kilo-octets, certains téléchargent des fichiers de traductions ou de configuration de plusieurs dizaines de ko, qui doivent ensuite être interprétés via JavaScript pour afficher l’interface personnalisée en français. Cela pénalise ainsi la performance globale.

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

À défaut d’avoir analysé la façon dont le DOM est injecté dans les pages, nous avons retenu un critère plus simple et à l’impact tout aussi significatif : l’utilisation de Shadow DOM, également appelé encapsulation DOM, vs. une plus classique injection dans le DOM du document.

Cette méthode moderne, utilisée par une poignée de CMP, assure un niveau de performance bien supérieur. Elle impacte en conséquence les scores de ce volet de façon significative.

100%	90%	80%	70%	60%	50%	40%	30%	10%	10%	0%
Shadow DOM	–	–	–	–	–	–	–	–	–	Classique

Rares sont les CMP à afficher des images au sein de l’interface par défaut, ce qui constitue un excellent point. Pour celles qui en utilisent, nous avons dégradé le score en tenant compte de leur poids total, et donc indirectement de leur nombre.

Notons tout de même que pour la plupart des CMP ayant recours aux images, c’est le format SVG qui est privilégié. Vectoriel et compressible, ce dernier représente le choix le plus pertinent face au Jpeg, au PNG et à fortiori au Gif.

100%	90%	80%	70%	60%	50%	40%	30%	10%	10%	0%
0	<= 10	<= 20	<= 30	<= 40	<= 50	<= 60	<= 70	<= 80	<= 90	> 90

Chaque connexion à un nouveau domaine génère des latences supplémentaires puisqu’il est nécessaire de passer par les phases de résolution dns, de connexion initiale et de négociation SSL. Cela représente entre 500 millisecondes et une seconde avec une connexion mobile. Charger des scripts depuis des domaines différents retarde ainsi mécaniquement l’affichage de la CMP.

Les CMP ayant adopté une approche centralisée autour d’un unique domaine obtiennent en conséquence le score maximal. Celles qui en utilisent deux, trois ou quatre voient leur score impacté négativement. La moyenne des 11 outils testés est de 2,5.

100%	90%	80%	70%	60%	50%	40%	30%	10%	10%	0%
1	–	2	–	3	–	4	–	5	–	>= 6

La différence de poids entre un même fichier compressé en Gzip et en Brotli peut atteindre 25%, ce qui a un impact direct sur son temps de téléchargement. Même si les deux critères les plus importants intègrent déjà l’impact de la compression (poids des JavaScript asynchrone et synchrone), nous avons choisi de répercuter ce choix comme critère complémentaire.

La plupart des CMP utilisant Gzip, il nous a semblé logique de mettre en avant les acteurs ayant déployé l’algorithme Brotli, plus moderne et plus performant.

100%	90%	80%	70%	60%	50%	40%	30%	10%	10%	0%
Brotli	–	–	–	–	Gzip	–	–	–	–	Aucun

Les facteurs non retenus

Si 12 points de contrôle ont été retenus, nous avions envisagé d’en intégrer d’autres pour obtenir des scores de performance encore plus exhaustifs. Voici ceux qui nous semblaient intéressants de prime abord, mais qui n’ont pas été retenus faute de pertinence.

Les polices d’écriture

Nous nous attendions à croiser au moins un mauvais élève faisant appel à des polices d’écriture hébergées sur un serveur distant, mais cela n’a pas été le cas. Toutes les CMP de ce comparatif affichent leurs textes en se reposant sur des mécanismes d’héritage CSS (la solution idéale), ou avec des « Safe Fonts » disponibles sous tous les navigateurs comme Arial ou Helvetica.

Même si cela rend caduque un point de contrôle à l’impact potentiellement majeur, il s’agit d’une excellente nouvelle pour la performance des outils comparés.

Les repaint/reflows à l’interaction

Nous nous attendions également à observer des comportements de repaint et/ou reflow non souhaités au survol ou au clic d’éléments comme les boutons, toggles, etc. Cela n’a été le cas sur aucune des CMP testées : toutes prennent soin d’injecter leur DOM comme un enfant direct du <body>, supprimant tout risque de recalcul de style qui remonterait l’arbre DOM.

Il s’agit là aussi d’un excellent point dans la mesure où ces problématiques sont très courantes et peuvent impacter négativement l’interactivité des pages, métrique INP en tête.

Comment ont été choisies les CMP du comparatif ?

Nous avons décidé d’intégrer 11 outils à notre comparatif. Pour établir cette liste, nous avons utilisé plusieurs sources complémentaires :

• Les outils utilisés pas nos clients, dont le profil varié reflète logiquement la variété de ce que l’on peut croiser plus largement sur les sites français.
• Le Core Web Vitals Technology Report édité par http Archive, et qui reflète la variété des outils implémentés sur des centaines de milliers de sites dans le monde.
• De multiples comparatifs de CMP afin de dégager ceux considérés comme incontournables.

S’il venait à manquer un acteur majeur, n’hésitez pas à nous le signaler en commentaire, il pourra éventuellement être intégré à posteriori dans le cadre d’une mise à jour.

Quelles sont les CMP les plus performantes (résultats)

Nous allons maintenant détailler et analyser le classement des CMP établi à partir de notre grille de notation intégrant les 12 critères. La liste est triée des plus performantes aux moins performantes.

L’outil Cookie Consent développé par Osano est à l’évidence la surprise de ce comparatif de performance des CMP. Sa note au dessus du lot ne s’explique toutefois pas par une approche particulièrement tournée vers la performance, mais davantage par une maîtrise technique transversale : contrairement à ses concurrents, Osano ne fait aucun faux pas coûteux en termes de points.

Associé à certains choix habiles encore trop peu présents par ailleurs comme une durée de vie de cache navigateur élevée (une journée) et l’utilisation systématique de la compression Brotli, cela lui suffit à se démarquer franchement. On notera enfin qu’Osano ne met pas à profit le Shadow DOM pour injecter sa CMP, qui constitue une technique de pointe utilisée par seulement deux de ses concurrents dans ce comparatif.

Plusieurs CMP se partagent la seconde marche du podium de la performance, avec des scores très proches qui ne justifieraient pas un classement individuel : il suffirait d’une réduction de quelques kilo-octets côté JavaScript pour que leurs positions changent. Ce quatuor n’en reste pas moins intéressant dans la mesure où il offre un choix plus large à niveau de performance équivalent.

Les quatre outils font preuve d’une belle maturité technique sur la plupart des sujets, mais pêchent généralement sur un point critique qui leur coûte des points cruciaux. CookieYes se loupe ainsi sur le volume de DOM, en injectant près de 140 noeuds quand les concurrents en comptent en moyenne 84.

Du côté de Didomi, c’est le volume de CSS qui est le plus problématique, avec une balise <style> qui intègre 80 ko de CSS (non compressé). Quantcast Choice multiplie quant à lui les échanges de données Json (83 ko). Iubenda, enfin, affiche un profil davantage multi-factoriel avec une accumulation de petites pertes de points sur plusieurs facteurs essentiels.

Tous peuvent quoi qu’il en soit être envisagés sereinement : l’installation de leur CMP ne sera pas synonyme de dégradation majeure de la performance de vos pages.

Un second groupe de CMP se détache du classement, avec là encore des scores très proches qui les rendent interchangeables dans le cadre de ce comparatif. Ces acteurs ont globalement le même profil, avec une maîtrise technique des problématiques front-end inégale. Axeptio et UserCentrics sont par exemple les deux seules CMP du classement à tirer profit du Shadow DOM. Et pourtant, ils commettent des fautes impardonnables sur d’autres volets clés.

Axeptio charge par exemple trois images, pour un poids total de 51,6 ko. One Trust et UserCentrics chargent de leur côté un volume de JavaScript asynchrone conséquent : 124,1 ko pour le premier et 206 ko pour le second. De quoi se poser légitimement la question du contenu de ces fichiers.

Comme dans tout classement, il y a des vainqueurs et des perdants et ce dernier groupe inclut trois acteurs dont les outils ont révélé des faiblesses techniques. Leurs scores étant encore une fois assez proches, le regroupement nous est apparu comme une évidence.

Cookie Law est pénalisé par un volume de DOM élevé (208 noeuds) et de multiples échanges de données (42,4 ko). Cookiebot fournit un code d’intégration synchrone de 34 ko, injecte 209 noeuds dans le DOM et envoie une en-tête cache-control de seulement 11 minutes (le plus court du classement).

Sirdata, pour clôturer, fournit un code d’intégration partiellement bloquant et, plus grave encore, n’utilise que très partiellement HTTP2 : c’est le seul acteur du classement à charger 146 ko de ressources depuis un domaine qui n’est pas hébergé sur un cdn et qui utilise l’ancien protocole HTTP/1.1. Un manquement impardonnable qui impacte très négativement son score final.

Conclusion du classement

Ce comparatif de la web performance des CMP ne vise pas à vous pousser sans discuter vers un acteur ni à pointer du doigts d’éventuels « mauvais élèves ». Notre espoir est qu’il constitue une aide dans votre processus de décision en plus d’autres critères propres à votre organisation.

Mais notre plus grand espoir, c’est de voir les acteurs cités réagir en s’appropriant les problématiques de performance présentées et en faisant évoluer leurs outils. Les CMP et Cookie Banner étant par nature impactantes pour la webperf et l’Expérience Utilisateur, chaque effort des éditeurs profitera à tout l’Internet.

Nous sommes bien évidemment disponibles pour échanger et répondre à vos questions : n’hésitez pas à publier un commentaire ci-dessous ou à nous envoyer un email via le formulaire de contact. Nous ne manquerons pas de revenir vers vous en mettant à profit notre expertise de spécialistes de la web performance front-end.