Cumulative Layout Shift (CLS)

Ce que le CLS mesure vraiment

Le Cumulative Layout Shift quantifie l'instabilité visuelle d'une page pendant toute sa durée de vie, et non pendant le seul chargement initial. C'est la nuance que la moitié des audits ratent : un décalage provoqué par une bannière de consentement affichée à la trentième seconde compte autant qu'un décalage à 300 ms. Le navigateur observe chaque frame, repère les éléments déjà rendus qui changent de position sans qu'une interaction utilisateur l'ait provoqué, et accumule.

Le mot cumulative est d'ailleurs le plus trompeur du sigle. Depuis la révision de la métrique, le score final n'est plus la somme de tous les décalages de la page : c'est la valeur de la pire fenêtre de session. Une fenêtre s'ouvre au premier layout shift, se ferme après une seconde sans nouveau décalage ou après cinq secondes maximum, et le CLS retenu est le maximum de ces fenêtres. Un site de presse qui charge dix publicités successives ne cumule donc pas dix pénalités, il est jugé sur sa pire salve.

La distinction opérationnelle qui compte : un décalage suivi d'une interaction utilisateur dans les 500 ms est exclu du calcul. Le navigateur pose un drapeau hadRecentInput sur l'entrée correspondante. Ouvrir un accordéon, déplier un menu, charger une page suivante au clic ne dégradent pas le score. Le CLS ne punit pas le mouvement, il punit le mouvement non sollicité.

Cette vidéo pose la définition et montre un cas concret de décalage sur une page réelle.

Le seuil officiel n'a pas bougé : 0,1 ou moins pour être classé « Good », 0,25 comme frontière du « Poor », et l'évaluation se fait au 75e percentile des visites réelles. Le Web Almanac 2025, publié le 5 mai 2026, rappelle ces bornes aux côtés de LCP à 2,5 secondes et INP à 200 ms. Ce 75e percentile est la partie que les développeurs oublient : votre page peut afficher 0,02 sur votre MacBook et 0,18 chez un quart de vos visiteurs mobiles en 4G dégradée. C'est cette dernière valeur qui décide, et elle vit dans les trois indicateurs d'expérience de page que Google agrège.

Fraction d'impact × fraction de distance : le calcul exact

Le score d'un décalage individuel est le produit de deux fractions, toutes deux ramenées au viewport. La fraction d'impact correspond à la surface du viewport occupée par l'union des positions de départ et d'arrivée des éléments instables. La fraction de distance correspond au plus grand déplacement observé, horizontal ou vertical, divisé par la plus grande dimension du viewport.

Un exemple chiffré vaut mieux qu'une formule. Sur un viewport de 1000 pixels de haut, un bloc de texte occupe la moitié supérieure puis est poussé de 200 pixels vers le bas par une image qui se charge au-dessus. La zone impactée couvre le bloc dans ses deux positions, soit 700 pixels sur 1000 : la fraction d'impact vaut 0,7. Le déplacement de 200 pixels sur une hauteur de 1000 donne une fraction de distance de 0,2. Le score du décalage est 0,7 × 0,2 = 0,14. Un seul événement, et la page est déjà au-dessus du seuil.

Ce calcul explique un contre-intuitif que je vois mal compris en audit : un petit élément qui bouge beaucoup pèse souvent moins qu'un grand bloc qui bouge peu. Un bandeau de 40 pixels de haut projeté à 400 pixels plus bas coûte 0,04 × 0,4 = 0,016. Le même bandeau qui pousse tout le contenu principal de 40 pixels coûte bien davantage, parce que la fraction d'impact intègre l'ensemble des éléments déplacés, pas seulement le coupable. Corriger le CLS, c'est donc d'abord protéger la surface qui occupe le haut du viewport, là où la fraction d'impact est structurellement maximale.

Dernier point technique : les éléments qui apparaissent pour la première fois ne comptent pas comme instables. Insérer un bloc dans le DOM n'est pas un décalage, ce qui compte c'est le mouvement des éléments déjà rendus. D'où la règle opérationnelle : insérer sous le pli ou dans un espace déjà réservé est gratuit, insérer en haut de page pousse tout le reste et coûte cher.

Les causes réelles de décalage en production

