Les bannières de cookies ralentissent-elles votre site

Tous les articles

Une bannière de cookies peut ralentir votre site, mais la bannière est rarement la partie coûteuse. Le script qui la dessine est petit. Le coût arrive à l'instant où quelqu'un accepte, quand tous les outils d'analyse, de publicité et de session que la bannière retenait se déclenchent d'un coup, sur un seul thread principal, après que votre page s'est déjà affichée.

Deux choses différentes s'appellent « la bannière »

Quand quelqu'un dit que sa bannière de cookies a ralenti le site, il décrit en général l'un de deux coûts distincts, et la différence décide de ce qu'il faut faire.

Le premier, c'est la couche de consentement elle-même : un script qui décide s'il faut afficher une boîte de dialogue, la dessine, enregistre la réponse et la diffuse. Ce travail est réellement léger. Un script de consentement, c'est une boîte de dialogue et un peu d'état, et les mieux construits se chargent en asynchrone et réservent leur propre espace.

Le second, c'est tout ce que la couche de consentement bloquait. Votre gestionnaire de balises, l'analytique, les pixels publicitaires, le rejeu de session, le widget de chat. Rien de tout cela ne s'est exécuté pendant que le visiteur décidait. Tout s'exécute à l'instant où il accepte, et comme la libération a lieu après le rendu de la page, elle atterrit sur un thread principal que le visiteur essaie déjà d'utiliser.

Ce qui implique quelque chose que la plupart des conseils de performance passent sous silence : un visiteur qui refuse obtient une page nettement plus rapide que celui qui accepte. Vous ne servez pas un site. Vous en servez deux, et votre monitoring en fait la moyenne.

Les quatre façons dont une bannière vous coûte vraiment

Les mécanismes sont bien documentés, et tous les quatre se corrigent.

Blocage du rendu. Un script de consentement chargé sans async ni defer retient l'analyseur pendant qu'il se télécharge. Ce délai s'applique avant que votre page ne puisse afficher quoi que ce soit, y compris lors des visites répétées où la réponse est déjà enregistrée et où la bannière n'apparaîtra jamais.

La bannière devient votre Largest Contentful Paint. Si elle couvre une grande part de la fenêtre d'affichage et arrive plus tard que votre visuel principal, le navigateur mesure la bannière à la place de votre contenu. Le seuil de Google est de 2.5 secondes, et une bannière qui s'affiche à 3 secondes vient de décider de votre score.

Décalage de mise en page. Une bannière injectée dans le flux du document plutôt que superposée par-dessus pousse vers le bas tout ce qui la suit. Cumulative Layout Shift est censé rester sous 0.1, et une barre pleine largeur qui apparaît une demi-seconde trop tard consommera ce budget à elle seule.

Le clic d'acceptation lui-même. Quand le gestionnaire de consentement initialise quatre fournisseurs de façon synchrone, le clic qui referme la bannière fige la page. Interaction to Next Paint est censé rester sous 200 millisecondes. Les gens remarquent celui-ci sans en connaître le nom, parce que c'est celui qui donne l'impression que le site est cassé.

Pourquoi votre score PageSpeed ne voit pas le parcours coûteux

Voici la faille de presque tous les articles sur le sujet. Lighthouse et PageSpeed Insights chargent votre page dans un profil vierge, sans consentement enregistré, prennent leurs mesures et s'arrêtent. Ils ne cliquent jamais sur rien. L'état qu'ils mesurent est donc l'état d'avant le choix : votre page, plus une bannière, avec toute la pile de balises encore bloquée derrière un bouton que personne n'a pressé.

C'est une vue légitime du premier visiteur. C'est aussi la page la moins coûteuse que vous serviez. Le parcours d'acceptation, l'état le plus lourd de votre site, n'apparaît jamais dans le score de laboratoire, si bien que les équipes optimisent le seul chiffre qu'elles voient pendant que le parcours coûteux reste non mesuré pendant des années. Il faut aller le regarder délibérément, et cela prend une dizaine de minutes.

Comment mesurer votre propre bannière, sur les deux parcours

1. Établir une référence avec la bannière désactivée

   Tracez la page avec le script de consentement entièrement bloqué, depuis le panneau de blocage de requêtes de votre navigateur. C'est le plancher. Sans lui, vous ne pouvez pas distinguer le coût du consentement du coût de ce que le consentement libère.

