Cumulative Layout Shift (CLS) : guide complet

En bref — Le Cumulative Layout Shift (CLS) mesure les déplacements spontanés du contenu pendant la lecture ou une interaction : une image tardive repousse le texte, un bouton saute au moment du clic. Le score commence à 0 et 0,1 ou moins est bon. La plupart des problèmes viennent d’éléments dont l’espace n’a pas été réservé avant leur chargement.

Qu’est-ce que le CLS ?

Vous avez déjà subi ce phénomène : une publicité ou une image finit de charger au-dessus du passage lu et toute la page descend. Vous visez « Annuler », une bannière apparaît et votre geste atteint « Confirmer ». Ce mouvement inattendu est un décalage de mise en page ; le CLS chiffre sa gravité.

Le CLS est l’un des trois Core Web Vitals, avec le Largest Contentful Paint, qui mesure le chargement du contenu principal, et l’Interaction to Next Paint, qui mesure la réactivité. Il évalue la stabilité visuelle : la page reste-t-elle en place ?

Fonctionnement approximatif du score

Le CLS est un score, pas une durée. Une valeur de 0,05 ne signifie pas 50 millisecondes : elle n’a pas d’unité. Plus la zone déplacée est grande et plus son déplacement est long, plus le score est mauvais.

Les seuils sont simples :

• 0,1 ou moins : bon.
• De 0,1 à 0,25 : amélioration nécessaire.
• Plus de 0,25 : mauvais.

Les déplacements qui suivent immédiatement votre action, comme l’ouverture d’un menu, ne pénalisent pas la page : vous les avez provoqués et les attendez. Seuls les mouvements inattendus comptent.

Causes et corrections

Presque tous les décalages ont la même origine : un élément chargé tardivement occupe un espace que la page n’avait pas réservé. Les principales causes sont :

• Images et vidéos sans dimensions. Le navigateur ignore leur hauteur avant réception ; définissez toujours width et height, ou un aspect-ratio CSS.
• Publicités, contenus intégrés et iframe. Réservez également leur espace.
• Polices Web. Le remplacement de la police de secours peut redistribuer le texte.
• Contenu inséré tardivement. Bannières de cookies, recommandations et autres éléments ajoutés au-dessus du contenu visible.

Règle mentale : si un élément doit apparaître plus tard, réservez-lui immédiatement un emplacement aux bonnes dimensions afin que rien ne bouge.

Pour la formule exacte, les fenêtres de session, les écarts entre laboratoire et terrain et la liste complète des corrections, ouvrez l’onglet Avancé.

En bref — Le CLS est le Core Web Vital de la stabilité visuelle. Chaque déplacement vaut impact fraction × distance fraction ; la métrique retient la plus grande fenêtre de session (au plus 1 s entre deux déplacements et 5 s au total), et non la somme sur toute la durée de la page comme avant juin 2021. Au 75e percentile des données de terrain, un score ≤ 0,1 est bon, jusqu’à 0,25 il faut l’améliorer, et au-delà il est mauvais. Seuls les mouvements visibles dans le viewport comptent ; ceux survenant dans les 500 ms après une interaction discrète sont exclus, contrairement au défilement. Les corrections consistent surtout à réserver l’espace, ajuster les polices et animer uniquement avec transform. Lighthouse peut afficher presque zéro parce qu’il ne reproduit ni les interactions ni toute la durée de vie ; Google utilise les données CrUX de terrain.

Ce que mesure le CLS

Google le définit ainsi : “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” (traduction) « Le Cumulative Layout Shift est une métrique Core Web Vital stable, centrée sur l’utilisateur, qui mesure la stabilité visuelle en quantifiant la fréquence des déplacements inattendus. » Le mot décisif est inattendu : le contenu bouge seul, sans action de l’utilisateur.

Il complète le Largest Contentful Paint pour le chargement et l’Interaction to Next Paint pour la réactivité. LCP et INP sont exprimés en millisecondes ; le CLS est un rapport sans unité. Un CLS de 0,05 ne représente donc pas 50 ms.