Après des dizaines de diagnostics, la distribution des causes est d'une monotonie remarquable. Les images et vidéos sans attributs width et height, ou sans aspect-ratio en CSS, arrivent en tête : le navigateur ne peut pas réserver la boîte avant d'avoir téléchargé l'en-tête du fichier, donc il fait remonter le contenu puis le repousse. C'est la cause la plus triviale à corriger et la plus fréquemment encore présente.

Viennent ensuite les emplacements publicitaires et les iframes tierces, dont la hauteur varie selon la créative servie. Un slot déclaré en 250 pixels qui reçoit une créative de 600 pixels décale toute la colonne. L'étude publiée le 2 novembre 2025 par Increv sur 208 000 sites, qui relevait 65,13 % de sites avec un bon CLS, pointait précisément les scripts publicitaires et les polices web comme problèmes persistants. Les chiffres ne sont pas directement comparables à ceux du Web Almanac, les méthodes d'échantillonnage diffèrent, mais le classement des coupables converge.

Les polices produisent un décalage plus discret et plus tenace. Avec font-display: swap, le texte s'affiche d'abord dans la police de repli, puis bascule : si les métriques des deux polices divergent, chaque ligne se réajuste. La correction n'est pas de renoncer au swap mais de calibrer la police de repli avec size-adjust, ascent-override et descent-override, ou d'utiliser font-display: optional quand la charte le permet.

Restent les injections tardives : bandeau de consentement, barre promotionnelle, notification de cookie, module d'A/B testing qui réécrit le DOM après le premier rendu. Ce sont celles qui échappent aux tests, parce qu'un outil de labo lancé sur une page vierge ne déclenche pas toujours le script, et parce que l'équipe qui pose la bannière n'est pas celle qui surveille la performance.

Mesurer le CLS : terrain, labo et API

Les données terrain viennent de CrUX, alimenté par les utilisateurs Chrome ayant accepté la remontée. La version d'octobre 2025, publiée le 11 novembre 2025, couvrait 18 438 315 origines : c'est un référentiel autrement plus large que n'importe quel crawl d'agence, et il est gratuit. Vous y accédez par la Search Console, par PageSpeed Insights, par l'API CrUX ou par BigQuery pour de l'analyse historique.

Une précaution que personne ne mentionne dans les audits qu'on nous fait relire : la documentation du CrUX Dashboard, mise à jour le 9 septembre 2025, précise que le CLS est restitué par paliers d'histogramme de 0,05. Interpréter un passage de 0,08 à 0,10 comme une dégradation réelle relève donc souvent de la lecture de marc de café. Il faut un mouvement d'au moins un palier, confirmé sur plusieurs collectes mensuelles, avant de conclure.

En labo, Lighthouse simule un chargement unique, sans interaction, sans scroll : il rate structurellement les décalages tardifs. Depuis décembre 2025, le panneau Lighthouse de Chrome DevTools est passé en version 13, avec des diagnostics de performance unifiés qui exposent directement les éléments responsables de chaque décalage. C'est un progrès de diagnostic, pas un changement de seuil ni de traitement algorithmique. Pour reproduire un CLS terrain, il faut scroller la page pendant l'enregistrement du panneau Performance, avec throttling réseau et CPU actifs.

Le troisième niveau, celui que presque personne n'exploite, c'est l'instrumentation maison. Un PerformanceObserver abonné au type d'entrée layout-shift vous livre, pour chaque décalage, sa valeur, son drapeau hadRecentInput et surtout un tableau sources qui nomme les nœuds DOM déplacés avec leurs rectangles avant et après. Remonter ces données dans votre analytics transforme le CLS d'un score opaque en une liste de sélecteurs CSS classés par coût. C'est trente lignes de JavaScript et cela remplace des heures de reproduction manuelle. Pour les applications monopage, l'API Soft Navigations introduite en expérimentation dans Chrome 139 en août 2025 permet enfin de rattacher les métriques à une route côté client plutôt qu'au seul chargement initial, avec la réserve qu'elle reste limitée à Chromium.

Le poids réel du CLS en SEO et en netlinking

Position tranchée : en 2026, le CLS est un critère d'hygiène, pas un levier de classement. Le Web Almanac 2025 relève 81 % de pages mobiles au vert sur le CLS, contre 77 % pour l'INP et 62 % seulement pour le LCP, la progression du mobile étant passée de 62 % en 2021 à 81 % en 2025. Autrement dit, la stabilité visuelle n'est plus le goulot d'étranglement : seules 48 % des pages mobiles valident les trois Core Web Vitals simultanément, et sur celles qui échouent c'est le temps d'affichage du plus grand élément visible qui bloque, bien plus souvent que le décalage.

