Comment mesurer le CLS : Search Console, PageSpeed Insights, Chrome DevTools et l'extension Web Vitals

Le Cumulative Layout Shift est le Core Web Vital qui mesure la stabilité visuelle : à quel point ta page saute pendant que quelqu’un essaie de la lire ou de cliquer. C’est aussi la métrique la plus douée pour faire s’engueuler une équipe, parce que quatre outils différents te donneront volontiers quatre chiffres différents pour la même page.

Ils ne se contredisent pas. Ils ne mesurent pas la même chose. Une fois que tu sais quel outil répond à quelle question, le CLS devient l’un des vitals les plus simples à débugger. Cet article parle de la mesure. Si tu découvres la métrique, commence par c’est quoi le CLS. Si tu sais déjà ce qui bouge et que tu veux les correctifs, va directement voir optimiser le CLS : 8 correctifs concrets.

Ce que le CLS mesure vraiment

Le CLS est un score sans unité. Chaque layout shift est noté comme la fraction du viewport touchée (impact fraction) multipliée par la distance parcourue par le contenu (distance fraction). Ces shifts sont regroupés en fenêtres de session : une fenêtre s’ouvre au premier shift, s’étend tant que les shifts continuent à moins d’une seconde d’écart, et plafonne à 5 secondes. Le CLS de ta page est le score de la pire fenêtre de session, pas la somme de tout ce qui s’est passé.

Les seuils :

Deux détails qui comptent plus qu’on ne le croit.

Les shifts qui surviennent dans les 500 ms après une interaction utilisateur ne comptent pas. Si quelqu’un clique sur “voir plus” et que le contenu se déploie, c’est attendu, donc exclu. C’est une des raisons pour lesquelles les outils lab et les données réelles divergent dans les deux sens.

Le CLS s’accumule sur toute la durée de vie de la page, pas seulement pendant le chargement. Images lazy-loadées, headers sticky, scroll infini et emplacements pub qui arrivent tard : tout compte. Un outil lab qui charge la page et s’arrête ratera chacun d’eux.

D’abord, comprendre field vs lab

Cette distinction explique à peu près toutes les conversations du type “mais l’outil disait que c’était bon”.

Les données field (terrain) viennent du Chrome User Experience Report (CrUX) : des mesures anonymisées de vrais utilisateurs Chrome, agrégées au 75e percentile sur 28 jours glissants. C’est ce que Google utilise pour ses signaux d’expérience de page. C’est réel, c’est lent à bouger, et c’est là-dessus que tu es noté au final.

Les données lab viennent d’un test synthétique : un seul chargement simulé sur un appareil milieu de gamme émulé, avec réseau bridé. C’est instantané et reproductible, ce qui en fait un bon outil de debug. C’est aussi une fiction. Un visiteur, un chargement, pas de scroll, pas d’interaction.

Le field te dit si tu as un problème. Le lab te dit pourquoi. Il te faut les deux.

1. Google Search Console : le tableau de bord de tout le site

Où : Search Console, puis Expérience, puis Signaux Web essentiels (Core Web Vitals), avec un rapport Mobile et un rapport Ordinateur.

C’est du pur field CrUX, et c’est le rapport à ouvrir en premier parce que c’est le seul qui montre toute la propriété d’un coup.

Les données sont regroupées par groupes d’URL, des ensembles de pages similaires qui correspondent en général à des templates. Fiches produit, articles de blog et pages de catégorie forment chacun leur propre groupe. Le statut d’un groupe est fixé par sa pire métrique : un super LCP et un super INP ne sauveront pas un groupe avec un mauvais CLS. Le chiffre du groupe est le 75e percentile : 75 % des visites sur les pages du groupe ont eu un CLS inférieur ou égal à ce nombre. Clique sur un problème pour voir des URL d’exemple, puis sur une URL pour voir les autres membres de son groupe et lancer directement un test PageSpeed Insights.

