Qu'est-ce que le Cumulative Layout Shift (CLS) et comment le corriger

Qu'est-ce que le Cumulative Layout Shift (CLS) ?

Le Cumulative Layout Shift (CLS) représente le volet « stabilité visuelle » des Core Web Vitals. Le CLS mesure les mouvements de la page pendant le rendu du contenu ou l'apparition de nouveaux éléments. Vous le remarquez quand vous perdez le fil de l'article que vous lisiez, ou quand vous cliquez sur le mauvais bouton parce qu'il a bougé sous votre doigt. On l'appelle parfois « content layout shift », mais le nom de la métrique est Cumulative Layout Shift.

Qu'est-ce qu'un bon score de Cumulative Layout Shift (CLS) ?

Un bon score CLS se situe entre 0 et 0,1. Entre 0,1 et 0,25, il est à améliorer. Au-delà de 0,25, il est considéré comme mauvais. Pour valider les Core Web Vitals sur le Cumulative Layout Shift, au moins 75 % des visites de votre page doivent obtenir un score « bon ». C'est le p75 de vos field data, mesuré séparément sur mobile et sur desktop. Le CLS n'a pas d'unité : c'est un score, là où le LCP et l'INP sont des durées.

Le rapport Core Web Vitals de Google Search Console regroupe les URL en échec par problème. L'intitulé « Problème CLS : supérieur à 0,1 (mobile) » signale des pages à améliorer, « Problème CLS : supérieur à 0,25 (ordinateur) » des pages mauvaises, et ces deux seuils existent pour chaque type d'appareil. Search Console calcule la moyenne de vos field data sur une période glissante. Un fix ne fait donc pas passer le rapport au vert le jour de sa mise en ligne : pendant plusieurs semaines, les données affichées reflètent encore en partie l'ancien site.

Ce que vous coûte un décalage de mise en page

Une page qui saute dans tous les sens donne l'impression d'être cassée, même quand tout fonctionne.

• Visiteurs et image de marque : un décalage interrompt le visiteur dans son action. Il perd la ligne qu'il lisait ou appuie sur le mauvais lien, et certains finissent par quitter le site. Un site qui bouge sans arrêt donne aussi l'impression d'être mal conçu, ce qui rejaillit sur l'entreprise.
• Accessibilité : les décalages de mise en page sont encore plus pénalisants quand on ne voit qu'une partie de l'écran, par exemple avec un zoom ou une loupe d'écran. Un seul décalage peut faire sortir de l'écran le texte que vous lisiez.
• SEO et classement dans les résultats de recherche : les systèmes de classement de Google utilisent les Core Web Vitals, et le CLS en fait partie. Son poids reste modeste. Google indique qu'il affiche toujours le contenu le plus pertinent en premier, et qu'une bonne expérience de page aide à départager des pages à la pertinence équivalente.

Comment mesure-t-on le CLS ?

Les navigateurs signalent les décalages de mise en page via l'Layout Instability API. Collez ce code dans la console pour afficher chaque décalage :

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Chaque entrée possède une propriété value, qui correspond au score du décalage, et une liste sources contenant les éléments déplacés. Les décalages survenant juste après un clic ont la propriété hadRecentInput définie sur true. Ils sont enregistrés ici, mais ne comptent pas dans le CLS.

Calcul du CLS

Chaque décalage reçoit son propre score :

score de décalage = fraction d'impact * fraction de distance

La fraction d'impact mesure la surface du viewport touchée par les éléments instables, en cumulant leur position avant et après le décalage. La fraction de distance mesure la distance parcourue, par rapport à la plus grande dimension du viewport (sur un téléphone, la hauteur).

Prenons un élément qui couvre la moitié du viewport et descend de 25 % de la hauteur du viewport. Avant et après réunis, il couvre 75 % du viewport. Cela donne une fraction d'impact de 0,75 et une fraction de distance de 0,25, soit un score de 0,75 * 0,25 = 0,1875 pour ce décalage. À lui seul, un tel décalage dépasse déjà 0,1. Le CLS de la page additionne ces scores par fenêtre de session, comme expliqué ci-dessous.

Décalages attendus et inattendus

Quand vous cliquez sur un lien « charger plus d'éléments », vous vous attendez à voir de nouveaux éléments apparaître et à ce que la page bouge. C'est pourquoi seuls les décalages inattendus sont comptabilisés dans le CLS. Tout décalage survenant dans les 500 millisecondes après un clic, un appui ou une frappe au clavier est exclu du calcul. Un menu déroulant qui s'ouvre au clic ne vous coûte donc rien. Le scroll ne compte pas comme une interaction, nous y reviendrons plus bas.

