Core Web Vitals CLS : pourquoi les éléments qui bougent sur votre landing page font perdre des clics

Un visiteur arrive sur votre page de vente, commence à lire l’argument principal, et au moment précis où il s’apprête à cliquer sur le bouton d’achat, celui-ci se décale de quelques centimètres — le temps qu’une bannière de consentement aux cookies, une police de caractères ou une image sans dimension définie finisse de s’afficher. Le clic tombe alors sur autre chose : un lien de menu, une image, le vide. Ce phénomène a un nom et un score officiel chez Google depuis 2020 : le CLS, ou Cumulative Layout Shift — la stabilité visuelle d’une page pendant son chargement.

Ce que mesure le CLS

Le CLS additionne, sur toute la durée de vie d’une page, l’ampleur de chaque décalage visuel inattendu d’un élément déjà visible à l’écran — pas le premier affichage d’un contenu qui apparaît depuis un espace vide, mais le déplacement d’un élément qui occupait déjà une position stable. Chaque décalage est pondéré par deux facteurs : la part de l’écran affectée par le mouvement, et la distance parcourue par les éléments qui bougent. Un bouton qui descend de deux centimètres pèse donc plus lourd dans le score qu’un léger réajustement de quelques pixels sur un élément secondaire. C’est le troisième des trois Core Web Vitals de Google, aux côtés du LCP (vitesse d’affichage) et de l’INP (réactivité aux clics), que nous détaillons chacun dans un article séparé.

Le seuil qui compte : 0,1

Google fixe trois paliers, mesurés au 75ᵉ centile des visites réelles sur une fenêtre glissante de 28 jours (données CrUX) : un CLS inférieur à 0,1 est jugé « bon », entre 0,1 et 0,25 il « nécessite une amélioration », au-delà de 0,25 il est « mauvais ». Contrairement au LCP ou à l’INP, le CLS n’a pas d’unité de temps : c’est un score sans dimension, cumulé sur toute la session, qui peut continuer à grimper bien après le premier affichage si de nouveaux éléments — bandeau, popup, publicité tierce — viennent perturber la mise en page en cours de visite.

Pourquoi ce n’est pas qu’un score technique

Le mécanisme derrière le CLS n’est pas propre au web : c’est celui de l’interruption d’une tâche en cours. Une étude de Brian P. Bailey et Joseph A. Konstan, publiée dans Computers in Human Behavior en 2006, a mesuré l’effet d’interruptions inattendues sur des utilisateurs en train d’exécuter une tâche à l’écran : les participants interrompus mettaient de 3 à 27 % de temps supplémentaire pour terminer leur tâche, commettaient environ deux fois plus d’erreurs, et rapportaient une hausse mesurable d’anxiété et de frustration par rapport aux groupes non interrompus (Bailey & Konstan, 2006). Un décalage de mise en page au moment où un visiteur s’apprête à cliquer reproduit exactement ce schéma à l’échelle d’une fraction de seconde : l’action prévue échoue, le visiteur doit recommencer, et l’expérience laisse une impression négative — même s’il finit par trouver le bon bouton. Sur une landing page où chaque clic doit se faire sans friction, ce coût invisible se traduit directement en clics perdus ou en abandons.

Les causes les plus fréquentes sur une landing page

• Images et vidéos sans dimensions définies — sans attribut width/height ni aspect-ratio CSS, le navigateur ne réserve aucun espace et pousse le contenu suivant dès que le fichier finit de charger.
• Polices web qui changent la taille du texte — un repli sur police système suivi du chargement de la police définitive (FOUT) peut changer la largeur du texte et donc la hauteur des blocs, en particulier sur les titres.
• Bandeau de consentement aux cookies injecté en haut de page — s’il pousse le contenu vers le bas au lieu de s’afficher en overlay, il décale tout ce qui est déjà visible, souvent pile au moment où le visiteur commence à lire ; voir notre article sur le bandeau de cookies.
• Popups et notifications injectées après coup — popup de bienvenue, notification d’achat en temps réel ou widget de chat qui s’ouvrent quelques secondes après le chargement et repoussent le contenu plutôt que de se superposer à lui.
• Publicités et embeds tiers sans emplacement réservé — un iframe publicitaire ou une vidéo intégrée qui ne révèle sa taille finale qu’une fois chargée.
• Contenu inséré dynamiquement au-dessus d’un élément existant — un message d’erreur de formulaire, une alerte de stock ou un badge de réduction ajouté juste au-dessus du bouton d’achat plutôt qu’à un emplacement déjà réservé.

Corriger le CLS sans sacrifier le design

La règle générale est simple : tout espace destiné à accueillir un contenu qui arrive après coup doit être réservé à l’avance, à la taille exacte qu’il occupera. Pour les images et vidéos, définir systématiquement width et height (ou une propriété CSS aspect-ratio) permet au navigateur de calculer l’espace nécessaire avant même que le fichier ne soit téléchargé — le composant Image de Next.js impose cette dimension par défaut, ce que nous détaillons dans notre article sur le déploiement Next.js sur Vercel. Pour les polices web, la propriété font-display: swap limite l’attente sans empêcher le changement de police, mais c’est surtout size-adjust (ou le choix d’une police système visuellement proche comme repli) qui évite que le changement de police ne modifie la hauteur du bloc de titre. Pour les bandeaux, popups et notifications, la solution la plus fiable reste l’overlay en position fixed ou absolute plutôt que l’insertion qui pousse le contenu existant : le visiteur voit l’élément apparaître par-dessus la page, jamais au prix d’un décalage de ce qu’il était déjà en train de lire.

Le cas particulier des éléments qui apparaissent après un délai

Un compte à rebours qui s’initialise après un court délai JavaScript, comme sur le template Webinaire & Masterclass (démo), ou un message de confirmation qui remplace un formulaire après soumission, doivent occuper dès le rendu initial un espace identique à celui de leur état final — un bloc vide de la bonne hauteur, plutôt qu’un conteneur qui grandit une fois le contenu réel injecté. C’est le même principe que nous développons pour les skeleton screens : ils doivent annoncer la forme exacte du contenu à venir, pas une estimation approximative qui décale tout au moment du remplacement.

Vérifier le résultat sur le terrain

Comme pour le LCP et l’INP, le score qui compte est celui mesuré sur le terrain — le rapport « Signaux Web essentiels » de Google Search Console agrège les données CrUX réelles de vos visiteurs une fois le trafic suffisant. En local, l’onglet Performance de Chrome DevTools affiche chaque décalage détecté avec l’élément responsable et son score individuel, ce qui permet de corriger un par un les décalages les plus coûteux plutôt que de deviner. Un CLS propre ne se voit pas dans un rapport : il se ressent en scrollant et en cliquant sur la page comme le ferait un visiteur pressé, sans jamais avoir l’impression que quelque chose bouge sous ses doigts.

Partir d’une base déjà stable visuellement

Les 10 templates LanderKit réservent nativement l’espace des images, boutons et sections dynamiques dès le rendu initial, sans bandeau ni popup imposés qui viendraient perturber la mise en page une fois le trafic publicitaire lancé. Vous pouvez vérifier la stabilité visuelle d’un template avant d’y ajouter vos propres scripts sur la démo liste d’attente SaaS ou la démo e-commerce (89 € l’unité, 229 € le pack complet).