CLS des utilisateurs réels (données terrain)

Ce que vérifie ce contrôle

Lit le Cumulative Layout Shift au 75e centile depuis le Chrome User Experience Report — agrégé sur une fenêtre glissante de 28 jours à partir des utilisateurs Chrome consentants. Le CLS est sans unité ; il additionne l’impact de chaque mouvement de mise en page inattendu pendant la visite, plafonné à la plus grande fenêtre d’activité de 5 secondes.

CLS terrain (p75)	Verdict
≤ 0,10	Bon
0,10–0,25	À améliorer
> 0,25	Mauvais

Pourquoi le CLS terrain diffère du CLS de laboratoire :

• Le CLS de laboratoire ne tourne qu’une fois. Lighthouse charge la page, attend quelques secondes, et totalise les décalages.
• Le CLS terrain tourne pendant toute la visite. Les vrais utilisateurs font défiler, cliquent et interagissent pendant des minutes. Chaque décalage compte — y compris les régies publicitaires qui chargent en retard, les images en chargement différé, les variantes A/B, et les widgets de recommandation qui s’hydratent après la première peinture.

C’est pourquoi le CLS terrain est généralement pire que le CLS de laboratoire, et pourquoi le corriger oblige à réfléchir au parcours utilisateur complet, pas seulement aux 5 premières secondes.

Pourquoi c’est important

Le CLS est l’un des trois Core Web Vitals de Google et un signal de classement direct. Un CLS médiocre n’est pas qu’un problème de SEO — c’est un bug d’utilisabilité qui empire à mesure que l’utilisateur reste sur la page :

• Les utilisateurs cliquent sur le mauvais bouton quand une pub pousse le contenu vers le bas.
• Des formulaires sont soumis avec les mauvaises valeurs quand une bannière chargée en retard décale la mise en page.
• Les taux de conversion chutent mesurablement au-dessus d’un CLS de 0,25 (le seuil « Mauvais » de Google).

Si votre CLS terrain est élevé alors que votre CLS de laboratoire est bon, le coupable est presque toujours du contenu qui charge après la première peinture — et les outils de labo n’attendent pas assez longtemps pour le voir.

Comment l’améliorer

1. Réservez la place pour tout ce qui est asynchrone. Chaque image, vidéo, embed, pub ou widget qui charge après la première peinture a besoin de dimensions explicites avant d’être chargé :

<!-- Pour les images, toujours inclure width + height -->
<img src="/photo.jpg" width="600" height="400" alt="..." />

<!-- Pour les iframes (YouTube, Twitter), enveloppez dans un conteneur à ratio fixe -->
<div style="aspect-ratio: 16 / 9;">
  <iframe src="https://www.youtube.com/embed/abc" width="100%" height="100%"></iframe>
</div>

<!-- Pour les emplacements pub, déclarez le min-height en CSS avant le chargement du SDK -->
<div class="ad-slot" style="min-height: 250px;"></div>

2. Évitez d’injecter du contenu au-dessus du contenu existant. Si vous devez afficher une bannière de cookies, placez-la en bas de page ou utilisez une barre collante en haut avec position: fixed — ne l’injectez jamais dans le flux du document.

3. Utilisez font-display: optional (ou swap avec un fallback soigné). Les webfonts qui arrivent en retard font sauter le titre des métriques du fallback à celles de la webfont. Le descripteur CSS size-adjust peut aligner le fallback sur la hauteur d’x de la webfont pour rendre l’échange invisible :

@font-face {
  font-family: "Inter-Fallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

4. Pour les animations, utilisez transform plutôt que top / left / margin. Les animations basées sur transform ne déclenchent pas de mise en page, donc elles ne contribuent pas au CLS.

5. Méfiez-vous des balises <script> à liaison tardive qui mutent le DOM. Outils de personnalisation, GTM, Hotjar, Intercom — autant de coupables habituels. Si un script tiers injecte un élément au-dessus de la ligne de flottaison après le rendu de la page, c’est du CLS.

6. Testez avec les extensions activées. Les outils de labo tournent dans un navigateur propre ; les vrais utilisateurs ont des bloqueurs de pub qui suppriment les placeholders, laissant des mises en page effondrées qui se décalent ensuite à nouveau. Réservez la place avec un CSS qui survit aux manipulations du DOM par les bloqueurs.

Questions fréquentes

Mon CLS est excellent en développement mais mauvais en production. Pourquoi ?

La production a des choses que le dev n’a pas : un vrai inventaire publicitaire, de vraies variantes A/B, de vrais widgets de recommandation, de la vraie personnalisation. Configurez l’API CrUX ou la bibliothèque JS web-vitals pour mesurer en direct en production — npm i web-vitals puis appelez onCLS(reportFn) pour journaliser les décalages en direct.

Les décalages de mise en page suite à une action utilisateur sont-ils comptés ?

Non. Le CLS ne compte que les décalages inattendus — tout ce qui survient dans les 500 ms après un clic, un toucher ou une pression de touche est exclu. Un onglet qui ouvre un accordéon n’est donc pas compté, même s’il décale visiblement le contenu.

Et les liens d’ancrage qui font sauter la page ?

Les défilements vers une ancre ne sont pas comptés comme du CLS — la spécification exclut tout décalage survenant pendant un défilement programmatique. Si votre CLS est mystérieusement élevé, les sauts d’ancrage ne sont pas la cause.