Des décalages de mise en page inattendus peuvent perturber l'expérience utilisateur de nombreuses façons. Par exemple, ils peuvent perdre leur place pendant la lecture si le texte se déplace brusquement ou les inciter à 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 façon dynamique à la page avant le contenu existant. Ces décalages peuvent être dus à des images ou des vidéos de dimensions inconnues, à des polices d'affichage plus grandes ou plus petites que la création de remplacement initiale, ou à des annonces ou widgets tiers qui se redimensionnent de façon dynamique.
Les différences de fonctionnement d'un site pendant son développement et celles de ses utilisateurs aggravent ce problème. Exemple :
- Les contenus personnalisés ou tiers se comportent 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 elles prennent plus de temps à charger 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 sur l'ensemble du cycle de vie d'une page.
Un changement de mise en page se produit chaque fois qu'un élément visible change de position d'une image affichée à l'autre. (Le calcul des scores de décalage de mise en page individuel est expliqué plus loin dans ce guide.)
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 et un maximum de cinq secondes pour la durée totale de la fenêtre.
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é, les sites doivent atteindre un score CLS de 0,1 ou moins. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, le 75e centile des chargements de pages est un bon seuil à mesurer, segmenté selon 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 d'instabilité de mise en page, 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 cadres. Ces éléments sont considérés comme des éléments instables.
Notez que 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 ne compte pas comme un décalage de mise en page, à condition que ce changement n'entraîne pas le changement de position d'autres éléments visibles.
Score de décalage de mise en page
Pour calculer le score de décalage de la mise en page, le navigateur tient compte de la taille de la fenêtre d'affichage et du mouvement des éléments instables dans la fenêtre d'affichage entre deux images affichées. 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 (définies ci-dessous).
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 sous la forme d'une fraction de la surface totale de la fenêtre d'affichage.
Dans l'image précédente, un élément occupe la moitié de la fenêtre d'affichage dans un cadre. Ensuite, 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é indique l'union de la zone visible de l'élément dans les deux cadres, ce qui correspond à 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 le déplacement des éléments instables par rapport à la fenêtre d'affichage. La fraction de distance correspond à la plus grande distance horizontale ou verticale qu'un élément instable a 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 l'exemple précédent, la plus grande dimension de la fenêtre d'affichage est 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 de 0, 25.
Ainsi, dans cet exemple, la fraction d'impact est 0.75 et la fraction de distance est 0.25. Le score de décalage de mise en page est donc 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 présent dans le DOM, donc sa position de départ ne change pas non plus.
En revanche, la position de départ du cadre vert change, mais comme elle a été partiellement déplacée en dehors de la fenêtre d'affichage, la zone invisible n'est pas prise en compte lors du calcul de la fraction d'impact. L'union des zones visibles du cadre vert dans les deux cadres (illustré par le rectangle rouge en pointillés) est identique à la surface du cadre vert du premier cadre, soit 50% de la fenêtre d'affichage. La fraction d'impact est de 0.5.
La fraction de distance est illustrée par la flèche violette. Le cadre vert a été déplacé vers le bas 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:
Dans la première image de l'image précédente, quatre résultats d'une requête API pour animaux s'affichent, triés par ordre alphabétique. Dans le deuxième frame, d'autres résultats sont ajoutés à la liste triée.
Le premier élément de la liste ("Cat") ne change pas sa position de départ entre les frames, il est donc stable. De même, les éléments ajoutés à la liste n'étaient pas dans le DOM. Leur position de départ ne change donc 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, les rectangles rouges en pointillés représentent l'union de ces trois éléments instables avant et après les zones, ce qui correspond dans ce cas à environ 60% de la surface de la fenêtre d'affichage (fraction d'impact 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% de la hauteur de la fenêtre d'affichage). La fraction de distance 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 attendait 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 décalage se produise suffisamment près de l'interaction pour que la relation soit clairement établie pour l'utilisateur.
Par exemple, si une interaction de l'utilisateur déclenche une requête réseau dont l'exécution 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, quelque chose qui pourrait sortir de sous lui.
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, et peuvent donc être exclus 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 bouge de façon brusque et inattendue sur la page nuit presque toujours à l'expérience utilisateur. Mais le contenu qui se déplace progressivement et naturellement d'une position à l'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 de navigateur prefers-reduced-motion, car certains visiteurs du site peuvent subir des effets néfastes ou des problèmes d'attention liés aux animations.
La propriété CSS transform vous permet d'animer des éléments sans déclencher de décalage de mise en page:
- Au lieu de modifier les propriétés
heightetwidth, utiliseztransform: scale(). - Pour déplacer des éléments, évitez de modifier les propriétés
top,right,bottomouleftet utilisez plutôttransform: translate().
Mesurer le CLS
Vous pouvez mesurer le CLS dans l'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, vous 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, vous devez regrouper ces entrées layout-shift inattendues dans des sessions, puis calculer la valeur maximale de la session. Vous pouvez vous reporter au code source de la bibliothèque JavaScript web vitals qui contient une implémentation de référence sur le calcul du CLS.
Dans la plupart des cas, la valeur CLS actuelle au moment du déchargement de la page correspond à la valeur CLS finale de cette page. Il existe toutefois quelques exceptions importantes, comme indiqué 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 en arrière-plan avant que le navigateur ne peigne son contenu, elle ne doit indiquer aucune valeur CLS.
- Si une page est restaurée à partir du cache amélioré, sa valeur CLS doit être réinitialisée, car les utilisateurs consultent cette page à part.
- L'API ne signale pas les entrées
layout-shiftpour les décalages qui se produisent dans les iFrames, contrairement à la métrique, car ils font partie de l'expérience utilisateur sur la page. Cela peut indiquer une différence entre CrUX et RUM. Pour mesurer correctement le CLS, vous devez les prendre en compte. Les sous-frames peuvent utiliser l'API pour signaler leurs entréeslayout-shiftau frame parent pour l'agrégation.
Outre ces exceptions, le CLS présente une complexité supplémentaire, car il mesure la durée de vie complète d'une page:
- Les utilisateurs peuvent garder un onglet ouvert très longtemps, par exemple des jours, des semaines, des 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 transmission de la valeur "finale".
Pour gérer ces cas de figure, le CLS doit être signalé chaque fois qu'une page s'exécute en arrière-plan, mais aussi 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.
Plutôt que de mémoriser et de s'attaquer à tous ces cas de figure, les développeurs peuvent utiliser la bibliothèque JavaScript web-vitals pour mesurer le CLS, qui tient compte de tous les éléments mentionnés ci-dessus, à 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 pour réduire le décalage de mise en page
- Understanding Cumulative Layout Shift (Comprendre le changement de mise en page cumulatif) par Annie Sullivan et Steve Kobes, #PerfMatters (2020)
Journal des modifications
Des bugs sont parfois découverts dans les API utilisées pour mesurer les métriques, et parfois dans les définitions des métriques elles-mêmes. Des modifications doivent donc 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, toutes les modifications apportées à l'implémentation ou à la définition de ces métriques seront affichées dans ce journal des modifications.
Si vous avez des commentaires sur ces métriques, vous pouvez les faire dans le groupe Google web-vitals-feedback.