La formule : impact × distance

Pour chaque déplacement, Google définit :

layout shift score = impact fraction × distance fraction

• La fraction d’impact “measures how unstable elements impact the viewport area between two frames” (traduction) « mesure la surface du viewport affectée par les éléments instables entre deux images » : elle rapporte au viewport la zone visible combinée avant et après le mouvement.
• La fraction de distance correspond à “the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).” (traduction) « la plus grande distance horizontale ou verticale parcourue par un élément instable, divisée par la plus grande dimension du viewport. »

Les deux dimensions comptent séparément. Un petit objet traversant presque tout l’écran et un grand objet bougeant à peine peuvent obtenir des scores très différents. Dans l’exemple de web.dev, une fraction d’impact de 0.75 multipliée par une fraction de distance de 0.25 donne un score de 0.1875.

Fenêtres de session : la règle souvent mal comprise

Voici le point essentiel : le CLS n’est pas la somme de tous les déplacements pendant toute la durée de vie de la page. Cette ancienne définition a changé en juin 2021.

Aujourd’hui, “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traduction) « le CLS mesure la plus grande rafale de scores parmi tous les déplacements inattendus pendant toute la durée de vie de la page. » Une fenêtre de session regroupe “one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” (traduction) « un ou plusieurs déplacements rapprochés, espacés de moins d’une seconde, sur une durée totale maximale de cinq secondes. » Le CLS retient la plus grande fenêtre, ni la somme ni la moyenne.

L’ancienne somme pénalisait discrètement les pages longues. Une application monopage ou un fil infini accumulait du CLS simplement en restant ouvert, même avec de petits déplacements espacés. L’équipe Chrome a adopté la fenêtre maximale afin de ne plus pénaliser la durée et a préféré le maximum à la moyenne pour éviter qu’une petite correction secondaire augmente paradoxalement le score. Lors du déploiement, aucune origine n’a empiré, la plupart sont restées stables et certaines interfaces lentes ou infinies se sont améliorées. Les articles parlant encore de « somme de tous les déplacements » sont obsolètes.

Ce qui compte — et ce qui ne compte pas

Trois exclusions déterminent le score :

• Sous la ligne de flottaison, aucun effet. Seuls les mouvements du contenu visible dans le viewport actuel sont comptés. Priorisez donc ceux qui affectent l’écran.
• Une action utilisateur ouvre une fenêtre de 500 ms. “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” (traduction) « Les déplacements survenant dans les 500 millisecondes suivant une action utilisateur portent le drapeau hadRecentInput et peuvent être exclus. » Google juge acceptables les mouvements “that occur in response to user interactions… are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.” (traduction) « provoqués par une interaction, si leur proximité rend la relation évidente. »
• Le défilement n’est pas exempté. L’exclusion vise seulement les événements discrets : toucher, cliquer ou presser une touche. Les gestes continus, défilement et pincement, ne déclenchent pas cette fenêtre.

Seuils et origine du score

“To provide a good user experience, sites should strive to have a CLS score of 0.1 or less,” (traduction) « Pour offrir une bonne expérience, les sites devraient viser un CLS inférieur ou égal à 0,1, » mesuré au “the 75th percentile of page loads, segmented across mobile and desktop devices.” (traduction) « 75e percentile des chargements, séparément sur mobile et ordinateur. »

• Bon : ≤ 0,1
• Amélioration nécessaire : de 0,1 à 0,25
• Mauvais : > 0,25

Le seuil de 0,1 n’est pas arbitraire. Les études de Google ont constaté que “levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive.” (traduction) « les déplacements de 0,15 ou plus étaient systématiquement perçus comme gênants, tandis que ceux de 0,1 ou moins restaient perceptibles sans être excessivement perturbants. » Un seuil plus strict aurait aussi été peu réaliste face aux intégrations tierces.

