Optimiser le Cumulative Layout Shift

Découvrez comment éviter les changements de mise en page soudains pour améliorer l'expérience utilisateur.

Le Cumulative Layout Shift (CLS) est l'une des trois métriques Core Web Vitals. Il mesure l'instabilité du contenu en combinant la quantité de contenu visible qui a été décalée dans la fenêtre d'affichage et la distance parcourue par les éléments concernés.

Les décalages de mise en page peuvent distraire les utilisateurs. Imaginez que vous commenciez à lire un article et que soudainement, des éléments se déplacent sur la page, ce qui vous déstabilise et vous oblige à retrouver votre place. Ce problème est très courant sur le Web, par exemple lorsque vous lisez les actualités ou essayez de cliquer sur les boutons "Rechercher" ou "Ajouter au panier". Ces expériences sont visuellement choquantes et frustrantes. Elles surviennent souvent lorsque des éléments visibles sont déplacés de force, car un autre élément a été ajouté à la page ou redimensionné de manière soudaine.

Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer d'obtenir un CLS de 0,1 ou moins pour au moins 75% des visites de page.

Contrairement aux autres métriques Core Web Vitals, qui sont des valeurs basées sur le temps mesurées en secondes ou en millisecondes, le score CLS est une valeur sans unité basée sur un calcul de la quantité de contenu qui se déplace et de la distance parcourue.

Dans ce guide, nous allons vous expliquer comment optimiser les causes courantes de décalages de mise en page.

Voici les causes les plus courantes d'un CLS faible:

• Images sans dimensions.
• Annonces, éléments intégrés et iFrames sans dimensions
• Contenu injecté dynamiquement, comme des annonces, des éléments intégrés et des iFrames, sans dimensions
• Polices Web

Comprendre les causes des décalages de mise en page

Avant de chercher des solutions aux problèmes de CLS courants, il est important de comprendre votre score CLS et d'identifier l'origine des variations.

CLS dans les outils de laboratoire par rapport au terrain