Sur le versant classement, la mise à jour principale de décembre 2025, déployée du 11 au 29 décembre selon Search Engine Land, n'a été accompagnée d'aucune consigne liant les variations de positions aux Core Web Vitals. L'analyse de Search Engine Journal publiée en décembre 2025 sur la performance comparée des CMS qualifie explicitement les Core Web Vitals de signal mineur, utile surtout comme départage entre pages équivalentes. Traitez donc le CLS comme un plancher à atteindre puis à surveiller, pas comme un chantier prioritaire face à la pertinence, au contenu et aux liens.

La vidéo officielle de Google sur l'amélioration du CLS reprend les arbitrages côté rendu.

Côté netlinking, la question qu'on nous pose le plus souvent est de savoir si un hôte au CLS dégradé transmet moins de valeur. Rien ne l'indique, et aucune documentation Google ne va dans ce sens : un lien placé dans un article pertinent conserve son poids même si la page bouge au chargement. Le risque est ailleurs, et il est commercial. Une page d'atterrissage instable détruit le taux de conversion du trafic que vos liens envoient, ce qui rend la campagne mesurable comme un échec alors que l'acquisition, elle, a fonctionné. Sur les médias éditoriaux que nous opérons en propre, la stabilité visuelle fait partie du contrôle technique de chaque gabarit pour cette raison précise : nos annonceurs jugent le résultat business, pas la couleur d'un score. C'est aussi pourquoi nous publions nos tarifs et nos critères de sélection en clair, plutôt qu'un indice composite maison.

L'arbitrage budgétaire est le même que pour toute décision technique : une journée de développement passée à faire tomber un CLS de 0,12 à 0,06 ne rapporte rien en visibilité si votre réactivité aux interactions reste médiocre et si votre profil de liens est vide. Ce même budget investi dans deux articles bien placés sur des médias thématiquement proches produit un retour mesurable, et le catalogue de médias consultable sans inscription permet de faire ce calcul avant de dépenser.

Corriger le CLS sur WordPress et les CMS grand public

WordPress concentre les mêmes causes que partout, avec deux aggravations propres à l'écosystème. Les thèmes et les constructeurs de page injectent souvent des styles après le premier rendu, et l'empilement de greffons d'optimisation produit des effets contradictoires : un module qui diffère le CSS non critique déclenche mécaniquement un re-layout à son application. Si vous chargez le CSS en asynchrone, gardez dans le CSS critique inline toutes les règles qui fixent les dimensions du haut de page.

Le lazy-loading est l'autre piège classique. WordPress ajoute loading="lazy" par défaut, y compris parfois sur l'image de mise en avant située dans le viewport initial : l'image se charge tard, donc elle pousse le texte. Excluez explicitement les images au-dessus du pli du chargement différé, et vérifiez que le thème sort bien les attributs de dimensions dans le HTML, ce que certains constructeurs de page suppriment en réécrivant les balises.

Cette vidéo déroule la correction sur une installation WordPress réelle.

Le choix de plateforme pèse plus qu'on ne l'admet. Le Web Almanac 2025 relève une progression annuelle des Core Web Vitals mobiles d'environ 14 % pour Wix, 11 % pour Duda, 8 % pour Squarespace et 7 % pour Joomla. La comparaison HTTP Archive de novembre 2025 citée par Search Engine Journal montre 84,87 % de sites Duda validant l'ensemble des Core Web Vitals contre 46,28 % pour le CMS le moins bien classé, soit 38,59 points d'écart. Un site hébergé sur une plateforme qui gère nativement les dimensions d'images et le chargement des polices part avec une avance qu'aucun greffon ne rattrape.

Pour l'audit lui-même, un crawler qui branche l'API PageSpeed Insights sur chaque URL vous donne la vue à l'échelle du site plutôt que page par page. Screaming Frog fait ce travail depuis longtemps, sa licence est passée à 199 £ par an en mai 2025, la version gratuite restant plafonnée à 500 URL. Le réflexe qui économise le plus de temps reste le plus simple : lancer l'audit sur les gabarits, pas sur les pages. Un site de 5 000 articles n'a que quatre ou cinq gabarits, corriger le gabarit corrige les 5 000.