La mention du 75e percentile des données de terrain est essentielle et mène au principal piège de mesure.

Laboratoire et terrain : pourquoi les chiffres divergent

Lighthouse et les autres outils de laboratoire affichent souvent un CLS proche de 0 alors que les données de terrain sont bien pires. Ce n’est pas une tromperie, mais une différence de portée. Un test court et scénarisé ne défile pas, ne clique pas et ne reste pas longtemps ; il ne voit que les déplacements du chargement initial. CrUX agrège de vraies visites sur de nombreux appareils et toute la durée de vie de la page : menus, contenus différés et publicités tardives. Un test bref ne peut structurellement pas tout observer.

Règle pratique : utilisez le laboratoire pour diagnostiquer un déplacement et le terrain pour connaître le vrai score. Google s’appuie sur CrUX, visible dans PageSpeed Insights et Search Console. Si Lighthouse indique 0 mais PSI 0,18, reproduisez en laboratoire le parcours réel qui déclenche le mouvement. Autres angles morts : les outils de laboratoire ne propagent généralement pas les déplacements d’iframe au document parent, et le RUM fondé sur l’API Layout Instability partage cette limite.

Causes fréquentes

Dans l’ordre approximatif où je les rencontre :

1. Images et vidéos sans dimensions. Aucun espace n’est réservé avant leur arrivée.
2. Publicités, intégrations et iframe sans emplacement stable. Leurs dimensions sont souvent dynamiques.
3. Contenu injecté au-dessus du contenu existant. Bannières, notifications, recommandations et promotions repoussent ce qui est déjà visible.
4. Polices Web (FOIT/FOUT). Des métriques différentes redistribuent le texte au remplacement.
5. Animations de propriétés de mise en page. Animer top, left, margin, box-shadow ou box-sizing force une nouvelle mise en page à chaque image.

Corrections

Chaque correction répond à sa cause :

• Images et vidéos : réservez l’espace. Définissez width et height, conservez img { height: auto; width: 100%; } pour le responsive, ou utilisez aspect-ratio.
• Publicités, iframe et intégrations : même principe. Utilisez min-height ou aspect-ratio. Google recommande : “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” (traduction) « Définir directement une hauteur et une largeur fixes sur le div publicitaire est la méthode la plus efficace. » Pour plusieurs formats, réservez le plus grand.
• Contenu dynamique : ne l’insérez pas dans le flux. Réservez un emplacement aux dimensions finales ou superposez-le. Un squelette n’aide que s’il correspond exactement.
• Polices : faites correspondre les métriques. La propriété font-display, notamment avec la valeur font-display: optional, limite le risque ; avec swap, employez size-adjust, ascent-override, descent-override et line-gap-override, puis préchargez les polices critiques.
• Animations : uniquement transform. Les transformations compositées ne déclenchent pas de nouvelle mise en page.

Place du CLS dans le classement — gardez les proportions

Le CLS contribue au signal d’expérience sur la page. Google indique que ses systèmes utilisent les Core Web Vitals, sans publier de poids précis, de règle de départage ni de garantie. Traitez toute mécanique spécifique comme une approximation. Mon conseil : atteignez la zone « bonne », puis passez à autre chose. Réduire 0,08 à 0,02 produit rarement à lui seul un gain de classement ou de chiffre d’affaires. Le CLS est un prérequis, pas le centre d’une stratégie SEO au détriment de LCP, INP ou du contenu.

Deux remarques opérationnelles évitent beaucoup de confusion :

• CrUX couvre une fenêtre glissante d’environ 28 jours. Une correction ne se reflète complètement dans PSI ou Search Console qu’après plusieurs semaines.
• L’élément attribué n’est souvent pas la cause racine. L’API indique l’élément déplacé, mais web.dev précise : “it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” (traduction) « ces éléments peuvent n’être qu’indirectement liés à la cause racine de l’instabilité. » Le texte déplacé peut être victime d’une image sans dimensions située au-dessus. Notez l’horodatage, puis cherchez dans la même fenêtre une requête terminée, une image ou police arrivée, un redimensionnement ou un changement de classe.

