Le CLS (Cumulative Layout Shift) est une métrique Core Web Vitals stable. Il s'agit d'une métrique importante centrée sur l'utilisateur pour mesurer la stabilité visuelle, car elle permet de quantifier la fréquence à laquelle les utilisateurs subissent des décalages de mise en page inattendus. Un CLS faible permet de s'assurer que la page est agréable.
Des décalages de mise en page inattendus peuvent perturber l'expérience utilisateur de nombreuses manières, par exemple en les faisant perdre leur place lors de la lecture si le texte se déplace soudainement, ou en les incitant à cliquer sur le mauvais lien ou le mauvais bouton. Dans certains cas, cela peut causer de sérieux dommages.
Un déplacement inattendu du contenu de la page se produit généralement lorsque les ressources se chargent de manière asynchrone ou lorsque des éléments DOM sont ajoutés de manière dynamique à la page avant le contenu existant. Le mouvement peut être dû à une image ou une vidéo dont les dimensions sont inconnues, à une police plus grande ou plus petite que la création de remplacement, ou à une annonce ou un widget tiers qui se redimensionnent de manière dynamique.
Les différences entre le fonctionnement d'un site pendant le développement et l'expérience de ses utilisateurs aggravent ce problème. Exemple :
- Le contenu personnalisé ou tiers se comporte souvent différemment lors du développement et de la production.
- Les images de test se trouvent souvent déjà dans le cache du navigateur du développeur, mais leur chargement prend plus de temps pour l'utilisateur final.
- Les appels d'API exécutés localement sont souvent si rapides que des retards de développement invisibles peuvent devenir importants en production.
La métrique CLS (Cumulative Layout Shift) vous aide à résoudre ce problème en mesurant la fréquence à laquelle il se produit pour les utilisateurs réels.
Qu'est-ce que le CLS ?
Le CLS mesure la plus grande rafale de scores de décalage de mise en page pour chaque décalage de mise en page inattendu qui se produit pendant la durée de vie d'une page.
Un changement de mise en page se produit chaque fois qu'un élément visible change de position d'un frame affiché à l'autre. Consultez la section Score de décalage de mise en page pour en savoir plus sur la mesure de ces décalages.
Une rafale de décalages de mise en page, appelée fenêtre de session, se produit lorsqu'un ou plusieurs décalages de mise en page individuels se produisent en succession rapide, avec moins d'une seconde entre chaque décalage, pendant une période maximale de cinq secondes.
La plus grande rafale correspond à la fenêtre de session avec le score cumulé maximal de tous les décalages de mise en page au sein de cette fenêtre.
Qu'est-ce qu'un bon score CLS ?
Pour offrir une expérience utilisateur de qualité, le site doit présenter un score CLS de 0.1 ou moins. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, nous vous recommandons de mesurer le 75e centile des chargements de page, segmenté sur les appareils mobiles et les ordinateurs.
Pour en savoir plus sur la recherche et la méthodologie qui sous-tendent cette recommandation, consultez Définir les seuils des métriques Core Web Vitals.
Décalages de mise en page en détail
Les décalages de mise en page sont définis par l'API Layout Instability, qui signale les entrées layout-shift chaque fois qu'un élément visible dans la fenêtre d'affichage change de position de départ (par exemple, sa position supérieure et sa position gauche dans le mode d'écriture par défaut) entre deux frames. Les éléments dont la position de départ change sont considérés comme des éléments instables.
Les décalages de mise en page ne se produisent que lorsque des éléments existants changent de position de départ. Si un nouvel élément est ajouté au DOM ou qu'un élément existant change de taille, cela n'est considéré comme un décalage de mise en page que si cette modification entraîne un changement de position de départ d'autres éléments visibles.
Score de décalage de mise en page
Pour calculer le score de décalage de mise en page, le navigateur prend en compte la taille de la fenêtre d'affichage et le mouvement des éléments instables dans la fenêtre d'affichage entre deux cadres affichés. Le score de décalage de mise en page est le produit de deux mesures de ce mouvement : la fraction d'impact et la fraction de distance.
layout shift score = impact fraction * distance fraction
Fraction d'impact
La fraction d'impact mesure l'impact des éléments instables sur la zone de la fenêtre d'affichage entre deux images.
La fraction d'impact d'une image donnée est une combinaison des zones visibles de tous les éléments instables de cette image et de l'image précédente, exprimée en fraction de la surface totale de la fenêtre d'affichage.
Cette image montre un élément qui occupe la moitié de la fenêtre d'affichage dans un seul cadre. Dans l'image suivante, l'élément se déplace de 25% vers le bas par rapport à la hauteur de la fenêtre d'affichage. Le rectangle rouge en pointillés indique la zone visible de l'élément sur les deux cadres, ce qui, dans ce cas, représente 75% de la fenêtre d'affichage totale. Sa fraction d'impact est donc de 0.75.
Fraction de distance
L'autre partie de l'équation du score de décalage de mise en page mesure la distance entre les éléments instables se sont déplacés par rapport à la fenêtre d'affichage. La fraction de distance correspond à la plus grande distance horizontale ou verticale qu'un élément instable s'est déplacé dans l'image, divisée par la plus grande dimension de la fenêtre d'affichage (largeur ou hauteur, selon la valeur la plus élevée).
Dans cet exemple, la plus grande dimension de la fenêtre d'affichage correspond à la hauteur, et l'élément instable s'est déplacé de 25% par rapport à la hauteur de la fenêtre d'affichage. La fraction de distance est donc 0.25.
Une fraction d'impact de 0.75 et une fraction de distance de 0.25 génèrent un score de décalage de mise en page de 0.75 * 0.25 = 0.1875.
Exemples
L'exemple suivant montre comment l'ajout de contenu à un élément existant affecte le score de décalage de mise en page:
Dans cet exemple, la zone grise change de taille, mais sa position de départ ne change pas. Il ne s'agit donc pas d'un élément instable.
Le bouton "Cliquez ici !" n'était pas dans le DOM auparavant. Par conséquent, sa position de départ ne change pas non plus.
La position de départ du cadre vert change, mais a été partiellement déplacée en dehors de la fenêtre d'affichage. La zone invisible n'est donc pas prise en compte lors du calcul de la fraction d'impact. L'union des zones visibles du cadre vert dans les deux cadres (rectangle rouge en pointillé) est identique à celle du rectangle vert du premier cadre, soit 50% de la fenêtre d'affichage. La fraction d'impact est de 0.5.
La fraction de la distance est illustrée par la flèche bleue. Le cadre vert est descendu d'environ 14% de la fenêtre d'affichage. La fraction de distance est donc de 0.14.
Le score de décalage de mise en page est de 0.5 x 0.14 = 0.07.
L'exemple suivant montre comment plusieurs éléments instables affectent le score de décalage de mise en page d'une page:
Le premier élément de la liste ("Cat") ne modifie pas sa position de départ entre les images. Il est donc stable. Les nouveaux éléments ajoutés à la liste n'étaient pas dans le DOM. Par conséquent, leur position de départ ne change pas non plus. Toutefois, les éléments portant les libellés "Chien", "Cheval" et "Zèbre" changent de position de départ, ce qui les rend instables.
Là encore, le rectangle rouge en pointillés représente la zone de ces trois éléments instables avant et après le décalage, ce qui correspond dans ce cas à environ 60% de la zone de la fenêtre d'affichage (fraction de 0.60).
Les flèches représentent les distances entre les éléments instables et leur position de départ. L'élément "Zebra", représenté par la flèche bleue, s'est le plus déplacé d'environ 30% par rapport à la hauteur de la fenêtre d'affichage. La fraction de distance utilisée dans cet exemple est donc 0.3.
Le score de décalage de mise en page est de 0.60 x 0.3 = 0.18.
Décalages de mise en page attendus et inattendus
Tous les décalages de mise en page ne sont pas nécessairement incorrects. En fait, de nombreuses applications Web dynamiques modifient fréquemment la position de départ des éléments sur la page. Un décalage de mise en page n'est mauvais que si l'utilisateur ne s'y attend pas.
Décalages de mise en page déclenchés par l'utilisateur
Les décalages de mise en page qui se produisent en réponse aux interactions de l'utilisateur (par exemple, cliquer ou appuyer sur un lien, appuyer sur un bouton ou saisir dans un champ de recherche) sont généralement acceptables, à condition que ce changement se produise suffisamment près de l'interaction pour que la relation soit claire pour l'utilisateur.
Par exemple, si une interaction utilisateur déclenche une requête réseau qui peut prendre un certain temps, il est préférable de créer un espace immédiatement et d'afficher un indicateur de chargement pour éviter un décalage de mise en page désagréable à l'issue de la requête. Si l'utilisateur ne se rend pas compte que quelque chose est en cours de chargement ou qu'il n'a pas de idée du moment où la ressource sera prête, il peut essayer de cliquer sur autre chose en attendant. Cet autre élément peut sortir de son emplacement une fois le chargement du premier terminé.
L'option hadRecentInput est définie pour les décalages de mise en page qui se produisent dans les 500 millisecondes suivant l'entrée utilisateur. Vous pouvez donc les exclure des calculs.
Animations et transitions
Les animations et les transitions, lorsqu'elles sont bien faites, sont un excellent moyen de mettre à jour le contenu de la page sans surprendre l'utilisateur. Un contenu qui change brusquement et de manière inattendue sur la page nuit presque toujours à l'expérience utilisateur. Toutefois, le contenu qui se déplace progressivement et naturellement d'une position à une autre peut souvent aider l'utilisateur à mieux comprendre ce qui se passe et le guider entre les changements d'état.
Assurez-vous de respecter les paramètres du navigateur prefers-reduced-motion, car les animations peuvent entraîner des problèmes de santé ou d'attention pour certains visiteurs du site.
La propriété CSS transform vous permet d'animer des éléments sans déclencher de décalages de mise en page:
- Utilisez
transform: scale()au lieu de modifier les propriétésheightetwidth. - Pour déplacer des éléments, utilisez
transform: translate()au lieu de modifier les propriétéstop,right,bottomouleft.
Mesurer le CLS
Vous pouvez mesurer le CLS en atelier ou sur le terrain. Il est disponible dans les outils suivants.
Outils de terrain
- Rapport sur l'expérience utilisateur Chrome
- PageSpeed Insights
- Search Console (rapport Core Web Vitals)
- Bibliothèque JavaScript
web-vitals
Outils de l'atelier
Mesurer les décalages de mise en page en JavaScript
Pour mesurer les décalages de mise en page en JavaScript, utilisez l'API Layout Instability.
L'exemple suivant montre comment créer un PerformanceObserver pour consigner les entrées layout-shift dans la console:
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('Layout shift:', entry);
}
}).observe({type: 'layout-shift', buffered: true});
Mesurer le CLS en JavaScript
Pour mesurer le CLS en JavaScript, regroupez les entrées layout-shift inattendues que vous avez connectées aux sessions et calculez la valeur maximale de la session. Pour une implémentation de référence, reportez-vous au code source de la bibliothèque JavaScript web vitals.
Dans la plupart des cas, la valeur CLS au moment du déchargement de la page correspond à la valeur CLS finale de cette page, mais il existe quelques exceptions importantes, énumérées dans la section suivante. La bibliothèque JavaScript web vitals en tient compte autant que possible, dans les limites des API Web.
Différences entre la métrique et l'API
- Si une page est chargée en arrière-plan ou si elle est mise en arrière-plan avant que le navigateur n'affiche de contenu, aucune valeur CLS ne doit être signalée.
- Si une page est restaurée à partir du cache amélioré, sa valeur CLS doit être réinitialisée, car il s'agit d'une visite distincte de la page.
- L'API ne signale pas les entrées
layout-shiftpour les décalages qui se produisent dans les cadres iFrame, mais la métrique le fait parce qu'ils font partie de l'expérience utilisateur sur la page. Cela peut montrer comme une différence entre CrUX et RUM. Pour mesurer correctement le CLS, vous devez inclure des iFrames. Les sous-frames peuvent utiliser l'API pour signaler leurs entréeslayout-shiftau frame parent à des fins d'agrégation.
En plus de ces exceptions, le CLS est encore plus complexe, car il mesure la durée de vie complète d'une page:
- Les utilisateurs peuvent garder un onglet ouvert pendant très longtemps, de jours, de semaines, voire de mois. En fait, un utilisateur peut ne jamais fermer un onglet.
- Sur les systèmes d'exploitation mobiles, les navigateurs n'exécutent généralement pas de rappels de déchargement de page pour les onglets en arrière-plan, ce qui rend difficile la création de rapports sur la valeur "finale".
Pour gérer de tels cas, nous recommandons que votre système signale le CLS chaque fois qu'une page est mise en arrière-plan, ainsi que chaque fois qu'elle est déchargée. L'événement visibilitychange couvre ces deux scénarios. Les systèmes d'analyse recevant ces données devront ensuite calculer la valeur CLS finale sur le backend.
Au lieu de mémoriser et de gérer vous-même tous ces cas de figure, les développeurs peuvent utiliser la bibliothèque JavaScript web-vitals pour mesurer le CLS, qui tient compte de tout ce qui est mentionné ici, à l'exception du cas des cadres iFrame:
import {onCLS} from 'web-vitals';
// Measure and log CLS in all situations
// where it needs to be reported.
onCLS(console.log);
Améliorer le CLS
Pour en savoir plus sur l'identification des décalages de mise en page sur le terrain et sur l'utilisation des données de test pour les optimiser, consultez notre guide sur l'optimisation du CLS.
Ressources supplémentaires
- Conseils de Google Publisher Tag sur la réduction du décalage de mise en page
- Understanding Cumulative Layout Shift (Comprendre le changement de mise en page cumulatif) par Annie Sullivan et Steve Kobes chez #PerfMatters (2020)
Journal des modifications
Il arrive que des bugs soient détectés dans les API utilisées pour mesurer les métriques, et parfois dans les définitions des métriques elles-mêmes. Par conséquent, des modifications doivent parfois être apportées, et ces modifications peuvent se présenter comme des améliorations ou des régressions dans vos rapports et tableaux de bord internes.
Pour vous aider à gérer cette situation, toutes les modifications apportées à l'implémentation ou à la définition de ces métriques sont présentées dans ce journal des modifications.
Si vous avez des commentaires sur ces métriques, envoyez-les dans le groupe Google web-vitals-feedback.