2. Mesurer l'état que voit un premier visiteur

   L'exécution PageSpeed Insights par défaut : profil neuf, aucun choix enregistré, bannière à l'écran. L'écart avec le plancher est le coût honnête de la bannière elle-même, et sur une bannière bien construite il est faible.

3. Enregistrer le parcours d'acceptation à la main

   Ouvrez le panneau de performance, lancez l'enregistrement, chargez la page, cliquez sur accepter et continuez d'enregistrer quelques secondes. Vous voyez alors ce qui arrive vraiment : combien de requêtes le choix déclenche et combien de temps le thread principal reste bloqué. Aucun score automatisé ne vous montrera cela, et c'est pourquoi si peu de gens l'ont regardé.

4. Enregistrer aussi le parcours de refus

   Refaites la trace et cliquez sur refuser. Sur un site où le Consent Mode v2 est câblé, vous devriez toujours voir partir des requêtes vers Google, sans aucun identifiant. C'est le fonctionnement prévu, pas une fuite, et cela vaut la peine de le vérifier de vos propres yeux avant que quelqu'un vous affirme le contraire.

5. Segmenter vos données terrain par état de consentement

   Les traces en laboratoire vous disent ce qui peut arriver ; les données terrain vous disent ce qui arrive. Un monitoring agrégé sur tous les visiteurs fait la moyenne d'un parcours de refus rapide et d'un parcours d'acceptation lent, et masque les deux. Si le vôtre accepte une dimension personnalisée, inscrivez-y l'état du consentement et lisez les deux populations séparément.

Ce que le Consent Mode change, et ce qu'il ne change pas

Beaucoup de guides décrivent encore le consentement comme un interrupteur : aucun script ne s'exécute tant que le visiteur n'a pas dit oui. C'est le comportement d'une couche de consentement bloquante, et pas du tout celui d'un site qui utilise le Consent Mode v2. En Consent Mode avancé, les balises de Google se chargent sur chaque page quelle que soit la réponse ; le signal change ce qu'elles ont le droit de stocker et d'envoyer, pas leur existence. Donc si votre plan pour accélérer le site consistait à conditionner les balises de Google au consentement, le poids ne disparaît pas. Seule la suppression d'une balise supprime son coût.

Le compromis mérite d'être nommé honnêtement, car c'est la vraie raison d'accepter ce poids. Câbler les signaux v2, c'est ce qui permet à Google de modéliser les conversions qu'un refus effacerait, ce qui, dans les projets clients d'Amplio Data, récupère entre 20 et 40 pour cent de la mesure que vous coûte une bannière de consentement. Ce sont des fourchettes mesurées sur des implémentations clients d'Amplio Data, pas une garantie. La récupération dépend de votre mix de trafic, de vos régions et de la configuration de vos balises. Un dispositif bloquant, c'est une page légèrement plus rapide qui rapporte moins de ce qui s'y est passé.

Le plancher que vous ne pouvez pas optimiser

Une partie de ce coût est permanente, et prétendre le contraire est exactement la façon dont les fournisseurs promettent ce qu'ils ne peuvent pas tenir. Vous paierez toujours le script qui décide s'il faut afficher une boîte de dialogue, la lecture de la réponse enregistrée avant l'initialisation de vos balises, et les balises dont vous avez réellement besoin.

Ce que vous pouvez supprimer, c'est le reste : le chargement synchrone, la barre injectée tardivement sans espace réservé, les quatre fournisseurs qui s'initialisent sur un seul clic, la balise que personne n'a regardée depuis 2023. D'après notre expérience, cette dernière est en général le plus gros gain disponible, et elle n'a rien à voir avec le consentement.

La vitesse compte aussi pour une deuxième raison, que nous traitons dans augmenter les taux d'acceptation sans dark patterns : une bannière qui rame se fait fermer par impatience plutôt que par préférence.

L'approche de Velo est la plus ennuyeuse qui soit. Servir la couche de consentement depuis l'edge, la garder asynchrone, réserver son espace pour que rien ne bouge, et transmettre le choix à vos balises assez vite pour que rien en aval n'attende. L'ingénierie intéressante se joue dans ce qui arrive après la réponse, pas dans la boîte de dialogue qui la recueille.