Résumé par IA

Version condensée de l’onglet Avancé :

• CLS mesure la stabilité visuelle et les mouvements inattendus du contenu visible.
• C’est un rapport sans unité, pas une durée. 0,05 ne signifie pas 50 ms.
• Formule par déplacement : impact fraction × distance fraction.
• La métrique retient la plus grande fenêtre de session : au plus 1 s entre mouvements et 5 s au total, pas la somme sur toute la vie de la page.
• Seuils au 75e percentile : bon ≤ 0,1 ; amélioration nécessaire ≤ 0,25 ; mauvais > 0,25.
• Exclusions : les mouvements hors viewport et ceux suivant une interaction discrète sous 500 ms ; le défilement reste compté.
• Causes : médias, publicités et iframe sans dimensions, contenu injecté, polices et animations de mise en page.
• Corrections : réserver l’espace, faire correspondre les polices et animer avec transform. Les jetons utiles sont width, height, aspect-ratio, font-display et size-adjust.
• Laboratoire ≠ terrain. Lighthouse manque souvent les interactions tardives ; CrUX reflète les utilisateurs réels.
• Classement : Google utilise les CWV sans publier de poids précis. Atteignez la zone bonne sans surinvestir.

Documentation officielle

Documentation de première main publiée par Google et l’équipe Chrome.

Documentation CLS principale

• Cumulative Layout Shift — définition, formule, fenêtres, seuils et exclusion hadRecentInput.
• Optimiser le CLS — causes et corrections officielles.
• Déboguer les déplacements — DevTools, régions et API d’attribution.

Contexte et mesure

• Évolution du CLS dans les outils Web — passage à la plus grande fenêtre en juin 2021.
• Définition des seuils Core Web Vitals — études utilisateur derrière 0,1 et 0,25.
• Mesurer les Web Vitals — terrain, laboratoire et scores artificiellement bas.
• Bonnes pratiques pour les polices — font-display, ajustements et préchargement.

Publicités et Search

• Réduire les déplacements — réservation des emplacements publicitaires.
• Core Web Vitals et résultats Google Search — rôle des CWV dans Search.

Citations de la source

Déclarations officielles de Google et de l’équipe Chrome. Chaque lien mène au passage cité.

Google — définition du CLS

• “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” (traduction) « Le CLS est une métrique stable centrée sur l’utilisateur qui quantifie la fréquence des déplacements inattendus. » Accéder à la citation
• “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traduction) « Le CLS mesure la plus grande rafale de scores de déplacements inattendus pendant toute la vie d’une page. » Accéder à la citation

Google — formule

• “layout shift score = impact fraction * distance fraction” (traduction) « score de déplacement = fraction d’impact × fraction de distance ». Accéder à la citation
• “The impact fraction measures how unstable elements impact the viewport area between two frames.” (traduction) « La fraction d’impact mesure la zone du viewport affectée entre deux images. » Accéder à la citation
• “The distance fraction is the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).” (traduction) « La fraction de distance divise le plus grand déplacement par la plus grande dimension du viewport. » Accéder à la citation

Google — fenêtre de session

• “A burst of layout shifts, known as a session window, is when one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” (traduction) « Une fenêtre de session regroupe des déplacements rapprochés espacés de moins d’une seconde, pendant cinq secondes au maximum. » Accéder à la citation

Google — seuils et action utilisateur

• “To provide a good user experience, sites should strive to have a CLS score of 0.1 or less… a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (traduction) « Pour une bonne expérience, visez un CLS inférieur ou égal à 0,1 au 75e percentile, séparément sur mobile et ordinateur. » Accéder à la citation
• “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” (traduction) « Les déplacements survenant dans les 500 ms suivant une action portent hadRecentInput et peuvent être exclus. » Accéder à la citation
• “Layout shifts that occur in response to user interactions (such as clicking or tapping a link, pressing a button, or typing in a search box) are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.” (traduction) « Les déplacements répondant à une interaction sont acceptables si leur lien avec elle est clair. » Accéder à la citation