Quoi en faire : identifier le template qui échoue, pas la page qui échoue. Si le coupable est un header partagé, une bannière cookies ou un emplacement pub tiers, un seul correctif fera bouger des centaines d’URL d’un coup. Chasser les URL une par une ici est presque toujours du temps perdu.

Quelques limites à garder en tête. Seules les URL indexées apparaissent, et seulement les groupes avec assez de trafic pour atteindre le seuil de publication de CrUX : un petit site peut ne voir presque rien, voire rien du tout. Le tableau d’exemples est plafonné à 200 lignes. Et avec les 28 jours glissants, un correctif livré la semaine dernière mettra des semaines à apparaître complètement. Ne fais pas de rollback en panique parce que la courbe n’a pas encore bougé.

2. PageSpeed Insights : field et lab pour une seule URL

Où : pagespeed.web.dev

PSI fait le pont entre les deux types de données, et la comparaison entre ses deux moitiés est le signal de diagnostic le plus utile qu’il te donne.

La section du haut (“Découvrez ce que vivent vos utilisateurs réels”) est le field CrUX pour cette URL précise. Si l’URL n’a pas assez de trafic à elle seule, PSI se rabat sur les données de l’origine entière. Vérifie laquelle des deux tu regardes ; les gens prennent des données d’origine pour des données de page en permanence.

La section du bas (“Diagnostiquer les problèmes de performances”) est un run Lighthouse en lab. Le CLS figure parmi les cinq métriques en haut, et depuis Lighthouse 12 il pèse un quart du score Performance global.

Le diagnostic à ouvrir s’appelle Layout Shift Culprits, dans la partie Insights du rapport. Il liste les éléments qui ont bougé, la contribution de chacun au CLS et, quand Lighthouse arrive à le déterminer, une cause probable étiquetée du genre “unsized image”, “font request” ou “injected iframe”. Les versions récentes de Lighthouse ont fusionné les anciens audits séparés (layout shifts, images sans dimensions, animations non composées) dans cet unique insight.

Une réserve : Lighthouse identifie les éléments qui ont bougé, qui sont en général les victimes plutôt que la cause. Si une bannière s’injecte en haut de page, l’audit listera tout ce qui se trouve en dessous. Lis la liste comme un pointeur vers une zone de la page, puis cherche ce qui s’est inséré au-dessus.

Maintenant, lis les deux chiffres ensemble. Si le CLS field et le CLS lab sont tous les deux mauvais, tu as un shift au chargement, et Layout Shift Culprits le nommera en général. Si le CLS field est mauvais et le CLS lab à 0,00, tu as un shift post-chargement : Lighthouse n’a jamais scrollé et n’a jamais attendu la troisième pub lazy-loadée. Passe directement à DevTools.

Ce deuxième cas est de loin la question CLS qu’on me pose le plus. “On a 100 dans PageSpeed mais on échoue aux Core Web Vitals” sonne comme une contradiction. Ça n’en est pas une. Ce sont juste deux outils qui répondent à deux questions différentes.

3. Chrome DevTools : là où tu corriges vraiment

DevTools n’est plus seulement un outil lab pour le CLS. Deux fonctionnalités comptent ici.

Les live metrics (page d’accueil du panneau Performance)

Ouvre DevTools et va dans le panneau Performance. Avant même d’enregistrer quoi que ce soit, le panneau affiche le LCP et le CLS locaux en direct pour la page courante, mis à jour en temps réel pendant que tu scrolles et interagis. Sous les cartes de métriques, le tableau Layout shifts journalise chaque shift avec son score et les éléments concernés. Survoler une entrée la surligne dans le viewport, cliquer la sélectionne dans le panneau Elements.

C’est l’outil pour reproduire un CLS post-chargement. Charge la page, puis comporte-toi comme un utilisateur : scrolle jusqu’en bas, survole la nav, ouvre le menu mobile, ferme la bannière cookies, redimensionne. Regarde quelle action fait grimper le chiffre.

Tu peux aussi activer les données field dans le panneau pour afficher les chiffres CrUX de l’URL courante à côté des tiens, basculer entre données d’origine et données d’URL, et passer de mobile à desktop. C’est un moyen rapide de voir si ce que tu reproduis en local correspond à ce que vivent les utilisateurs.

