Le Cumulative Layout Shift (CLS) mesure la stabilité visuelle d’une page pendant son chargement. Il évalue la taille des éléments et la distance sur laquelle ils se déplacent. C’est l’un des trois indicateurs Core Web Vitals utilisés par Google pour mesurer l’expérience utilisateur d’une page.
Le CLS est calculé sur la fenêtre de cinq secondes qui concentre le plus de décalages.
Voici la formule de calcul :
score de décalage de mise en page = fraction d’impact × fraction de distance
Ou, dit plus simplement :
score de décalage de mise en page = % de la fenêtre d’affichage qui a changé × la distance parcourue par un élément instable
Le CLS est important parce qu’il est franchement pénible de cliquer sur un élément d’une page qui se décale et d’atterrir sur autre chose.
Cela m’arrive régulièrement. Je vise un élément et, soudainement, je clique sur une publicité qui m’envoie sur un autre site. En tant qu’utilisateur, je trouve ça frustrant.
Il y a plusieurs raisons qui expliquent un mauvais CLS :
- Les images sans dimensions définies.
- Les publicités, intégrations et iframes sans dimensions définies.
- L’injection de contenu via JavaScript.
- L’application tardive de polices ou de styles pendant le chargement.
Voyons ce qu’est un bon score CLS et comment l’améliorer.
Un bon score CLS, mesuré à partir des données du Chrome User Experience Report (CrUX), est inférieur ou égal à 0,1. Il s’agit de données provenant de véritables utilisateurs de Chrome ayant accepté de les partager lorsqu’ils visitent votre site. Pour être considéré comme bon, votre score doit être de 0,1 ou moins pour 75 % des chargements de page.
Votre page peut être classée dans l’une des catégories suivantes :
- Bon : <= 0,1
- À améliorer : > 0,1 et <= 0,25
- Médiocre : > 0,25
Données sur le CLS
72,8 % des sites obtiennent un bon score CLS en avril 2023. Cette moyenne est calculée au niveau du site : pour qualifier un site, le seuil doit être tenu sur 75 % des chargements de page.
Le CLS est l’indicateur Core Web Vital qui s’est le plus amélioré depuis l’impulsion donnée par Google en faveur de sites plus rapides.
Lorsque nous avons mené une étude au niveau des pages à partir des données de Site Audit, nous avons constaté que le CLS est similaire sur ordinateur et sur mobile.
Vérifiez gratuitement vos CWV (dont le CLS) avec Site Audit
Nous avons également remarqué que beaucoup de sites peinent à obtenir un bon score CLS, en particulier sur les connexions lentes.
Le CLS est moins bon dans les données au niveau des pages que dans les données au niveau de l’origine. Il est probable que les éditeurs optimisent leurs pages principales, celles qui reçoivent le plus de trafic, tout en laissant un grand nombre d’autres pages avec des scores médiocres.
Il existe deux façons de mesurer le CLS : les données de terrain (field data) et les données de laboratoire (lab data).
Les données de terrain proviennent du Chrome User Experience Report (CrUX), c’est-à-dire de véritables utilisateurs de Chrome ayant choisi de partager leurs données. Elles donnent la meilleure idée des performances CLS réelles. Ce sont aussi les données qui seront effectivement utilisées par Google pour évaluer les Core Web Vitals.
Les données de laboratoire reposent sur des tests réalisés dans des conditions identiques afin d’être reproductibles. Google ne les utilise pas pour les Core Web Vitals, mais elles sont utiles pour vos tests : les données CrUX (de terrain) correspondent à une moyenne glissante sur 28 jours, il faut donc patienter avant de voir l’impact de vos modifications.
Le meilleur outil pour mesurer le CLS dépend du type de données souhaité (laboratoire ou terrain) et du nombre d’URL à analyser.
Mesurer le CLS pour une seule URL
PageSpeed Insights récupère des données de terrain au niveau de la page que vous ne pouvez pas interroger directement dans le jeu de données CrUX. L’outil exécute également des tests en laboratoire basés sur Google Lighthouse et fournit des données d’origine afin de comparer les performances d’une page à celles de l’ensemble du site.
Mesurer le CLS pour plusieurs URL ou un site entier
Vous pouvez obtenir les données CrUX dans Google Search Console, classées dans les catégories bon, à améliorer et médiocre.
En cliquant sur l’un des problèmes, vous obtenez une répartition par groupes de pages affectées. Ces groupes rassemblent des pages ayant des valeurs similaires, vraisemblablement issues d’un même modèle. Une seule modification appliquée au modèle suffira à corriger toutes les pages du groupe.
Si vous souhaitez obtenir à la fois des données de laboratoire et des données de terrain à grande échelle, le seul moyen est de passer par l’API PageSpeed Insights. Vous pouvez vous y connecter facilement avec Site Audit d’Ahrefs et obtenir des rapports détaillés sur vos performances. C’est gratuit pour les sites vérifiés disposant d’un compte Ahrefs Webmaster Tools (AWT).
Notez que les données Core Web Vitals affichées dépendent du user-agent sélectionné pour votre crawl lors de la configuration. Si vous explorez le site en mode mobile, vous obtiendrez les valeurs CWV mobiles renvoyées par l’API.
Outil gratuit : vérifiez les CWV et Lighthouse jusqu’à 10 pages
Voici un autre outil gratuit qui vous permet d’analyser jusqu’à 10 pages ou sites simultanément pour vous comparer à vos concurrents.
Configuration :
- Saisissez votre clé d’API Google PageSpeed Insights dans le champ prévu à cet effet. (Voici comment générer une clé d’API.)
- Ajoutez les URL à analyser (une par ligne).
Lancement de l’analyse :
- Cliquez sur le bouton « Check CWV » pour démarrer la récupération des indicateurs. Une barre de progression affichera l’état des requêtes.
Consultation des résultats :
Les résultats sont présentés sous forme de cartes de score classées par catégorie :
- CWV Desktop pour la page
- CWV Desktop pour l’origine
- Lighthouse Desktop
- CWV Mobile pour la page
- CWV Mobile pour l’origine
- Lighthouse Mobile
Chaque indicateur est associé à un code couleur reflétant la performance :
- Vert : Bon
- Jaune : À améliorer
- Rouge : Médiocre
Vérificateur en masse des Core Web Vitals
Voici un aperçu des cartes de score. L’outil peut aussi être utilisé de manière autonome comme test de vitesse de site web (en anglais).
Dans PageSpeed Insights, si vous sélectionnez le CLS dans la section « Diagnostics », vous verrez l’ensemble des problèmes associés, comme « Éviter les décalages de mise en page importants ». Ce sont ces problèmes qu’il faudra résoudre.
Dans la plupart des cas, pour optimiser le CLS, vous travaillerez sur des problèmes liés aux images, aux polices ou, éventuellement, au contenu injecté. Examinons chaque cas.
1. Réservez l’espace pour les images, vidéos et iframes
Pour les images, l’objectif est de réserver l’espace nécessaire pour que l’image vienne simplement le remplir, sans provoquer de décalage. Cela peut consister à définir la hauteur et la largeur des images directement dans la balise <img> de cette façon :
<img src="cat.jpg" width="640" height="360" alt="cat with string" />
Pour les images responsives, il faut utiliser un srcset comme ceci :
<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" />
Vous devez également réserver l’espace requis pour les vidéos et les iframes. Pour les contenus dynamiques comme les publicités, prévoyez l’espace maximal nécessaire.
Il existe par ailleurs une propriété CSS relativement récente, aspect-ratio, qui permet de définir une largeur dynamique en fonction de la taille de l’écran ; le navigateur calcule alors la hauteur appropriée.
2. Optimisez les polices
Pour les polices, l’objectif est de les afficher à l’écran le plus rapidement possible, et de ne pas les remplacer par d’autres. Lorsqu’une police est chargée ou modifiée, un décalage visible apparaît, du type Flash of Invisible Text (FOIT) ou Flash of Unstyled Text (FOUT).
Si vous pouvez utiliser une police système, faites-le. Il n’y a rien à charger, donc aucun délai ni changement susceptible de provoquer un décalage.
Si vous devez utiliser une police personnalisée, la meilleure méthode actuelle pour minimiser le CLS consiste à combiner <link rel="preload"> (qui va tenter de récupérer votre police le plus tôt possible) et font-display: optional (qui accorde à la police une courte fenêtre temporelle pour se charger).
Si la police n’arrive pas à temps, le chargement initial affichera simplement une police par défaut. Votre police personnalisée sera ensuite mise en cache et apparaîtra lors des chargements de pages suivants.
3. Utilisez des animations qui ne déclenchent pas de changements de mise en page
Certaines propriétés CSS provoquent des décalages de mise en page, telles que box-shadow, box-sizing, top, left, et d’autres, qu’il ne faut pas animer. Privilégiez plutôt les animations basées sur transform afin d’éviter ces décalages.
4. Assurez-vous que vos pages sont éligibles au bfcache
Le back/forward cache conserve les pages dans le cache du navigateur. Il permet de recharger instantanément une page déjà chargée, ce qui signifie qu’aucun décalage de mise en page ne se produira.
Cette optimisation comporte de nombreux aspects. Les principales stratégies sont listées ci-dessous, et vous pouvez consulter le guide complet pour aller plus loin.
Principales stratégies :
- Ne jamais utiliser l’événement
unload. - Limiter l’usage de
Cache-Control: no-store. - Mettre à jour les données obsolètes ou sensibles après la restauration depuis le bfcache.
- Éviter les références
window.opener. - Toujours fermer les connexions ouvertes avant que l’utilisateur ne quitte la page.
- Tester que vos pages sont bien mises en cache.
Conclusion
Depuis l’introduction du CLS, nous avons déjà vu apparaître des innovations comme le bfcache et la propriété CSS aspect-ratio qui aident à résoudre ce problème. Je m’attends à voir émerger d’autres avancées et de nouveaux moyens de prévenir les décalages de mise en page à l’avenir.
Si vous avez des questions, contactez-nous sur LinkedIn pour les francophones.