Google — choix des seuils

• “levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive.” (traduction) « Les déplacements à partir de 0,15 étaient perçus comme gênants ; à 0,1 ou moins, ils restaient perceptibles sans être excessifs. » Accéder à la citation

Google — réserver un emplacement publicitaire

• “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” (traduction) « Définir directement une hauteur et une largeur fixes sur le div publicitaire est la méthode la plus efficace. » Accéder à la citation

Google — élément attribué et cause racine

• “elements listed as sources are the elements that shifted during the layout shift. However, it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” (traduction) « Les éléments listés sont ceux qui ont bougé, mais ils peuvent n’être liés qu’indirectement à la cause racine. » Accéder à la citation

Liste de contrôle : causes et corrections CLS

Procédez de haut en bas ; les deux premiers points corrigent la majorité des cas réels.

• Chaque <img> et <video> possède width et height, ou un aspect-ratio, avec une règle responsive adaptée.
• La règle responsive conserve img { height: auto; width: 100%; } lorsque ce comportement convient.
• Publicités, iframe et intégrations réservent leur espace avec min-height ou aspect-ratio.
• Le contenu tardif se trouve sous la ligne de flottaison si possible.
• Les bannières et widgets sont superposés ou pré-réservés, pas insérés au-dessus.
• Les squelettes correspondent exactement aux dimensions finales.
• Les polices utilisent font-display: optional, ou swap avec size-adjust et ascent-override ; les polices critiques sont préchargées.
• Les animations utilisent uniquement transform, jamais top, left, margin, box-shadow ou box-sizing.
• Le score a été contrôlé dans les données de terrain, pas seulement Lighthouse.
• Les interactions et chargements différés ont été reproduits.
• Les mouvements d’iframe ont été vérifiés sur le terrain.

Aide-mémoire CLS

Les seuils

Définition en une ligne

• layout shift score = impact fraction × distance fraction.
• CLS = plus grande fenêtre de session : ≤ 1 s entre mouvements, ≤ 5 s au total. Ce n’est plus la somme sur toute la durée depuis juin 2021.
• C’est un score sans unité, pas une durée.

Éléments exclus

• Mouvements hors du viewport actuel.
• Mouvements dans les 500 ms après une action discrète, avec hadRecentInput.
• Ne sont pas exclus : défilement et pincement, qui sont des gestes continus.

Causes → corrections

Pièges de mesure

• Lighthouse affiche souvent environ 0, car il ne reproduit pas tout le cycle ; Google utilise CrUX.
• CrUX accuse environ 28 jours de retard.
• Les mouvements d’iframe remontent rarement au score parent dans les outils de laboratoire.
• L’élément attribué est celui qui bouge, pas nécessairement la cause.

Outils de mesure et de diagnostic du CLS

Données de terrain

• PageSpeed Insights : CLS CrUX pour la page et l’origine, avec Lighthouse en parallèle.
• Search Console — rapport Core Web Vitals : CLS de terrain par groupes d’URL et par état.
• CrUX : jeu de données sous-jacent, avec historique dans CrUX Vis ou BigQuery.

Données de laboratoire

• Chrome DevTools — Performance : enregistrez une trace et consultez la piste Layout Shifts ; Live Metrics actualise le CLS pendant les interactions.
• Surbrillance des régions déplacées : DevTools → Rendering → Layout Shift Regions.
• Lighthouse : contrôle rapide du chargement initial.
• WebPageTest : CLS avec film fixe et trace.

RUM — vos propres données de terrain

• Bibliothèque JavaScript web-vitals : onCLS() rapporte le CLS des visiteurs réels.
• PerformanceObserver avec layout-shift : API brute et tableau sources des éléments déplacés.

