Tu ouvres un article, tu commences à lire le premier paragraphe, et le texte descend d’un coup à l’écran. Une pub vient de se charger au-dessus. Tu retrouves ta ligne, tu vas taper sur un lien, et pile à ce moment-là une image finit de charger et le lien glisse sous ton doigt. Tu tapes sur autre chose.
Cette expérience a un chiffre attaché. Il s’appelle Cumulative Layout Shift, ou CLS, et c’est l’un des trois Core Web Vitals de Google, à côté du LCP et de l’INP.
La définition
Le CLS mesure le mouvement inattendu du contenu visible d’une page.
Trois mots de cette phrase font tout le travail.
Inattendu : les décalages que l’utilisateur n’a pas demandés. Si quelqu’un clique sur “lire la suite” et que la page se déploie, c’est attendu, et ça ne compte pas.
Visible : seul le mouvement à l’intérieur du viewport est mesuré. Du contenu qui se réorganise loin sous la ligne de flottaison, là où personne ne le voit, n’est pas noté.
Mouvement : précisément, un élément qui change de position entre deux images rendues. Un élément qui apparaît simplement dans un espace vide ne décale rien et score zéro.
L’autre chose à comprendre tout de suite : le CLS couvre toute la durée de vie de la page, pas seulement le chargement. Un shift causé par une image lazy-loadée trente secondes après le début du scroll compte exactement autant qu’un shift causé par une webfont lente au chargement. Beaucoup d’équipes se font avoir là-dessus, parce que la plupart des tests de perf rapides chargent la page et s’arrêtent là.
Comment le score se calcule
Le CLS n’a pas d’unité. Ce ne sont ni des secondes ni des pixels. Chaque shift individuel reçoit un score :
score du layout shift = impact fraction × distance fraction
L’impact fraction, c’est la part du viewport touchée : la surface combinée couverte par l’élément qui bouge, dans sa position de départ et dans sa position d’arrivée, rapportée au viewport.
La distance fraction, c’est la distance parcourue, rapportée à la plus grande dimension du viewport.
Un exemple chiffré rend ça concret. Disons qu’un bloc de texte remplit la moitié haute de l’écran, et qu’une bannière se charge au-dessus en le poussant vers le bas d’un quart de la hauteur d’écran :
- Le bloc occupait les 50 % du haut et occupe maintenant la zone de 25 % à 75 %. L’union de ces deux surfaces fait 75 % du viewport, donc l’impact fraction vaut 0,75.
- Il a bougé de 25 % de la hauteur du viewport, donc la distance fraction vaut 0,25.
- 0,75 × 0,25 = 0,1875 pour ce seul shift.
Une bannière, et tu as déjà explosé le seuil “bon”.
Les fenêtres de session
Les shifts individuels sont regroupés en fenêtres de session. Une fenêtre s’ouvre au premier shift et continue de s’étendre tant qu’un autre shift survient dans la seconde qui suit, jusqu’à un maximum de 5 secondes. Le CLS de ta page est le score de la pire fenêtre, pas le total de tout ce qui s’est passé.
Ça compte plus qu’on ne le croit. Une page avec une seule rafale catastrophique de mouvements score plus mal qu’une page avec beaucoup de petits shifts bien espacés. Et ça veut dire que tu ne dois pas essayer de corriger tous les shifts de la page d’un coup. Trouve la fenêtre qui fixe ton score et commence par elle.
Les seuils
| Score CLS | Verdict |
|---|---|
| 0 à 0,1 | Bon |
| 0,1 à 0,25 | À améliorer |
| Au-dessus de 0,25 | Mauvais |
Ces seuils n’ont pas bougé depuis le lancement des Core Web Vitals, et ils sont toujours les mêmes en 2026, quoi qu’en disent périodiquement certains articles SEO.
Quatre détails sur la façon dont le seuil s’applique vraiment :
- C’est le 75e percentile, pas la moyenne. Ta page passe quand au moins 75 % des vraies visites sont à 0,1 ou en dessous. Une super médiane ne vaut rien si le quart le plus lent de ton trafic passe un sale moment.
- Le mobile et l’ordinateur sont évalués séparément. Passer sur desktop et échouer sur mobile, c’est échouer là où ça compte, vu que le mobile fait en général l’essentiel du trafic.
- Il n’y a pas de crédit partiel. Pour un verdict Core Web Vitals “bon” dans l’ensemble, une page doit avoir LCP, INP et CLS tous les trois au vert. Deux sur trois, c’est un échec.
- Ça repose sur des données field. L’évaluation utilise de vrais utilisateurs Chrome, via le Chrome User Experience Report. Un score lab parfait dans Lighthouse est un diagnostic utile, pas un laissez-passer.
Ce qui provoque les layout shifts
Presque tous les problèmes de CLS se ramènent à la même cause de fond : le navigateur ne savait pas quelle place un élément allait prendre, il a donc mis la page en page sans lui, puis il a dû refaire le travail. Voilà les suspects habituels.
Les images et vidéos sans dimensions. Le grand classique. Sans attributs width et height (ou sans aspect-ratio CSS), le navigateur réserve zéro hauteur, met en page tout ce qui est en dessous, puis pousse tout vers le bas quand l’image arrive. Les navigateurs modernes calculent automatiquement un ratio à partir des attributs HTML, mais seulement si tu les fournis.
Les pubs, embeds et iframes. Du contenu tiers dont tu ne contrôles pas la taille, qui arrive quand le tiers en a envie. Les emplacements pub sont la première source de CLS sur les sites de contenu, et ils sont pires que les images parce que la taille peut varier d’une impression à l’autre.
Le contenu injecté dynamiquement. Bannières cookies, barres newsletter, bandeaux promo, avis “votre session va expirer” : tout ce que du JavaScript insère au-dessus d’un contenu existant une fois la page déjà rendue. Injecter du contenu en haut de page décale tout ce qui est en dessous, et c’est pour ça qu’une bannière cookies peut à elle seule faire échouer un site.
Les webfonts. Une police de secours s’affiche d’abord, puis la webfont se charge et la remplace avec d’autres métriques : d’autres largeurs de caractères, d’autres hauteurs de ligne. Le texte se recompose, et tout ce qui est en dessous bouge. C’est le shift que les équipes ratent le plus souvent, parce qu’il est petit, rapide, et n’apparaît qu’à cache froid.
Animer les mauvaises propriétés. Animer top, left, width, height ou margin déclenche un layout et compte comme un shift. Animer transform et opacity tourne sur le compositor, ne déplace rien dans la mise en page, et score zéro. Même effet visuel, métrique complètement différente.
Le rendu côté client et l’hydratation. Du contenu qui se rend après le chargement du JavaScript, des squelettes de chargement qui n’ont pas la hauteur du vrai contenu, des layouts partagés dont la hauteur change d’une route à l’autre. Dans les single-page apps c’est en général la cause dominante, et elle est invisible pour les outils qui ne mesurent que le chargement initial.
Les mises à jour du DOM qui attendent le réseau. Un bouton qui va chercher des données et déploie un panneau seulement ensuite : si la réponse met plus de 500 ms après le clic, le shift qui en résulte n’est plus attribué à l’interaction et se met à compter contre toi.
Ce qui ne compte pas
Utile à savoir, pour ne pas perdre de temps à courir après :
- Les shifts dans les 500 ms qui suivent une interaction utilisateur sont exclus. Accordéons, menus déroulants, boutons “voir plus” : tout va bien, tant qu’ils réagissent vite.
- Les animations purement compositor (
transform,opacity) ne décalent pas la mise en page. - Les éléments qui apparaissent dans un espace qui leur était déjà réservé.
Pourquoi ça vaut le coup de corriger
L’argument SEO est réel. Le CLS fait partie des signaux d’expérience de page, et passer les trois Core Web Vitals est un avantage sur les requêtes concurrentielles. Mais c’est un départage entre pages comparables, pas un substitut à un contenu de qualité. Quelqu’un qui te promet des gains de classement spectaculaires avec un simple correctif CLS mérite un peu de scepticisme.
L’argument le plus fort est plus simple : les décalages font cliquer à côté. Sur un site de contenu, ça donne des rebonds et des clics pub accidentels. Sur un tunnel de commande, ça donne un client qui appuie sur le mauvais bouton d’un formulaire qu’il était en train de finir. C’est l’une des rares métriques où un mauvais score correspond directement à quelqu’un qui insulte son téléphone.
Et ensuite
Maintenant que tu sais ce que veut dire le chiffre, il y a deux choses à en faire.
Le mesurer correctement, avec des données field plutôt qu’un seul run en lab. Search Console, PageSpeed Insights et Chrome DevTools répondent chacun à une question différente, et ils ne seront pas d’accord entre eux pour de bonnes raisons. Va voir comment mesurer le CLS.
Puis le corriger. Le guide optimiser le CLS : 8 correctifs concrets reprend une par une les causes ci-dessus avec leur remède : réserver la place des images et des pubs, dompter les bannières injectées, faire basculer les polices sans recomposition, le tout replacé dans le contexte du LCP et de l’INP.