Sessions de décalage

À ses débuts, le CLS cumulait chaque décalage sur toute la durée de vie de la page. Les pages restant ouvertes longtemps, comme les flux infinis et les single-page apps, accumulaient un score toujours plus élevé. Depuis juin 2021, le CLS se calcule en sessions. Chaque session dure 5 secondes au maximum et se termine dès qu'une seconde complète s'écoule sans décalage. La session affichant le score le plus élevé devient le score CLS final.

Si une première session atteint 0,095, la suivante 0,15 et la dernière 0, le score CLS final est le plus élevé des trois : 0,15.

Causes courantes de CLS

Tous les décalages de mise en page fonctionnent de la même façon. Après le rendu initial de la page, un élément change de taille ou de position, déplaçant tout ce qui le suit dans la mise en page. Voici les causes les plus fréquentes :

Images, vidéos et iframes sans dimensions

Les médias sans dimensions sont l'une des causes de CLS les plus courantes. Le navigateur ne découvre la taille d'une image qu'à l'arrivée des premiers octets du fichier. D'ici là, sans attributs width et height (ou sans propriété CSS aspect-ratio), il ne réserve aucun espace et l'image a une hauteur nulle. Quand elle charge, tout ce qui se trouve en dessous est repoussé vers le bas.

Comment les images et les médias provoquent des décalages de mise en page aborde les images, vidéos et iframes sans dimensions, le piège du width: auto en CSS, la direction artistique, les incohérences d'images responsives, le lazy loading et les images placeholders.

Swaps de polices web

Pendant le téléchargement de la police web, la page affiche son texte avec une police de fallback. Dès que la police web arrive, le texte se réorganise. Des largeurs de lettres et des hauteurs de ligne différentes modifient les retours à la ligne, et chaque bloc situé sous ce paragraphe se déplace.

L'audit Lighthouse « Ensure text remains visible during webfont load » incite à utiliser font-display: swap. Pour le CLS, cela ne règle rien à soi seul : le texte s'affiche plus vite avec la police de fallback, mais le swap continue de le déplacer. La solution consiste à utiliser une police de fallback qui occupe le même espace, grâce aux métriques @font-face comme size-adjust et ascent-override. Servez ensuite la police plus rapidement grâce à l'auto-hébergement et au préchargement des polices critiques. Le guide d'identification et de correction fournit le code.

Animations et transitions CSS

Animez top, left, width ou height, et le navigateur recalculera le layout à chaque frame. Chacune de ces frames peut être un layout shift. Les propriétés transform et opacity ne déclenchent jamais de calcul de layout : privilégiez-les pour déplacer vos éléments. L'article Décalage de mise en page causé par les transitions CSS détaille la correction.

Publicités, intégrations et contenu injecté dynamiquement

Les publicités chargent tard et repoussent le contenu vers le bas. Un bandeau de cookies affiché en surimpression ne décale rien, mais s'il est inséré en haut de page, il repousse toute la page vers le bas. Les requêtes AJAX provoquent le même problème lorsqu'elles injectent du contenu sans réserver d'espace. Dans chaque cas, un élément arrive sur la page alors que le navigateur ignorait tout de lui lors de la mise en page initiale. Réservez l'espace dès le départ, par exemple avec un min-height sur le conteneur. Pour les intégrations tierces comme YouTube et Google Maps, le pattern de façade supprime complètement le CLS.

Décalages déclenchés par le défilement

Un test de chargement Lighthouse ne fait pas défiler la page ; il ne détectera donc pas cette cause de CLS. Les en-têtes qui se masquent au défilement, les effets de parallaxe et les barres de navigation qui rétrécissent animent souvent top ou height. Le défilement ne fait pas partie des interactions exclues dans la spécification Layout Instability : chaque décalage qu'il provoque compte donc dans le score CLS. Utilisez transform: translateY() pour tout élément qui se déplace au défilement. L'article Comment les animations déclenchées au défilement provoquent du CLS donne tous les détails.

Identifier et corriger les problèmes de CLS

Commencez par les field data. Un test en lab data ne voit que les premières secondes du chargement de la page, alors que les visiteurs font défiler l'écran, attendent les publicités et poursuivent leur lecture. Vérifiez le p75 du CLS séparément sur mobile et sur desktop : pour le CLS, le desktop est souvent le pire des deux. Google Search Console montre quels groupes de pages sont en échec. Un outil RUM comme CoreDash enregistre également quel élément s'est déplacé : vous voyez ainsi s'il s'agit de l'image produit sur un template ou de l'encart publicitaire sur un autre. Observez aussi la tendance. Une hausse brutale signifie généralement qu'un déploiement a ajouté quelque chose, comme une nouvelle bannière ou un encart publicitaire.

