- →Le score retenu n'est pas la somme des décalages d'une visite mais celui de la pire fenêtre de session, cinq secondes maximum, avec un écart de moins d'une seconde entre deux shifts.
- →Un seul mouvement mal placé suffit : l'exemple canonique de la documentation Google donne 0,1875 pour un bloc qui occupe la moitié du viewport et descend d'un quart de sa hauteur, soit près du double du seuil.
- →Le CLS de laboratoire est presque toujours optimiste : Lighthouse ne scrolle pas et ne charge ni la vraie régie publicitaire ni le vrai consentement. Seul le champ CrUX au 75e percentile sur 28 jours compte.
- →Selon les données CrUX compilées par le Web Almanac 2025, seuls 39 % des sites de presse et de médias passent l'ensemble des Core Web Vitals, la publicité et l'injection de contenu étant les causes majeures côté CLS.
- →En 2026 le CLS reste un signal d'arbitrage, pas un levier de classement : l'audit Lumina de 2026 relève qu'aucun des cinq articles anglophones de référence sur les Core Web Vitals ne passe lui-même ces mêmes seuils.
- →La vraie raison de corriger le CLS est la conversion, pas le ranking : Seologist rapporte en 2026 un passage de 0,25 à 0,05 suivi de 15 % de conversions supplémentaires en trois mois sur un e-commerce international.
Ce que le CLS mesure vraiment
Le Cumulative Layout Shift est la seule des trois métriques du trio de signaux d'expérience de page à ne compter ni millisecondes ni octets. Il quantifie l'instabilité visuelle : la quantité de contenu qui change de position à l'écran alors que l'utilisateur n'a rien demandé. Un score sans unité, produit par des décalages de mise en page observés en conditions réelles, pas une mesure de vitesse d'affichage.
La mécanique retenue par Google depuis la révision de juin 2021 n'additionne plus tous les décalages d'une visite. Elle retient la pire fenêtre de session : une série de layout shifts séparés de moins d'une seconde, plafonnée à cinq secondes. Le score de la page, c'est celui de cette fenêtre. Conséquence rarement intégrée dans les audits : une page longue avec dix micro-décalages étalés sur trois minutes de lecture peut sortir un meilleur CLS qu'une page courte qui bouge trois fois d'affilée au chargement.
Deuxième subtilité de la spécification Layout Instability : tout décalage survenu dans les 500 millisecondes qui suivent une interaction est exclu du calcul, via le drapeau hadRecentInput. Ouvrir un accordéon, dérouler un menu, cliquer sur « voir plus » ne pénalise donc rien. Ce qui est puni, c'est le mouvement non sollicité, celui qui fait rater un bouton ou perdre sa ligne de lecture.
Le seuil publié par Google n'a pas bougé et la documentation officielle le répète en 2026 : 0,1 au 75e percentile pour être classé bon, 0,25 au-delà duquel la page est mauvaise. Ce 75e percentile pèse autant que le chiffre lui-même. On ne mesure pas l'utilisateur moyen, on mesure le quart le moins bien servi, sur une fenêtre glissante de 28 jours. Optimiser sur son propre poste en fibre ne déplace rien du tout.
Fraction d'impact, fraction de distance : le calcul du score
Chaque décalage individuel vaut fraction d'impact multipliée par fraction de distance. La fraction d'impact est la part du viewport couverte par l'union de la zone occupée avant et après le mouvement. La fraction de distance est la plus grande distance parcourue par un élément instable, rapportée à la plus grande dimension du viewport, hauteur ou largeur selon l'orientation.
L'exemple canonique de la documentation Google pose le décor : un bloc occupe la moitié de la hauteur visible, puis descend d'un quart de cette hauteur. L'union avant/après couvre 75 % du viewport, soit une fraction d'impact de 0,75. La fraction de distance vaut 0,25. Le score du décalage ressort à 0,1875, presque le double du seuil acceptable, pour un seul mouvement d'un seul élément. C'est l'ordre de grandeur à garder en tête : un CLS se ruine avec un incident, pas avec cent.
Ce produit explique aussi pourquoi certains correctifs ne rendent rien. Diviser par deux la distance d'un décalage qui touche la quasi-totalité de l'écran rapporte davantage que supprimer trois micro-mouvements en pied de page. Et tous les éléments repoussés parce qu'un bloc a été inséré au-dessus d'eux entrent dans la zone d'impact, même s'ils n'ont ni changé de taille ni changé de nature. Un bandeau de 40 pixels injecté en haut du DOM décale mécaniquement tout ce qui suit.
Une exception vaut d'être connue par cœur : les transformations CSS ne génèrent aucun layout shift. Un élément animé par transform bouge visuellement sans rien décaler dans le flux. Animer top, margin ou height produit au contraire des décalages comptabilisés. La ligne de partage n'est pas « ça bouge ou ça ne bouge pas », c'est « ça repasse par le calcul de mise en page ou pas ».
Ce qui casse le CLS en production
La liste des coupables est courte et remarquablement stable depuis cinq ans. Les images et vidéos sans attributs width et height explicites arrivent en tête : le navigateur ne peut pas réserver la boîte avant le téléchargement, il empile le texte, puis le repousse. Viennent ensuite les emplacements publicitaires dont la hauteur dépend de la créative servie, les embeds tiers qui se redimensionnent après initialisation, et les polices web qui provoquent un reflow au moment de la substitution.
Les données CrUX compilées par le Web Almanac 2025 donnent le chiffre le plus parlant : 39 % seulement des sites de presse et de médias passent l'ensemble des Core Web Vitals, et les régies, les traceurs et l'injection de contenu y sont désignés comme les causes majeures d'échec. Le même rapport situe le CLS et l'INP au-dessus de 75 % de taux de réussite au niveau mondial, tandis que le LCP ne passe que sur environ 62 % des pages mobiles. Autrement dit, un site qui rate son CLS ne rate pas la métrique difficile, il rate la plus facile.
La catégorie la plus sournoise reste l'injection tardive de contenu. Bandeau de consentement inséré dans le flux au lieu d'être posé en overlay, test A/B qui remplace un titre après hydratation, bloc de recommandations chargé en JavaScript trois secondes après le premier rendu, message de personnalisation qui pousse le hero vers le bas. Ces éléments ne sont pas des bugs, ce sont des décisions produit, et c'est pour ça qu'ils survivent aux audits techniques : personne dans l'équipe ne se sent responsable de la métrique.
Dernier angle mort : le lazy loading mal calibré. Charger paresseusement une image située dans le viewport initial garantit un décalage, parce que le navigateur attend le scroll pour lui donner sa taille réelle. La règle est simple, on ne lazy-load jamais ce qui est visible au premier écran.
Mesurer le CLS : terrain contre laboratoire
Deux familles d'outils, deux vérités différentes, et une confusion qui fait perdre des semaines. Les données de terrain viennent du dataset CrUX, alimenté par les utilisateurs Chrome réels : PageSpeed Insights les affiche, l'API CrUX les expose, et le rapport dédié dans la console de recherche les regroupe par modèle d'URL. C'est cette source, et elle seule, qui alimente le signal utilisé par Google. Un compte-rendu de statistiques Core Web Vitals de mars 2026 note d'ailleurs que l'évaluation se fait désormais au niveau de l'origine autant qu'au niveau de la page, ce qui change la façon dont un correctif se propage : améliorer un gabarit d'article ne remonte pas immédiatement une origine plombée par ses pages de catégorie.
Les données de laboratoire viennent de Lighthouse, du panneau Performance de Chrome DevTools et des simulations Web Vitals. Elles sont utiles pour isoler une cause, jamais pour juger un état. Un CLS de laboratoire est presque toujours optimiste : le robot ne scrolle pas, ne clique pas sur le bandeau de consentement, et charge rarement la vraie régie publicitaire. Le réflexe qui paie est d'ouvrir DevTools, d'activer le rendu des Layout Shift Regions, puis de rejouer la page en throttling 3G lent pour voir les zones bleues apparaître une par une.
Cette vidéo officielle de Google détaille les correctifs et complète utilement la partie mesure.
Pour instrumenter en continu, l'API Layout Instability se branche en quelques lignes : un PerformanceObserver sur le type d'entrée layout-shift, en ignorant les entrées portant hadRecentInput, et on remonte le score de la pire fenêtre dans son propre outil d'analyse. C'est la seule façon d'attribuer un décalage à un gabarit, à un partenaire publicitaire ou à un déploiement précis, ce que ni PageSpeed Insights ni la console ne feront jamais pour vous.
Le poids réel du CLS en SEO et en netlinking
Position ferme : le CLS est un critère d'arbitrage, pas un levier de classement. Aucun seuil nouveau n'a été introduit par les core updates de décembre 2025 et de mars 2026, et l'analyse publiée par ApogeeWatcher le 17 mai 2026 rappelle qu'aucune mise à jour estampillée page experience n'est intervenue depuis le déploiement de juin 2021. L'audit Lumina de 2026 enfonce le clou : sur les cinq articles anglophones de référence traitant des Core Web Vitals, aucun ne passe lui-même les seuils, et Ahrefs se classe en première page sur la requête avec un INP terrain d'environ 390 ms, soit près du double du seuil de 200 ms. La pertinence et l'autorité de liens pèsent toujours davantage.
Cela ne veut pas dire que la métrique est décorative. Une analyse du core update de décembre 2025 publiée par ALM Corp relève que les sites affichant un CLS supérieur à 0,15 ont subi environ 19 % de perte de trafic supplémentaire par rapport aux autres pendant ce cycle. Et un panorama statistique de 2026 mesure que les pages en position 1 ont environ 10 % de chances de plus de passer l'ensemble des Core Web Vitals que celles en position 9. Corrélation modeste, réelle, insuffisante pour arbitrer un budget contre du contenu ou des liens.
L'angle qui intéresse vraiment un acheteur de liens est ailleurs. Un média dont le CLS s'effondre est presque toujours un média saturé de scripts tiers, de régies et de blocs injectés côté client. C'est exactement le profil de site où un lien sponsorisé est lui aussi inséré en JavaScript après le rendu, donc invisible pour une bonne partie des crawls, et où il partage la page avec quinze autres liens vendus. Le CLS terrain d'un domaine devient alors un signal de qualité éditoriale par ricochet, gratuit et vérifiable en trente secondes sur PageSpeed Insights avant d'engager un achat. C'est le genre de contrôle qu'on applique sur les médias que nous opérons en propre, où les liens sont écrits dans le HTML au build et où aucun encart n'est poussé après le premier rendu. Le catalogue des médias consultable sans inscription permet de faire cette vérification domaine par domaine, et la grille publique indique à quel prix se négocie une insertion sur chacun.
Corriger le CLS sur WordPress et sur les autres CMS
Sur WordPress, le diagnostic commence toujours au même endroit : le thème et les extensions, pas les images. Les données CrUX relayées en 2026 par HostingStep situent le taux de bon CLS des sites WordPress à 84 % sur mobile contre 71 % sur desktop, une inversion inhabituelle par rapport au LCP et à l'INP où le desktop domine d'ordinaire. La raison tient aux sliders, aux méga-menus et aux blocs publicitaires larges qui n'existent qu'en version large d'écran.
Cette vidéo montre la correction pas à pas sur WordPress avec des outils concrets.
Le tour de chauffe qui règle la majorité des cas tient en quatre gestes. Rétablir les attributs width et height sur toutes les images du contenu, ce que WordPress fait nativement mais que beaucoup de constructeurs de pages retirent, et compléter avec aspect-ratio en CSS pour les médias fluides. Réserver la hauteur des emplacements publicitaires avec un min-height calé sur la créative la plus fréquente plutôt que sur la plus petite, quitte à laisser un blanc. Passer les polices en font-display: swap accompagné de size-adjust et d'une police de repli aux métriques proches, pour que la substitution ne change pas la hauteur de ligne. Sortir le bandeau de consentement du flux et le poser en overlay à position fixe.
Restent les cas tenaces, ceux qu'un plugin d'optimisation ne réglera jamais : les recommandations de contenu chargées après le rendu, les compteurs sociaux, les widgets d'avis. La bonne réponse n'est pas de les supprimer mais de leur allouer une boîte fixe dès le HTML initial, quitte à afficher un squelette. Un espace vide réservé coûte zéro point de CLS, un espace conquis après coup coûte le produit de sa surface par sa distance.
Le contrôle final se fait toujours sur le terrain, pas en laboratoire, et sur 28 jours. C'est long, c'est frustrant, et c'est la seule mesure qui compte. Entre-temps, les gains observés valent le déplacement pour des raisons commerciales plus que pour des raisons de classement : Seologist rapporte en 2026 un e-commerce international passé de 0,25 à 0,05 en stabilisant images produit et boutons, suivi de 15 % de conversions supplémentaires en trois mois, et NitroPack documente sur The Economic Times un CLS ramené à 0,09 accompagné d'un taux de rebond en baisse de 43 %.
Nautilinks opère un réseau de médias éditoriaux. Articles écrits en interne, mentions de transparence respectées, mix d'ancres calibré.
Questions fréquentes
Pourquoi mon CLS Lighthouse est bon alors que la Search Console signale des URL en échec ?
Parce que ce sont deux mesures différentes. Lighthouse produit un score de laboratoire sur un chargement synthétique, sans scroll, sans consentement cliqué et souvent sans la vraie régie publicitaire. La Search Console affiche le champ CrUX, au 75e percentile, sur 28 jours glissants, avec de vrais utilisateurs qui font défiler la page et déclenchent les blocs paresseux. Un écart important entre les deux signale presque toujours un décalage provoqué après le premier écran, donc invisible en laboratoire.
Peut-on atteindre un CLS strictement nul et faut-il le viser ?
Oui, c'est atteignable sur une page statique dont tous les médias ont des dimensions déclarées et qui n'injecte rien après le rendu. Non, ce n'est pas un objectif rentable. Le seuil publié par Google est 0,1 au 75e percentile, et descendre de 0,05 à 0 ne change strictement rien au classement. L'effort marginal se justifie seulement si les décalages restants gênent l'usage, typiquement sur un tunnel de commande où un bouton se déplace au moment du clic.
Le CLS influe-t-il sur la présence dans les AI Overviews ?
Faiblement. Les synthèses publiées en 2026 à partir des travaux de Search Engine Land ne relèvent qu'une corrélation statistique ténue entre la réussite des Core Web Vitals et l'inclusion dans les AI Overviews. La sélection s'opère d'abord sur la pertinence, la clarté de l'extrait et l'autorité de la source. Traiter le CLS comme un levier de visibilité générative revient à optimiser la mauvaise variable.
Faut-il écarter un média dont le CLS est mauvais quand on achète un lien ?
Pas mécaniquement, mais c'est un signal d'alerte à creuser. Un CLS terrain élevé trahit presque toujours une accumulation de scripts tiers et d'encarts injectés côté client. Sur ce type de page, le lien acheté est souvent lui aussi ajouté après le rendu, donc mal vu des crawls, et il cohabite avec beaucoup d'autres liens vendus. Vérifiez plutôt cela : place du lien dans le HTML source, nombre de liens sortants sur la page, densité publicitaire.
L'évaluation au niveau de l'origine change quoi à une stratégie de correction ?
Elle impose de traiter les gabarits par volume de trafic et non par gravité individuelle. Un compte-rendu statistique de mars 2026 indique que Google évalue les Core Web Vitals à l'échelle de l'origine autant qu'à celle de la page. Corriger un gabarit d'article qui pèse peu de sessions ne remonte pas une origine plombée par ses pages de listing. Croisez donc le CLS par modèle d'URL avec les sessions réelles avant d'ouvrir un chantier.
Les animations CSS dégradent-elles le CLS ?
Seulement si elles repassent par le calcul de mise en page. Une animation qui utilise transform ne déplace rien dans le flux et ne génère aucune entrée layout-shift. Une animation qui modifie top, left, margin, width ou height en produit à chaque image. C'est la règle la plus rentable à faire appliquer par une équipe front : composer avec transform et opacity, jamais avec les propriétés géométriques.
Testez vos connaissances
Quiz : Cumulative Layout Shift
1/3Comment Google agrège-t-il les décalages successifs pour établir le CLS d'une page ?