Pour la plupart des visiteurs européens, la première chose qui apparaît sur un site n’est pas le contenu, mais le bandeau de cookies. C’est une obligation du droit de la protection des données, et c’est aussi un élément d’interface aux conséquences précises sur la performance : il se charge à chaque première visite, occupe une grande partie de l’écran, et le clic sur « Accepter » ou « Refuser » est souvent la première interaction de l’utilisateur avec la page.
Pour cette raison précise, un bandeau de cookies mal conçu peut dégrader les trois Core Web Vitals : il peut devenir l’élément LCP, il peut déplacer le contenu et générer du CLS, et il peut ralentir la première interaction, ce qui dégrade l’INP. Dans cet article, nous voyons comment cela se produit et comment mettre en œuvre le consentement de manière conforme sans sacrifier la performance. Il ne s’agit pas d’un conseil juridique : les décisions sur le contenu du bandeau doivent être prises avec la personne qui gère la conformité, mais la manière dont il est chargé et affiché relève de la technique.
Le bandeau comme élément LCP
Le Largest Contentful Paint mesure le moment où le plus grand élément visible sur l’écran initial est affiché. Sur un smartphone, un bandeau de cookies au texte long, qui occupe la moitié de l’écran ou plus, peut facilement être plus grand que l’image principale ou que le titre de la page. Dans ce cas, l’élément LCP n’est pas le contenu, mais le texte du bandeau.
Le problème devient sérieux quand le bandeau arrive tard. De nombreuses plateformes de gestion du consentement chargent le bandeau par un script externe, que le navigateur télécharge après le HTML, parfois après d’autres scripts, et qui demande à son tour sa configuration et ses textes à un serveur distant. Le bandeau n’est affiché qu’au bout de cette chaîne, souvent avec une animation d’entrée. S’il est le plus grand élément, le LCP de la page coïncide avec son arrivée, même quand le contenu était prêt bien avant.
Les solutions agissent sur deux fronts. Le premier est la taille : un bandeau compact, avec un texte court et un lien vers l’information complète, occupe moins de place que le contenu principal et ne devient pas l’élément LCP. Il est aussi plus respectueux de l’utilisateur, qui voit tout de suite la page qu’il cherchait. Le second est le moment : si le bandeau doit être grand, il devrait au moins apparaître tôt. Son balisage et son CSS peuvent être inclus directement dans le HTML, ou bien le script de la plateforme peut être chargé en priorité, avec un preconnect vers le domaine d’où il provient et sans dépendre d’autres scripts.
Un détail souvent négligé concerne les animations. Un bandeau qui apparaît en fondu à partir d’une opacité nulle n’est pris en compte par le navigateur que lorsqu’il devient visible, et une animation lente retarde donc le LCP si le bandeau est le plus grand élément. Une apparition immédiate, ou une animation fondée uniquement sur la position, évite le problème.
Le bandeau et le CLS
Le deuxième problème est le décalage de mise en page. Un bandeau inséré dans le flux de la page, par exemple une barre en haut qui repousse tout le contenu vers le bas quand elle apparaît, génère un décalage qui s’ajoute au CLS. La même chose se produit, en sens inverse, quand le bandeau disparaît après le clic et que le contenu remonte.
La solution est simple : le bandeau doit se superposer au contenu, avec un positionnement fixe, et ne pas être inséré dans le flux de la page. Un panneau fixe en bas, ou une fenêtre modale, ne déplace rien quand il apparaît ni quand il disparaît. Il faut aussi éviter le blocage du défilement appliqué au corps de la page tant que le bandeau est ouvert : sur ordinateur, la disparition de la barre de défilement élargit la page de quelques pixels et décale tout le contenu. Si le blocage est nécessaire, la propriété CSS scrollbar-gutter: stable réserve l’espace de la barre de défilement et évite le décalage.
.banner-consenso {
position: fixed;
inset: auto 0 0 0; /* ancré en bas, au-dessus du contenu */
max-height: 40vh; /* n’occupe pas tout l’écran */
overflow: auto;
z-index: 1000;
}
html {
scrollbar-gutter: stable; /* aucun décalage si le défilement est bloqué */
}Le clic sur « Accepter » et l’INP
Le troisième problème, et souvent le plus grave, concerne l’INP. Quand l’utilisateur accepte les cookies, la plateforme de consentement doit activer tous les outils qui attendaient : analytics, pixels publicitaires, heatmaps, chat, vidéos intégrées. Dans de nombreuses implémentations, tout cela se passe dans le même gestionnaire d’événement de clic : le navigateur insère des dizaines de scripts, les exécute, et ce n’est qu’à la fin qu’il peut afficher la fermeture du bandeau. L’utilisateur appuie sur le bouton et, pendant une demi-seconde, rien ne se passe.
Comme il s’agit souvent de la première interaction et, pour beaucoup d’utilisateurs, de l’une des rares de la visite, ce clic peut à lui seul déterminer l’INP d’une page. La solution suit le principe vu dans l’article sur le thread principal : donner un retour visuel immédiat, rendre la main au navigateur et ne faire le travail lourd qu’ensuite.
pulsanteAccetta.addEventListener( 'click', async () => {
banner.hidden = true; // 1. retour immédiat
salvaConsenso( 'accettato' );
await new Promise( ( r ) => setTimeout( r, 0 ) ); // 2. laisser le navigateur afficher
attivaStrumenti(); // 3. analytics, pixels et autres tags
} );Si vous utilisez une plateforme commerciale, il vaut la peine de vérifier si elle propose ce mode ou si elle active les tags de façon différée. Dans bien des cas, le problème n’est pas la plateforme mais le nombre d’outils activés au moment du consentement : c’est une occasion de plus de passer en revue les scripts tiers réellement nécessaires.
Le consent mode de Google
Pour ceux qui utilisent les outils de Google, le consent mode propose une approche différente : les tags sont chargés dès le départ dans un mode limité, sans cookies, et au moment du consentement ils reçoivent seulement une mise à jour d’état, au lieu d’être chargés à partir de zéro. Du point de vue de la performance, cela déplace le travail du clic vers le chargement de la page : le clic devient plus léger, mais les scripts sont tout de même téléchargés et exécutés pendant le chargement. Il faut donc l’évaluer avec le reste de la stratégie de chargement, par exemple en différant le gestionnaire de balises jusqu’après le premier affichage.
Le poids de la plateforme
Les plateformes de gestion du consentement varient beaucoup en poids et en comportement. Certaines chargent quelques kilo-octets et affichent le bandeau presque immédiatement ; d’autres téléchargent des centaines de kilo-octets de JavaScript, des listes de fournisseurs, des traductions, des feuilles de style et des polices propres, même pour les utilisateurs qui ont déjà donné leur consentement lors de visites précédentes. Au moment du choix, il vaut la peine de comparer, en plus des fonctionnalités et de la conformité, le poids du script, le nombre de requêtes, la possibilité d’héberger les ressources sur son propre domaine et le comportement pour les visiteurs récurrents.
Pour ceux qui ont déjà donné leur consentement, l’idéal est que la plateforme lise le choix dans un cookie ou dans le stockage local et n’affiche ni ne charge rien de superflu. C’est le cas le plus fréquent sur les sites à nombreux visiteurs récurrents, et celui où un bandeau lourd est le plus difficile à justifier.
Le cas de WordPress
Sur WordPress, le bandeau est généralement géré par un plugin, qui peut afficher son propre bandeau ou intégrer une plateforme externe. Les réglages à vérifier sont toujours les mêmes : position et taille du bandeau, animations d’entrée, manière dont les scripts sont bloqués puis débloqués, chargement du plugin sur chaque page ou seulement là où c’est nécessaire. Certains plugins génèrent le bandeau côté serveur, directement dans le HTML, et sont généralement les plus rapides à l’afficher ; d’autres le construisent via JavaScript après le chargement.
Un point délicat est l’interaction avec les caches de page. Si le bandeau est inséré dans le HTML par le serveur, la page en cache doit être la même pour ceux qui ont déjà donné leur consentement et pour ceux qui ne l’ont pas fait : le bandeau doit donc toujours être inclus et affiché ou masqué par le navigateur selon le cookie, ou chargé séparément. Les configurations qui génèrent des versions différentes de la page selon le cookie de consentement réduisent l’efficacité du cache et dégradent le TTFB précisément pour les nouveaux visiteurs.
Un exemple typique
Un site d’information constate dans ses données de terrain un LCP mobile de 3,2 secondes, alors que les tests de laboratoire indiquent 1,6. Le RUM révèle que l’élément LCP le plus fréquent est le paragraphe du bandeau de cookies, long et chargé depuis une plateforme externe après les scripts publicitaires. Le clic sur « Accepter », en outre, active une douzaine de tags et enregistre un INP supérieur à 400 millisecondes. Trois interventions : texte du bandeau ramené à deux lignes avec un lien vers l’information sur la confidentialité, script de la plateforme chargé en premier avec un preconnect, activation des tags reportée après la fermeture du bandeau. En un mois, les données de terrain montrent un LCP mobile sous 2,5 secondes et un INP de la première interaction dans la plage « bon », sans aucune modification des choix de consentement.
Attention aux tests de laboratoire
Il existe un piège important dans la mesure de ces effets. De nombreuses plateformes n’affichent le bandeau qu’aux visiteurs de l’Union européenne, selon leur localisation. Les tests de laboratoire de PageSpeed Insights et d’autres outils sont souvent exécutés depuis des serveurs situés hors d’Europe : le bandeau n’apparaît pas, et le test montre une page différente de celle que voit la plupart des utilisateurs européens. Le résultat est un LCP et un CLS apparemment excellents en laboratoire, et des données de terrain bien plus mauvaises, comme nous l’avons vu dans l’article expliquant pourquoi il faut à la fois CrUX et les données de laboratoire.
Pour évaluer correctement l’impact du bandeau, il est donc préférable d’utiliser des outils qui permettent de choisir une localisation européenne, d’exécuter des tests depuis un navigateur local avec les DevTools, en veillant à effacer les cookies pour simuler une première visite, et surtout de regarder les données d’utilisateurs réels. Un système de Real User Monitoring avec attribution montre rapidement si l’élément LCP le plus fréquent est le texte du bandeau et si l’interaction la plus lente est le clic sur ses boutons.
Une checklist pour le bandeau
- Le bandeau est compact et ne dépasse pas, par sa taille, le contenu principal de l’écran initial.
- Il apparaît immédiatement, sans fondus lents et sans dépendre d’une longue chaîne de scripts.
- Il se superpose au contenu avec un positionnement fixe et ne décale pas le contenu quand il apparaît ou disparaît.
- Le clic sur les boutons ferme immédiatement le bandeau et n’active les tags qu’après l’affichage.
- Pour ceux qui ont déjà choisi, il ne charge rien de superflu.
- Il est testé depuis une localisation européenne, cookies effacés, et vérifié par rapport aux données de terrain.
En bref
Le bandeau de cookies est le premier élément que voit et touche la plupart des visiteurs européens, et pour cette raison il peut peser sur les trois Core Web Vitals : devenir l’élément LCP quand il est grand et arrive tard, générer du CLS quand il repousse le contenu, dégrader l’INP quand le clic de consentement active tous les outils d’un coup.
Un bandeau compact, affiché immédiatement, superposé au contenu et doté d’un gestionnaire de clic qui répond avant d’activer les tags résout la plupart de ces problèmes, sans aucun compromis sur la conformité. Conformité réglementaire et performance ne s’opposent pas : elles ne le deviennent que lorsque le consentement est mis en œuvre sans penser à ceux qui doivent le donner, c’est-à-dire les utilisateurs qui attendent de voir la page.