Reproduisez ensuite le problème dans Chrome DevTools ou avec l'extension Core Web Vitals Visualizer et identifiez ce qui le fait bouger. Le diagnostic étape par étape, les démonstrations d'outils, les correctifs de code pour chaque cause et une checklist de résolution rapide sont réunis dans Identifier et corriger les problèmes de Cumulative Layout Shift (CLS).

Étude de cas : le test A/B de Rakuten 24 sur les Core Web Vitals

Rakuten 24, une boutique en ligne japonaise, a optimisé pour les Core Web Vitals une landing page à fort trafic. Elle l'a comparée à l'originale pendant un mois, avec 50 % du trafic sur chaque version. Pour le CLS, l'équipe a réservé de l'espace pour les images avec la propriété CSS aspect-ratio et pour les éléments en lazy loading avec min-height. Le CLS de la page optimisée a baissé de 92,72 %. Elle a également fini de charger 0,4 seconde plus tôt lors de leur test de chargement sur mobile, avec un meilleur FCP et un meilleur TTFB. Par rapport à l'originale, la page optimisée a enregistré :

• 53,37 % de revenus en plus par visiteur
• 33,13 % de hausse du taux de conversion
• 15,20 % de hausse sur le panier moyen
• 35,12 % de baisse du taux de sortie

Le CLS a représenté la plus forte amélioration du test, mais le temps de chargement, le FCP et le TTFB ont progressé aussi. Ces résultats reviennent donc à l'ensemble de l'optimisation. Ne les citez pas comme la valeur du CLS à lui seul.

Ce que montrent les données réelles sur le CLS

Dans le Chrome UX Report d'août 2026, 81,5 % des origines affichaient un bon CLS, contre 80,1 % en août 2025.

Sur corewebvitals.io lui-même, CoreDash mesure le CLS comme le Core Web Vital le plus performant. Sur l'ensemble des chargements de page, 92,8 % obtiennent un score « bon », avec un écart presque nul entre desktop (92,8 % de « bon ») et mobile (92,7 % de « bon »). Tous deux ont un p75 de 0 : au moins les trois quarts des chargements de page n'ont donc subi aucun décalage de mise en page.

À l'échelle du web, le CLS est meilleur sur mobile que sur desktop. C'est l'inverse du LCP et de l'INP. Le Web Almanac 2025 fournit les chiffres, ainsi que la fréquence des causes listées ci-dessus :

• 81 % des sites mobiles et 72 % des sites desktop ont un bon CLS. Environ 9 % des sites mobiles et 10 % des sites desktop sont classés mauvais.
• 62 % des pages mobiles ont au moins une image sans dimensions explicites, contre 66 % en 2024.
• 40 % des pages mobiles (44 % sur desktop) comportent des animations non compositées.
• 87 % des pages mobiles utilisent au moins une police web, et environ 12 % en préchargent une (chapitre Fonts).

Guides associés

Ces guides permettent d'aller plus loin pour repérer et corriger le CLS :

• Identifier et corriger les problèmes de CLS : diagnostic étape par étape avec démonstrations d'outils, correctifs de code pour chaque cause et checklist rapide.
• Comment les images et les médias provoquent des décalages de mise en page : le CLS causé par les images, vidéos et iframes sans dimensions, la direction artistique, les images responsives, le lazy loading et les placeholders.
• Corriger les décalages de mise en page causés par les images auto-dimensionnées : définir les dimensions appropriées pour les images et les conteneurs responsives.
• Corriger les décalages de mise en page causés par les transitions CSS : repérer les animations CSS qui déclenchent le layout et les remplacer par des alternatives compositées.
• Animations déclenchées par le défilement et CLS : la cause de CLS qu'un test de chargement Lighthouse ne détecte pas, et comment la corriger.
• Auto-héberger Google Fonts : réduire le CLS lié au chargement des polices en les auto-hébergeant avec la bonne directive font-display et du préchargement.
• Garantir la visibilité du texte pendant le chargement des polices web : font-display et overrides de métriques de police pour éviter les décalages lors du swap.
• Créer un widget de chat avec des Core Web Vitals parfaits : étude de cas sur l'intégration d'un widget tiers sans régression sur le CLS, l'INP ou le LCP.

La vue d'ensemble des Core Web Vitals couvre les trois métriques, et la checklist Core Web Vitals vous aide à auditer votre site.