Il est courant d'entendre des développeurs penser que le CLS mesuré par le rapport sur l'expérience utilisateur Chrome (CrUX) est incorrect, car il ne correspond pas au CLS qu'ils mesurent à l'aide de Chrome DevTools ou d'autres outils de laboratoire. Les outils de laboratoire de performances Web tels que Lighthouse peuvent ne pas afficher la valeur CLS complète d'une page, car ils effectuent généralement une simple charge de la page pour mesurer certaines métriques de performances Web et fournir des conseils (bien que les flux utilisateur Lighthouse vous permettent de mesurer au-delà de l'audit de chargement de page par défaut).

Le CrUX est l'ensemble de données officiel du programme Web Vitals. Pour cette raison, la CLS est mesurée tout au long de la durée de vie de la page, et pas seulement lors du chargement initial de la page que mesurent généralement les outils de laboratoire.

Les décalages de mise en page sont très courants lors du chargement de la page, car toutes les ressources nécessaires sont récupérées pour afficher la page initialement. Toutefois, ils peuvent également se produire après le chargement initial. De nombreux décalages post-chargement peuvent se produire à la suite d'une interaction utilisateur et seront donc exclus du score CLS, car il s'agit de décalages attendus, à condition qu'ils se produisent dans les 500 millisecondes suivant cette interaction.

Toutefois, d'autres décalages post-chargement inattendus par l'utilisateur peuvent être inclus en l'absence d'interaction éligible. Par exemple, si vous faites défiler la page et que le contenu chargé de manière différée est chargé, ce qui entraîne des décalages. D'autres causes courantes de CLS post-chargement sont les interactions de transitions, par exemple dans les applications monopages, qui prennent plus de 500 millisecondes que le délai de grâce.

PageSpeed Insights affiche à la fois le CLS perçu par l'utilisateur à partir d'une URL dans la section "Découvrez ce que vos utilisateurs réels vivent" et le CLS de chargement en laboratoire dans la section "Diagnostiquer les problèmes de performances". Les différences entre ces valeurs sont probablement dues au CLS post-chargement.

Identifier les problèmes de chargement de CLS

Lorsque les scores CLS CrUX et Lighthouse de PageSpeed Insights sont globalement alignés, cela indique généralement qu'un problème de CLS de chargement a été détecté par Lighthouse. Dans ce cas, Lighthouse vous aidera à effectuer deux audits pour vous fournir plus d'informations sur les images qui provoquent un CLS en raison de la largeur et de la hauteur manquantes. Il listera également tous les éléments qui ont été décalés lors du chargement de la page, ainsi que leur contribution au CLS. Pour les afficher, filtrez les audits sur les audits CLS:

Le panneau "Performances" de DevTools met également en évidence les changements de mise en page dans la section Expérience. La vue Récapitulatif d'un enregistrement Layout Shift inclut le score cumulé de décalage de mise en page, ainsi qu'un calque rectangulaire indiquant les régions concernées. Cela est particulièrement utile pour obtenir plus de détails sur les problèmes de CLS de chargement, car ils sont facilement reproduits avec un profil de performances de recharge.

Identifier les problèmes de CLS post-chargement

Un désaccord entre les scores CLS de CrUX et de Lighthouse indique souvent un CLS post-chargement. Il peut être difficile de détecter ces variations sans données sur le terrain. Pour en savoir plus sur la collecte de données sur le terrain, consultez Mesurer les éléments CLS sur le terrain.

L'extension Chrome Web Vitals vous permet de surveiller le CLS lorsque vous interagissez avec une page, soit dans un affichage en plein écran, soit dans la console, où vous pouvez obtenir plus d'informations au-dessus des éléments déplacés.

Au lieu d'utiliser l'extension, vous pouvez parcourir votre page Web tout en enregistrant les changements de mise en page à l'aide d'un observateur de performances collé dans la console.

Après avoir configuré la surveillance des changements, vous pouvez essayer de reproduire les problèmes de CLS post-chargement. Le CLS se produit souvent lorsque l'utilisateur fait défiler une page, lorsque le contenu à chargement différé est chargé entièrement sans espace réservé. Le déplacement du contenu lorsque l'utilisateur maintient le pointeur dessus est une autre cause courante de CLS post-chargement. Tout décalage de contenu lors de l'une de ces interactions est considéré comme inattendu, même s'il se produit en 500 millisecondes.

Pour en savoir plus, consultez Déboguer les décalages de mise en page.

Une fois que vous avez identifié les causes courantes du CLS, vous pouvez également utiliser le mode "Par période" du flux utilisateur de Lighthouse pour vous assurer que les flux utilisateur typiques ne régressent pas en introduisant des décalages de mise en page.

Mesurer les éléments CLS sur le terrain

Sur le terrain, surveiller le CLS peut être d'une aide précieuse pour déterminer dans quelles circonstances il se produit et affiner les causes possibles. Comme la plupart des outils de laboratoire, les outils sur le terrain ne mesurent que les éléments qui ont changé, mais cela fournit généralement suffisamment d'informations pour identifier la cause. Vous pouvez également utiliser les mesures du champ CLS pour déterminer les problèmes à résoudre en priorité.

La bibliothèque web-vitals contient des fonctions d'attribution qui vous permettent de collecter ces informations supplémentaires. Pour en savoir plus, consultez Déboguer les performances sur le terrain. D'autres fournisseurs de RUM ont également commencé à collecter et à présenter ces données de la même manière.

Causes courantes de CLS

Une fois que vous avez identifié les causes du CLS, vous pouvez commencer à résoudre les problèmes. Dans cette section, nous allons vous présenter les raisons les plus courantes de ce problème et les mesures que vous pouvez prendre pour l'éviter.

Images sans dimensions

Indiquez toujours les attributs de taille width et height sur vos images et éléments vidéo. Vous pouvez également réserver l'espace requis avec aspect-ratio CSS ou un élément similaire. Cette approche garantit que le navigateur peut allouer la quantité d'espace appropriée dans le document pendant le chargement de l'image.

Historique des attributs width et height sur les images

Au début du Web, les développeurs ajoutaient des attributs width et height à leurs balises <img> pour s'assurer qu'un espace suffisant était alloué sur la page avant que le navigateur ne commence à extraire les images. Cela permet de réduire la refonte et la mise en page.

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

Dans cet exemple, width et height n'incluent pas d'unités. Ces dimensions "pixel" garantissent que le navigateur réserve une zone de 640 x 360 pixels dans la mise en page de la page. L'image s'étirait pour s'adapter à cet espace, que ses dimensions réelles y correspondent ou non.

Lorsque le Responsive Web Design a été introduit, les développeurs ont commencé à omettre width et height et à utiliser CSS pour redimensionner les images à la place:

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

Toutefois, comme la taille de l'image n'est pas spécifiée, aucun espace ne peut lui être alloué tant que le navigateur ne commence pas à la télécharger et ne peut pas déterminer ses dimensions. Lorsque les images se chargent, le texte est décalé vers le bas de la page pour les laisser de la place, ce qui crée une expérience utilisateur confuse et frustrante.

C'est là qu'intervient le format. Le format d'une image correspond à son rapport largeur/hauteur. Il est courant de voir ce rapport exprimé sous la forme de deux nombres séparés par un deux-points (par exemple, 16:9 ou 4:3). Pour un format x:y, l'image mesure x unités de large et y unités de haut.

Cela signifie que si nous connaissons l'une des dimensions, nous pouvons déterminer l'autre. Pour un format 16:9:

• Si puppy.jpg a une hauteur de 360 px, la largeur est de 360 x (16 / 9) = 640 px.
• Si puppy.jpg a une largeur de 640 px, la hauteur est de 640 x (9 / 16) = 360 px.

Connaître le format d'une image permet au navigateur de calculer et de réserver suffisamment d'espace pour la hauteur et la zone associée.

Bonnes pratiques modernes pour définir les dimensions des images

Étant donné que les navigateurs modernes définissent le format par défaut des images en fonction des attributs width et height de l'image, vous pouvez éviter les décalages de mise en page en définissant ces attributs sur l'image et en incluant le CSS précédent dans votre feuille de style.

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

Tous les navigateurs ajoutent ensuite un format par défaut en fonction des attributs width et height existants de l'élément.

Cela permet de calculer un format basé sur les attributs width et height avant le chargement de l'image. Il fournit ces informations au tout début du calcul de la mise en page. Dès qu'une image doit avoir une certaine largeur (par exemple, width: 100%), le format est utilisé pour calculer la hauteur.

Cette valeur aspect-ratio est calculée par les principaux navigateurs lors du traitement du code HTML, plutôt qu'avec une feuille de style par défaut pour l'user-agent (consultez cet article pour en savoir plus). La valeur est donc affichée un peu différemment. Par exemple, Chrome l'affiche comme suit dans la section "Styles" du panneau "Élément" :

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

Safari se comporte de la même manière, en utilisant une source de style Attributs HTML. Firefox n'affiche pas du tout cette aspect-ratio calculée dans son panneau Inspecteur, mais l'utilise pour la mise en page.

La partie auto du code précédent est importante, car elle permet aux dimensions de l'image de remplacer le format par défaut après le téléchargement de l'image. Si les dimensions de l'image sont différentes, cela entraîne toujours un léger décalage de la mise en page après le chargement de l'image. Toutefois, cela garantit que le format de l'image est toujours utilisé lorsqu'il est disponible, au cas où le code HTML serait incorrect. Même si le format réel est différent du format par défaut, il entraîne moins de décalage de mise en page que la taille par défaut de 0x0 d'une image pour laquelle aucune dimension n'est fournie.

Pour en savoir plus sur les formats et les images responsives, consultez Chargement de page sans à-coups avec les formats multimédias.

Si votre image se trouve dans un conteneur, vous pouvez utiliser CSS pour la redimensionner en fonction de la largeur du conteneur. Nous définissons height: auto; pour éviter d'utiliser une valeur fixe pour la hauteur de l'image.

img {
  height: auto;
  width: 100%;
}

Qu'en est-il des images responsives ?

Lorsque vous travaillez avec des images responsives, srcset définit les images que le navigateur peut sélectionner et la taille de chacune d'elles. Pour que les attributs de largeur et de hauteur <img> puissent être définis, chaque image doit utiliser le même format.

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

Les formats de vos images peuvent également varier en fonction de votre direction artistique. Par exemple, vous pouvez inclure un recadrage d'une image pour les vues d'écran étroites et afficher l'image complète sur ordinateur:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

Chrome, Firefox et Safari acceptent désormais de définir width et height sur les éléments <source> d'un élément <picture> donné:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>

Annonces, éléments intégrés et autres contenus chargés tardivement

Les images ne sont pas le seul type de contenu pouvant entraîner des décalages de mise en page. Les annonces, les éléments intégrés, les iFrames et les autres contenus injectés dynamiquement peuvent tous entraîner un décalage vers le bas des contenus qui apparaissent après eux, ce qui augmente votre CLS.

Les annonces sont l'un des principaux facteurs de décalage de mise en page sur le Web. Les réseaux publicitaires et les éditeurs acceptent souvent les tailles d'annonces dynamiques. Les tailles d'annonces améliorent les performances/revenus grâce à des taux de clics plus élevés et à un plus grand nombre d'annonces participant aux enchères. Malheureusement, cela peut entraîner une expérience utilisateur non optimale, car les annonces font défiler le contenu visible que vous consultez vers le bas de la page.

Les widgets intégrés vous permettent d'inclure du contenu Web portable sur votre page, comme des vidéos YouTube, des cartes Google Maps et des posts sur les réseaux sociaux. Cependant, ces widgets ne savent souvent pas quelle est la taille de leur contenu avant de le charger. Par conséquent, les plates-formes proposant des intégrations ne réservent pas toujours de l'espace pour leurs widgets, ce qui entraîne des décalages de mise en page lorsqu'ils se chargent.

Les techniques pour y faire face sont toutes similaires. La principale différence réside dans le contrôle que vous pouvez exercer sur le contenu qui sera inséré. Si ces éléments sont insérés par un tiers, comme un partenaire publicitaire, vous ne pourrez peut-être pas connaître la taille exacte du contenu qui sera inséré ni contrôler les éventuels changements de mise en page dans ces éléments intégrés.

Réserver de l'espace pour le contenu à charger plus tard

Lorsque vous placez du contenu à chargement différé dans le flux de contenu, vous pouvez éviter les décalages de mise en page en réservant l'espace qui lui est dédié dans la mise en page initiale.

Une approche consiste à ajouter une règle CSS min-height pour réserver de l'espace ou, pour les contenus responsifs tels que les annonces, à utiliser la propriété CSS aspect-ratio de la même manière que les navigateurs l'utilisent automatiquement pour les images dont les dimensions sont fournies.

Vous devrez peut-être tenir compte de légères différences de tailles d'annonces ou d'espaces réservés entre les différents facteurs de forme à l'aide de requêtes multimédias.

Pour les contenus dont la hauteur n'est pas fixe, comme les annonces, vous ne pourrez peut-être pas réserver l'espace exact nécessaire pour éliminer complètement le décalage de mise en page. Si une annonce plus petite est diffusée, un éditeur peut styliser un conteneur plus grand pour éviter les décalages de mise en page ou choisir la taille la plus probable pour l'emplacement publicitaire en fonction des données historiques. L'inconvénient de cette approche est qu'elle augmente la quantité d'espace vide sur la page.

Vous pouvez définir la taille initiale sur la plus petite taille qui sera utilisée et accepter un certain niveau de décalage pour les contenus plus volumineux. L'utilisation de min-height, comme suggéré précédemment, permet à l'élément parent de croître si nécessaire, tout en réduisant l'impact des décalages de mise en page par rapport à la taille par défaut de 0 px d'un élément vide.

Essayez d'éviter de réduire l'espace réservé en affichant un espace réservé si, par exemple, aucune annonce n'est renvoyée. Supprimer l'espace réservé aux éléments peut entraîner un CLS tout aussi important que l'insertion de contenu.

Placer le contenu à chargement différé plus bas dans la fenêtre d'affichage

Les contenus injectés dynamiquement plus près du haut de la fenêtre d'affichage entraînent généralement des décalages de mise en page plus importants que les contenus injectés plus bas dans la fenêtre d'affichage. Toutefois, l'injection de contenu n'importe où dans la fenêtre d'affichage entraîne toujours un léger décalage. Si vous ne pouvez pas réserver d'espace pour le contenu injecté, nous vous recommandons de le placer plus loin sur la page afin de réduire son impact sur le CLS.

Éviter d'insérer du contenu sans interaction de l'utilisateur

Vous avez probablement déjà constaté des décalages de mise en page en raison d'une interface utilisateur qui s'affiche en haut ou en bas du viewport lorsque vous essayez de charger un site. Comme pour les annonces, cela se produit souvent avec les bannières et les formulaires qui déplacent le reste du contenu de la page:

Si vous devez afficher ces types d'affordances d'interface utilisateur, réservez suffisamment d'espace dans le viewport à l'avance (par exemple, à l'aide d'un espace réservé ou d'une interface utilisateur squelette) afin que, lors du chargement, le contenu de la page ne soit pas déplacé de manière surprenante. Vous pouvez également vous assurer que l'élément ne fait pas partie du flux du document en superposant le contenu lorsque cela est pertinent. Pour obtenir des recommandations supplémentaires sur ces types de composants, consultez l'article Bonnes pratiques concernant les avis sur les cookies.

Dans certains cas, l'ajout de contenu de manière dynamique est un élément important de l'expérience utilisateur. Par exemple, lorsque vous ajoutez des produits à une liste d'articles ou que vous modifiez le contenu d'un flux en direct. Dans ce cas, il existe plusieurs façons d'éviter les décalages de mise en page inattendus:

• Remplacez l'ancien contenu par le nouveau dans un conteneur de taille fixe ou utilisez un carrousel et supprimez l'ancien contenu après la transition. N'oubliez pas de désactiver tous les liens et les commandes jusqu'à la fin de la transition pour éviter les clics ou les pressions accidentels pendant l'importation du nouveau contenu.
• Demandez à l'utilisateur de lancer le chargement du nouveau contenu afin qu'il ne soit pas surpris par le changement (par exemple, avec un bouton "Charger plus" ou "Actualiser"). Nous vous recommandons de précharger le contenu avant l'interaction de l'utilisateur afin qu'il s'affiche immédiatement. Pour rappel, les décalages de mise en page qui se produisent dans les 500 millisecondes après la saisie utilisateur ne sont pas comptabilisés dans le CLS.
• Chargez le contenu en dehors de l'écran et affichez une notification indiquant à l'utilisateur qu'il est disponible (par exemple, avec un bouton "Défiler vers le haut").

Animations

Les modifications apportées aux valeurs des propriétés CSS peuvent nécessiter une réaction du navigateur. Certaines valeurs, telles que box-shadow et box-sizing, déclenchent une nouvelle mise en page, une nouvelle peinture et une nouvelle composition. Modifier les propriétés top et left entraîne également des décalages de mise en page, même lorsque l'élément déplacé se trouve sur son propre calque. Évitez d'utiliser ces propriétés pour l'animation.

D'autres propriétés CSS peuvent être modifiées sans déclencher de refontes. Par exemple, vous pouvez utiliser des animations transform pour traduire, mettre à l'échelle, faire pivoter ou déformer des éléments.

Les animations composées à l'aide de translate ne peuvent pas avoir d'impact sur d'autres éléments. Elles ne sont donc pas prises en compte dans le CLS. Les animations non composées ne provoquent pas non plus de recomposition. Pour en savoir plus sur les propriétés CSS qui déclenchent des décalages de mise en page, consultez Animations hautes performances.

Polices Web

Le téléchargement et l'affichage des polices Web sont généralement gérés de l'une des deux manières suivantes avant le téléchargement de la police Web:

• La police de remplacement est remplacée par la police Web, ce qui entraîne un flash de texte non stylisé (FOUT).
• Le texte "invisible" est affiché à l'aide de la police de remplacement jusqu'à ce qu'une police Web soit disponible et que le texte soit rendu visible (FOIT, flash de texte invisible).

Les deux approches peuvent entraîner des décalages de mise en page. Même si le texte est invisible, il est toujours mis en page à l'aide de la police de remplacement. Par conséquent, lorsque la police Web est chargée, le bloc de texte et le contenu environnant sont décalés de la même manière que pour la police visible.

Les outils suivants peuvent vous aider à réduire le décalage du texte:

• font-display: optional peut éviter une nouvelle mise en page, car la police Web n'est utilisée que si elle est disponible au moment de la mise en page initiale.
• Assurez-vous que la police de remplacement appropriée est utilisée. Par exemple, l'utilisation de font-family: "Google Sans", sans-serif; garantit que la police de remplacement sans-serif du navigateur est utilisée pendant le chargement de "Google Sans". Si vous ne spécifiez pas de police de remplacement à l'aide de font-family: "Google Sans", la police par défaut est utilisée. Dans Chrome, il s'agit de "Times", une police Serif qui est moins adaptée que la police sans-serif par défaut.
• Réduisez les différences de taille entre la police de remplacement et la police Web à l'aide des nouvelles API size-adjust, ascent-override, descent-override et line-gap-override, comme indiqué dans l'article Amélioration des polices de remplacement.
• L'API de chargement de polices peut réduire le temps nécessaire pour obtenir les polices nécessaires.
• Chargez les polices Web essentielles le plus tôt possible à l'aide de <link rel=preload>. Une police préchargée a plus de chances de répondre à la première peinture, auquel cas il n'y a pas de décalage de mise en page.

Pour en savoir plus sur les bonnes pratiques concernant les polices, consultez Bonnes pratiques concernant les polices.

Réduire le CLS en vous assurant que les pages sont éligibles au bfcache

Pour maintenir un score CLS faible, une technique très efficace consiste à vous assurer que vos pages Web sont éligibles au cache avant/arrière (bfcache).

Le bfcache conserve les pages dans la mémoire du navigateur pendant une courte période après que vous avez quitté la page. Si vous y revenez, elles seront restaurées exactement comme vous les avez laissées. Cela signifie que la page entièrement chargée est disponible instantanément, sans aucun décalage qui pourrait normalement être observé lors du chargement pour l'une des raisons mentionnées précédemment.

Cela signifie que le chargement initial de la page peut toujours rencontrer des décalages de mise en page, mais qu'un utilisateur qui revient sur les pages ne voit pas les mêmes décalages de mise en page de manière répétée. Vous devez toujours essayer d'éviter les décalages, même lors du chargement initial. Toutefois, lorsque cela est plus difficile à résoudre, vous pouvez au moins réduire leur impact en les évitant lors de toute navigation bfcache.

La navigation avant et arrière est courante sur de nombreux sites. Par exemple, pour revenir à une page de contenu, à une page de catégorie ou aux résultats de recherche.

Lorsque cette fonctionnalité a été déployée dans Chrome, nous avons constaté des améliorations notables du CLS.

Le cache amélioré est utilisé par défaut par tous les navigateurs, mais certains sites ne sont pas éligibles pour diverses raisons. Consultez le guide du cache amélioré pour en savoir plus sur la manière de tester et d'identifier les problèmes qui empêchent l'utilisation du cache amélioré. Vous pourrez ainsi vous assurer que vous exploitez pleinement cette fonctionnalité pour améliorer le score CLS global de votre site.

Conclusion

Il existe plusieurs techniques pour identifier et améliorer le CLS, comme indiqué précédemment dans ce guide. Les Core Web Vitals incluent des tolérances. Même si vous ne pouvez pas éliminer complètement le CLS, l'utilisation de certaines de ces techniques devrait vous permettre de réduire son impact. Vous pourrez ainsi respecter ces limites et offrir une meilleure expérience aux utilisateurs de votre site Web.