Le CLS (Cumulative Layout Shift) mesure les décalages visuels imprévus d'une page : une image qui pousse le texte vers le bas, une bannière qui s'insère au-dessus du contenu, une police qui change la hauteur d'un titre. C'est la métrique de stabilité visuelle des Core Web Vitals. Le seuil "Bon" de Google est inférieur à 0,1 au 75e percentile des visites réelles. La règle d'or tient en une phrase : réserver l'espace de chaque élément avant son chargement.
Ce guide détaille comment le CLS est calculé, comment identifier les éléments qui bougent, et les correctifs par cause - images, publicités, polices, animations - pour stabiliser durablement vos pages.
Qu'est-ce que le CLS, concrètement ?
Le CLS répond à la question : "la page reste-t-elle stable pendant que je la lis ?". Un décalage de mise en page survient quand un élément visible change de position d'un frame à l'autre sans interaction de l'utilisateur. L'exemple classique : vous alliez taper "Annuler" et la page a bougé, vous avez tapé "Confirmer".
Selon la définition officielle sur web.dev, le score d'un décalage est le produit de deux facteurs : la fraction d'impact (la part de l'écran affectée) et la fraction de distance (l'ampleur du déplacement). Le CLS retient la pire rafale de décalages (session window) de toute la vie de la page - pas seulement le chargement initial, ce qui explique les écarts fréquents entre lab et field.
Deux exclusions importantes : les décalages survenant dans les 500 ms après une interaction sont considérés comme attendus et ignorés, et les éléments animés via transform ne déclenchent pas de layout shift.
Quel est un bon score CLS en 2026 ?
Les seuils officiels, identiques sur mobile et desktop, à atteindre au 75e percentile des visites réelles :
| Statut | Seuil CLS |
|---|---|
| Bon | < 0,1 |
| À améliorer | 0,1 - 0,25 |
| Mauvais | > 0,25 |
Le CLS est sans unité : 0,1 correspond approximativement à 10 % de la surface visible déplacée sur une distance significative. C'est peu - une seule bannière injectée en haut de page peut suffire à faire exploser le score.
Comment mesurer et diagnostiquer le CLS ?
Commencez par PageSpeed Insights : la donnée field (CrUX) donne le verdict réel, et la section diagnostics liste les éléments qui se déplacent. Le rapport Core Web Vitals de Search Console agrège la vue site entier par type de page.
Pour le diagnostic fin, l'onglet Performance de Chrome DevTools affiche chaque layout shift sur la timeline avec l'élément déplacé, et l'insight Layout shift culprits identifie automatiquement les coupables. En field, la librairie web-vitals avec attribution remonte les éléments responsables chez vos vrais visiteurs.
Piège à connaître, documenté dans le guide d'optimisation officiel : un CLS bon en lab mais mauvais en field signale presque toujours des décalages tardifs - publicités chargées en cours de lecture, contenu en lazy loading sans espace réservé, bannières de consentement - invisibles lors d'un audit qui s'arrête au chargement.
Comment optimiser le CLS ? Les correctifs par cause
Un même principe traverse tous les correctifs : le navigateur doit connaître l'espace occupé par chaque élément avant que son contenu n'arrive.
Déclarer les dimensions des images et iframes
Ajoutez systématiquement les attributs width et height sur les <img> et <iframe> : le navigateur en déduit le ratio et réserve l'espace avant le téléchargement, comme expliqué sur MDN à propos d'aspect-ratio. Pour les conteneurs responsives et les embeds (vidéos, cartes, réseaux sociaux), la propriété CSS aspect-ratio remplit le même rôle.
Réserver l'espace du contenu dynamique
Bannières publicitaires, widgets, contenus recommandés, bannières de consentement : tout ce qui est injecté après le rendu initial doit avoir un emplacement pré-dimensionné en CSS (min-height sur le slot), quitte à afficher un espace vide si le contenu ne se charge pas. Règle absolue : ne jamais insérer de contenu au-dessus de l'existant, sauf en réponse à une interaction. Les publicités sont la première cause de CLS field sur les sites média.
Maîtriser le chargement des polices web
Une police web qui remplace la police de secours peut changer la hauteur de chaque ligne de texte (FOUT). Les leviers, détaillés dans le guide des bonnes pratiques polices de web.dev : précharger la police critique avec <link rel="preload">, utiliser font-display: optional pour les cas stricts, et ajuster la police de secours avec les descripteurs size-adjust et ascent-override pour que la permutation soit géométriquement neutre.
Animer avec transform, jamais avec la géométrie
Les animations de top, left, width, height ou margin déclenchent des layout shifts et des recalculs coûteux. Utilisez transform: translate() et scale() : ces propriétés sont composées hors du flux de mise en page et sont exclues du calcul du CLS.
Quelles erreurs font échouer le CLS le plus souvent ?
Quatre patterns dominent les audits : l'image hero sans width/height qui pousse tout le contenu à son arrivée, la bannière (promo, consentement, app mobile) injectée en haut de page, l'embed tiers (YouTube, réseaux sociaux, carte) sans conteneur dimensionné, et la police web au chargement non maîtrisé. Ces quatre correctifs règlent la grande majorité des scores rouges.
Comment suivre le CLS dans le temps ?
Le CLS régresse silencieusement : une nouvelle campagne publicitaire, un widget marketing ajouté, un changement de police, et le score bascule sans qu'aucun développeur n'ait touché au code. Pour un suivi continu, WebCoreFlow interroge CrUX et PageSpeed Insights de façon programmée et historise le CLS de vos pages réelles, ce qui permet de dater précisément une régression et de la relier à sa cause.
Combien de temps pour voir un résultat ?
Comptez 28 jours sur la donnée field, la durée de la fenêtre glissante de CrUX. La validation lab est immédiate : après correction, la timeline de Chrome DevTools ne doit plus montrer de layout shift sur le chargement, et les parcours avec scroll doivent rester stables. Si le field résiste après un cycle complet, cherchez les décalages tardifs que l'audit de chargement ne voit pas.
Sources et références
Analysez votre site en 30 secondes.
Obtenez votre score Core Web Vitals et un plan d'action concret pour grimper dans Google. Sans carte bancaire.
Questions fréquentes
- Qu'est-ce que le CLS (Cumulative Layout Shift) ?
- Le CLS mesure les décalages visuels imprévus pendant la vie d'une page : une image qui pousse le texte, une bannière qui s'insère, une police qui change la hauteur d'un titre. C'est la métrique officielle de stabilité visuelle des Core Web Vitals de Google. Sans unité, elle combine la surface déplacée et la distance du déplacement.
- Quel est un bon score CLS ?
- Un bon CLS est inférieur à 0,1, mesuré au 75e percentile des visites réelles (données CrUX), sur mobile comme sur desktop. Entre 0,1 et 0,25, le statut est \"À améliorer\" ; au-delà de 0,25, il est \"Mauvais\".
- Quelles sont les causes les plus fréquentes d'un mauvais CLS ?
- Quatre causes dominent : les images et iframes sans dimensions déclarées, le contenu injecté dynamiquement au-dessus de l'existant (bannières, publicités, widgets), les polices web qui provoquent un reflow au chargement (FOUT), et les animations qui modifient la géométrie des éléments au lieu d'utiliser transform.
- Un décalage déclenché par un clic compte-t-il dans le CLS ?
- Non, à condition qu'il survienne dans les 500 ms suivant l'interaction. Un accordéon qui s'ouvre au clic est un décalage attendu et exclu du calcul. Seuls les décalages imprévus, sans interaction récente de l'utilisateur, pénalisent le score.
- Pourquoi mon CLS est-il bon en lab mais mauvais en field ?
- Parce que Lighthouse ne mesure que le chargement initial, alors que le CLS field couvre toute la vie de la page, scroll inclus. Les décalages tardifs - publicités qui se chargent en cours de lecture, contenus en lazy loading sans espace réservé - n'apparaissent qu'en field. C'est la donnée field que Google utilise.
- Comment identifier les éléments qui causent du CLS ?
- PageSpeed Insights liste les éléments concernés dans la section dédiée. Pour aller plus loin, l'onglet Performance de Chrome DevTools affiche chaque layout shift sur la timeline avec l'élément déplacé, et l'insight Layout shift culprits identifie les coupables automatiquement.