Le cumulative layout shift (CLS) mesure à quel point le contenu visible bouge de façon inattendue pendant qu’une page est ouverte, et une bonne valeur est de 0,1 ou moins au 75e percentile des visites (web.dev, avril 2023). Au-delà de 0,25, la valeur est mauvaise. Sur téléphone, les causes habituelles sont les images sans dimensions, les publicités et les intégrations sans espace réservé, les bannières et les avis de cookies injectés en haut de page, les polices web tardives et les animations qui déplacent la mise en page. Repérez l’élément qui bouge dans DevTools, puis réservez son espace avant qu’il ne se charge.
Qu’est-ce que le cumulative layout shift ?
Le CLS est la plus grande rafale de décalages de mise en page pendant la vie d’une page, et non la somme de tous les décalages. Chaque décalage est noté comme fraction d’impact multipliée par fraction de distance. La fraction d’impact est la part de la fenêtre d’affichage couverte par les éléments qui ont bougé, et la fraction de distance est la plus grande distance parcourue par un élément divisée par la plus grande dimension de la fenêtre. Les décalages séparés de moins d’une seconde sont regroupés dans une fenêtre de session d’au plus cinq secondes, et le CLS est la fenêtre au score le plus élevé (web.dev). Les décalages qui commencent dans les 500 ms suivant une action de l’utilisateur sont exclus (web.dev, Optimize CLS, février 2025).
| Note | CLS (p75) |
|---|---|
| Bon | 0,1 ou moins |
| À améliorer | Plus de 0,1, jusqu’à 0,25 |
| Mauvais | Plus de 0,25 |
Ce sont les seuils de Google pour « une bonne valeur », et web.dev recommande de vérifier le 75e percentile séparément pour mobile et ordinateur.
Pourquoi le CLS est plus difficile sur téléphone
Le même mouvement obtient un score plus élevé sur un petit écran, parce que les deux fractions sont mesurées par rapport à la fenêtre d’affichage, et que la plus grande dimension d’un téléphone est plus petite. Pour l’illustrer avec la formule ci-dessus : supposons qu’une bannière de cookies de 80 px de haut apparaisse en haut d’une page et repousse tout vers le bas, dans une fenêtre de 390 × 844 px remplie de contenu. Presque toute la surface de la fenêtre est touchée, donc la fraction d’impact vaut environ 1,0, et la fraction de distance vaut 80 / 844 = 0,095. Le score est d’environ 0,095, à une bannière de la limite de 0,1. C’est une illustration, qui suppose que le contenu remplit la fenêtre.
Les causes sont les mêmes que sur ordinateur, mais notées sur une surface plus petite, et web.dev note que les tailles de publicité peuvent varier selon le format d’appareil, si bien qu’un emplacement réservé pour la taille ordinateur peut être faux sur téléphone.
Le CLS n’est aussi mesuré que dans certains navigateurs. La bibliothèque web-vitals indique que onCLS() ne fonctionne que sur Chromium, alors que ses autres fonctions marchent aussi dans Firefox et Safari (README de web-vitals). Web-features 3.44.0 (octobre 2026) ne montre l’API Layout Instability que dans Chrome et Edge. Le CLS collecté sur le terrain avec cette bibliothèque couvre donc les navigateurs Chromium, et une visite dans Safari sur iPhone ne remonte aucun CLS par ce biais.
Ce qui bouge sur mobile et comment le corriger
Chaque cause a un correctif qui réserve l’espace avant l’arrivée du contenu. Selon le guide de web.dev pour optimiser le CLS (février 2025) :
| Cause | Correctif |
|---|---|
| Images et vidéos sans dimensions | Attributs width et height, ou aspect-ratio en CSS |
| Publicités, intégrations et iframes | Réservez l’espace avec min-height ou aspect-ratio ; gardez un espace réservé quand aucune publicité ne revient |
| Bannières et avis de cookies injectés dans la page | Réservez l’espace avec un espace réservé, ou superposez le contenu pour qu’il ne pousse pas la page |
| Polices web tardives | font-display: optional, une police de secours proche, des métriques de secours de même taille |
| Animations | Animez transform plutôt que top, left ou box-shadow |
Images et vidéos
Définissez la taille intrinsèque de chaque image pour que le navigateur puisse réserver la boîte avant l’arrivée du fichier :
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">img {
height: auto;
width: 100%;
}Pour les images adaptatives, web.dev demande de garder le même rapport d’aspect entre les candidats de srcset, et pour <picture> de mettre width et height sur chaque <source> et sur l’<img>. Un nouveau format d’image ne change que la taille du fichier, donc il ne corrige pas ce problème ; le motif <picture> est expliqué dans WebP vs AVIF. aspect-ratio est Baseline largement disponible depuis mars 2024 (web-features 3.44.0).
Publicités, intégrations et bannières
Réservez l’espace de l’emplacement avec la plus petite taille attendue, et utilisez une requête média là où la taille diffère sur téléphone :
.ad-slot { min-height: 250px; }
@media (min-width: 768px) {
.ad-slot { min-height: 90px; }
}Les deux hauteurs sont des exemples ; utilisez vos propres tailles de publicité. Web.dev ajoute trois conseils : prenez la plus petite taille attendue comme minimum, affichez un espace réservé au lieu de réduire l’espace quand aucune publicité ne revient, et placez le contenu à chargement tardif plus bas dans la fenêtre, car un contenu injecté près du haut provoque des décalages plus grands. Pour un avis de cookies, faites-en une superposition ou réservez sa hauteur dès le premier rendu, au lieu de pousser la page vers le bas quand un script décide de l’afficher.
Polices web
Le texte invisible et le texte sans style provoquent tous deux des décalages, parce que le texte invisible est tout de même mis en page avec la police de secours, selon web.dev. Il suggère font-display: optional et une police de secours proche, des métriques de secours de même taille, et le préchargement des polices critiques. Les valeurs, le préchargement et le code de secours figurent dans le guide font-display swap.
Animations et bouton retour
Animez avec transform, qui ne déclenche pas de mise en page ; web.dev note que les animations translate composées ne comptent pas dans le CLS. Rendez aussi les pages éligibles au cache de retour/avance, car une page restaurée s’affiche comme l’utilisateur l’a quittée, sans décalages liés à un nouveau chargement. Cela n’aide pas au premier chargement.
Comment repérer les décalages de mise en page
Utilisez les outils de laboratoire pour trouver l’élément, et les données terrain pour voir si de vrais utilisateurs le rencontrent. Web.dev indique ces pistes :
- PageSpeed Insights : comparez le CLS terrain (issu du Chrome UX Report) au CLS de laboratoire de Lighthouse. Un grand écart signale en général des décalages après le chargement, que l’exécution en laboratoire ne voit pas.
- Lighthouse : ses audits listent les éléments décalés et leur contribution, mais montrent souvent l’élément touché et non la cause profonde.
- Panneau Performance de DevTools : enregistrez une trace et ouvrez la piste Layout shifts. Les barres violettes marquent les groupes de décalages, un grand losange indique un décalage plus important, et le résumé donne l’heure de début, le score et les éléments décalés. L’insight Layout shift culprits liste le CLS total et les causes probables (web.dev).
Pour voir quel élément a bougé chez de vrais visiteurs, ajoutez la version d’attribution de web-vitals, qui signale la cible du plus grand décalage, son moment et sa valeur :
import {onCLS} from 'web-vitals/attribution';
onCLS(({value, rating, attribution}) => {
console.log(rating, value, {
target: attribution.largestShiftTarget,
time: attribution.largestShiftTime,
score: attribution.largestShiftValue,
});
});Selon web.dev, les décalages à l’intérieur d’iframes ne peuvent pas être mesurés par les API web, mais apparaissent dans le Chrome UX Report. Pour savoir comment lancer Lighthouse et les autres outils, voir le guide d’audit mobile avec Lighthouse et le guide de test de vitesse mobile.
Vérifiez la mise en page à la taille d’un téléphone
Une mise en page qui diffère entre ordinateur et téléphone se repère plus facilement aux largeurs de téléphone. Mobile View Extension recharge l’onglet avec le user agent, la taille d’écran et le ratio de pixels d’un téléphone, ce qui vous montre la version mobile de la page et ce qui bouge pendant le chargement. Il ne mesure ni le CLS ni aucune métrique de vitesse, et il s’exécute sur votre connexion d’ordinateur ; une bannière ou une publicité qui décale la page sur un téléphone lent peut donc se charger trop vite pour être remarquée. Confirmez avec les outils ci-dessus. Pour d’autres raisons qui font qu’une page s’affiche différemment sur téléphone, voir pourquoi un site web s’affiche différemment sur mobile.
Questions fréquentes
Quelle est une bonne valeur de CLS ?
Une bonne valeur de CLS est de 0,1 ou moins, et au-delà de 0,25 elle est mauvaise, mesurées au 75e percentile des chargements de page (web.dev, avril 2023). La plage entre 0,1 et 0,25 est à améliorer.
Qu’est-ce qui provoque le décalage de mise en page sur mobile ?
Les images et vidéos sans dimensions, les publicités, intégrations et iframes sans espace réservé, les bannières et avis de cookies injectés, les polices web qui s’affichent plus grandes ou plus petites que la police de secours, et les animations qui modifient les propriétés de mise en page. Le même mouvement obtient un score plus élevé sur téléphone parce que les fractions sont mesurées sur une fenêtre plus petite.
Comment trouver la cause du CLS ?
Enregistrez une trace dans le panneau Performance de DevTools, ouvrez la piste Layout shifts, puis examinez les éléments décalés dans le résumé. Pour les vrais visiteurs, utilisez la version d’attribution de web-vitals pour remonter largestShiftTarget.
Le CLS affecte-t-il le SEO ?
Google recommande de bonnes Core Web Vitals pour réussir dans la Recherche et indique qu’elles correspondent à ce que ses systèmes de classement principaux cherchent à récompenser ; il ne les présente pas comme un facteur de classement direct (Google Search Central, mise à jour de décembre 2025). L’effet direct touche les visiteurs qui perdent leur place quand la page saute.