Comment les outils se classent eux-mêmes

Exemple concret : services de vitesse et de suivi connus classés selon leur CLS mobile réel issu du Chrome UX Report.

Quelle correction CLS appliquer en premier ?

Erreurs CLS qui masquent le vrai problème

Prendre un bon test Lighthouse pour une preuve

Lighthouse peut se terminer avant une bannière, une publicité ou un mouvement déclenché par interaction. Utilisez-le pour diagnostiquer, puis confirmez dans CrUX ou votre RUM avant de conclure.

Corriger uniquement l’élément déplacé indiqué par DevTools

L’élément déplacé est souvent la victime. Un contenu tardif situé au-dessus peut être la cause. Rejouez la trace et examinez ce qui est apparu ou redimensionné juste avant.

Réserver une hauteur fixe approximative

Un emplacement approximatif peut provoquer un second mouvement si le contenu responsive est plus haut ou plus bas. Utilisez les dimensions intrinsèques ou aspect-ratio lorsque les proportions sont connues.

Animer des propriétés de mise en page

Modifier top, left ou les marges peut déplacer le contenu voisin. Utilisez transform si l’effet ne doit pas modifier le flux du document.

Diagnostiquer un problème CLS par symptôme

Le CLS de terrain est mauvais mais le laboratoire est proche de zéro

Cause probable : mouvement après interaction, pendant une session longue ou pour certains utilisateurs. Correction : reproduisez le parcours réel en enregistrant Performance, puis ajoutez l’attribution web-vitals au RUM. Confirmation : l’interaction et l’élément apparaissent dans la trace ou le relevé RUM.

Le texte saute à l’arrivée de la police personnalisée

Cause probable : les métriques de la police de secours diffèrent. Correction : préchargez seulement la police critique et ajustez les métriques de secours. Confirmation : cache désactivé, la piste Layout Shifts n’enregistre plus le remplacement.

Une bannière ou publicité pousse la page

Cause probable : l’emplacement n’a pas de dimensions réservées. Correction : allouez un conteneur stable ou placez le message hors du contenu visible. Confirmation : sous réseau ralenti, l’empreinte reste identique.

Le CLS s’améliore en test, pas dans PageSpeed Insights

Cause probable : CrUX utilise une fenêtre glissante. Correction : validez d’abord en laboratoire et dans le RUM, puis attendez le renouvellement du terrain. Confirmation : votre distribution après publication progresse avant l’agrégat public.

Capturer les déplacements dans le navigateur

Collez ce script dans la console DevTools avant de reproduire le problème. Il ignore les mouvements liés à une action récente et affiche le score ainsi que les éléments attribués.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.hadRecentInput) continue;
    console.table({
      value: entry.value,
      time: Math.round(entry.startTime),
      elements: entry.sources?.map((source) => source.node),
    });
  }
});

observer.observe({ type: 'layout-shift', buffered: true });

Le nœud attribué est une piste, pas une preuve. Comparez son horodatage aux requêtes réseau, chargements de polices et insertions DOM de la même trace.

Prouver qu’une correction CLS fonctionne

Test de réservation d’espace

Test : désactivez le cache, ralentissez la connexion, rechargez et enregistrez Layout Shifts. Résultat attendu : le média conserve la même empreinte avant et après chargement. Échec : le conteneur dépend encore du contenu tardif. Fenêtre : immédiate dans la trace. Annulation : l’emplacement crée un rognage, un vide excessif ou un nouveau mouvement responsive.

Test de remplacement de police

Test : rechargez sans cache en surveillant le texte et Layout Shifts. Résultat attendu : aucun mouvement mesurable. Échec : les métriques divergent encore ou la police arrive trop tard. Fenêtre : immédiate sur plusieurs tests. Annulation : le texte reste caché plus longtemps ou la typographie finale se dégrade.

Confirmation sur le terrain