Enregistrer une trace

Une fois que tu reproduis un shift de façon fiable, enregistre une trace. Le résultat contient une piste Layout Shifts dédiée, avec les clusters affichés en barres et les shifts individuels en marqueurs. Cliquer sur l’un d’eux te donne une animation avant/après du shift, les éléments touchés, son score et la fenêtre de session à laquelle il appartient. Tu vois donc exactement quel cluster fixe ton CLS, et tu arrêtes d’optimiser ceux qui ne le fixent pas.

Deux astuces en complément. Dans le tiroir Rendering, active Layout Shift Regions : ça peint un flash bleu sur toute zone qui bouge, et c’est le moyen le plus rapide de repérer les shifts que tu raterais autrement. Et bride en Slow 4G avec un CPU milieu de gamme. Les layout shifts sont une course entre des ressources qui arrivent. Sur une connexion rapide, tout arrive en même temps et rien ne bouge. Tes utilisateurs ne sont pas sur le wifi de ton bureau.

4. L’extension Web Vitals : ce qu’elle est devenue

L’extension Chrome officielle Web Vitals de Google est retirée. Le support s’est arrêté le 7 janvier 2025, quand l’équipe Chrome a fusionné ses fonctionnalités dans le panneau Performance de DevTools. La vue live metrics décrite plus haut est son remplacement direct. L’extension est peut-être encore installée sur ta machine et semble peut-être encore fonctionner, mais elle n’est plus maintenue et ne reçoit plus de mises à jour.

Si tu t’en servais pour le badge permanent et la lecture rapide du CLS, tu as trois options maintenant.

Les live metrics de DevTools sont le successeur officiel, et strictement plus capables.

Plusieurs extensions maintenues par la communauté proposent un overlay des métriques CWV directement sur la page, sans ouvrir DevTools. Pratique pour passer beaucoup de pages en revue rapidement, mais vérifie tout ce qu’elles remontent dans DevTools avant d’agir dessus.

La librairie JavaScript web-vitals est la vraie réponse pour une mesure continue. C’est la même librairie sur laquelle l’extension était construite, elle attribue les shifts à des éléments précis, et tu peux envoyer les données à ta plateforme d’analytics. Ça te donne tes propres données field, à la granularité d’URL que tu veux, mises à jour en quelques heures plutôt qu’en 28 jours.

Si tu bosses le CLS plus qu’occasionnellement, mettre en place du RUM avec web-vitals est ce qui a le plus de levier dans cette liste. Tous les autres outils de cet article sont un échantillon d’un problème que tu pourrais mesurer directement.

Un workflow qui marche

1. Search Console : trouver quels templates échouent, mobile et desktop séparément.
2. PageSpeed Insights sur une URL représentative : comparer le CLS field au CLS lab pour savoir si le problème est au chargement ou après.
3. DevTools : le reproduire. Live metrics plus Layout Shift Regions pour les shifts post-chargement, une trace avec la piste Layout Shifts pour les shifts au chargement.
4. Corriger : attributs width et height ou aspect-ratio sur tous les médias, espace réservé pour les pubs et embeds, font-display: optional ou une police de secours aux métriques alignées pour les webfonts, bannières en overlay plutôt qu’insérées, et transform à la place des propriétés qui déclenchent un layout pour les animations. Le détail et les snippets prêts à coller sont dans l’article sur les correctifs CLS.
5. Vérifier en lab tout de suite, en field patiemment. DevTools confirme le correctif en quelques secondes. CrUX mettra quelques semaines à suivre, et Search Console un peu plus encore.

Pourquoi tes chiffres ne sont pas d’accord : l’antisèche

Le CLS est un indicateur retardé, construit à partir de vraies sessions que tu ne vois pas. L’essentiel du travail consiste à reproduire, sur ta propre machine et volontairement, les conditions que tes utilisateurs subissent par hasard. Les outils ci-dessus servent à ça ; les correctifs, c’est l’étape d’après.