Test : comparez les données onCLS() après publication à la base précédente, puis observez CrUX. Résultat attendu : meilleur p75 sans aggravation de la traîne. Échec : une autre source tardive subsiste. Fenêtre : dès l’arrivée du trafic pour le RUM ; 28 jours pour CrUX. Annulation : CLS ou erreurs d’interaction empirent durablement.

Métriques CLS à suivre

CLS des utilisateurs réels au p75

Métrique : CLS au 75e percentile par modèle et appareil. Enseignement : respect de la stabilité pour la majorité des visites. Collecte : CrUX, PSI ou RUM web-vitals. Repère : bon ≤ 0,1 ; amélioration nécessaire jusqu’à 0,25 ; mauvais au-delà. Cadence : déploiements dans le RUM et tendance mensuelle.

Taux de visites mauvaises

Métrique : part des visites réelles avec CLS > 0,25. Enseignement : une traîne dommageable peut se cacher derrière un p75 acceptable. Collecte : regroupez les événements onCLS() par modèle et parcours. Repère : établissez une base propre au site et réduisez la catégorie mauvaise. Cadence : hebdomadaire et après les changements.

Attribution des déplacements par cause

Métrique : entrées layout-shift regroupées par élément ou composant. Enseignement : implémentations responsables de l’instabilité récurrente. Collecte : version avec attribution de web-vitals ou PerformanceObserver. Repère : comparez impact total et visites touchées. Cadence : à chaque publication de modèle ou composant.

Ressources utiles

Documentation officielle approfondie

• Cumulative Layout Shift — référence canonique.
• Optimiser le CLS — guide officiel des corrections.
• Déboguer les déplacements — méthode DevTools.
• Évolution du CLS — changement de fenêtre en juin 2021.

Sources pratiques

• Corriger les problèmes CLS — Barry Pollard, sur les polices et la cause racine.
• Le CLS en pratique — nuances de mesure, iframe et attribution.
• Mesurer et optimiser le CLS — DebugBear.
• Guide presque complet du CLS — cas limites des SPA et gestes continus.
• Coupables des déplacements — panneau de diagnostic Chrome.
• Corriger le CLS — méthode pratique pour CMS.
• Layout Instability API — spécification sous-jacente, notamment pour hadRecentInput.

Dans mon travail Le CLS est un prérequis de mes analyses Core Web Vitals : mesurez-le, atteignez la zone bonne et gardez-le en proportion face à LCP, INP et au contenu. Google ne publie ni poids précis ni règle de départage.

Statistiques à citer

• Le seuil de 0,1 repose sur des études de perception. À partir de 0,15, les mouvements étaient systématiquement gênants ; à 0,1 ou moins, perceptibles sans excès. Source
• Le CLS est le Core Web Vital le plus facile à valider. Dans mes audits d’entreprise, une grande majorité des sites dépasse le seuil, souvent autour de 80 %, alors qu’un peu plus de la moitié valide les trois métriques.
• Le changement de juin 2021 a aidé sans nuire. Aucune origine n’a empiré ; certaines pages infinies ou lentes se sont améliorées. Source
• Les médias sans dimensions restent répandus. Ils constituent une cause fréquente et simple à corriger.
• 72 % des sites obtiennent un bon CLS, selon les données 2025 du Web Almanac, tandis que 62 % des pages mobiles livrent encore une image sans dimensions explicites. Source
• Impact commercial : Rakuten 24 a rapporté 53,37 % de revenu par visiteur supplémentaire chez les utilisateurs au CLS faible plutôt qu’élevé. C’est une étude de cas, pas une preuve causale universelle. Source

Vidéos

• Chaîne vidéo de l’équipe Chrome (YouTube) — présentations des Core Web Vitals et démonstrations des pistes et régions Layout Shifts. Chaîne

Testez vos connaissances : Cumulative Layout Shift

Cinq questions rapides sur la mesure et la correction de l’instabilité visuelle. Choisissez une réponse, puis vérifiez-la.

Journal des modifications