Introduction : Le CLS, ce Core Web Vital que tout le monde sous-estime
En 2026, le Cumulative Layout Shift (CLS) reste le Core Web Vital le plus mal compris. Et honnêtement, c'est un peu normal. Contrairement à l'INP qui mesure la réactivité ou au LCP qui mesure la vitesse de chargement du contenu principal, le CLS quantifie quelque chose de plus subtil : la stabilité visuelle de votre page. C'est précisément parce qu'il est subtil qu'on le néglige — jusqu'au jour où Google pénalise votre classement.
Vous connaissez la situation. Vous lisez un article, vous êtes sur le point de cliquer sur un lien, et soudain la page saute. Une publicité vient de se charger au-dessus de votre contenu. Vous cliquez sur « Annuler » mais le bouton a bougé — et vous venez de confirmer une commande. Voilà le CLS en action.
J'ai vu des sites perdre plusieurs positions dans les résultats Google uniquement à cause d'un CLS mal maîtrisé. En 2026, l'algorithme de classement intègre de plus en plus le concept d'« Experience Equity » : un site doit offrir une mise en page stable sur tous les types d'appareils, pas uniquement sur les derniers smartphones. Un CLS élevé corrèle directement avec les « rage clicks » — un signal que Google surveille de près.
Dans ce guide, on va aller bien au-delà des conseils basiques. On va décortiquer le calcul du CLS, explorer les cinq causes principales avec du code qui fonctionne, et plonger dans les techniques avancées — CSS Containment, font metric overrides, content-visibility, et l'optimisation du bfcache. Allez, c'est parti.
Comment le CLS est Réellement Calculé
Avant de vouloir corriger quoi que ce soit, il faut comprendre ce qu'on mesure. Et spoiler : le CLS n'est pas une simple somme de tous les décalages de la page. C'est plus subtil que ça.
La Formule : Fraction d'Impact × Fraction de Distance
Chaque décalage de mise en page individuel est calculé selon cette formule :
Score de décalage = Fraction d'impact × Fraction de distance
- Fraction d'impact : la proportion du viewport affectée par le décalage. Si un élément de 400 px de haut se déplace de 200 px vers le bas, la zone d'impact couvre 600 px (position initiale + position finale). Sur un viewport de 800 px, la fraction d'impact est 600/800 = 0,75.
- Fraction de distance : la distance de déplacement divisée par la plus grande dimension du viewport. Si l'élément se déplace de 200 px dans un viewport de 800 px, la fraction de distance est 200/800 = 0,25.
Score final : 0,75 × 0,25 = 0,1875. Un seul décalage suffit pour dépasser le seuil « bon » de 0,1. Oui, un seul.
Les Fenêtres de Session
Le CLS ne cumule pas tous les décalages de la page indéfiniment. Il utilise un système de fenêtres de session : des groupes de décalages qui se produisent à moins d'une seconde d'intervalle, avec une durée maximale de 5 secondes par fenêtre. Le CLS final de la page correspond au score de la fenêtre de session la plus élevée — pas la somme de toutes les fenêtres.
Concrètement, ça veut dire qu'un gros décalage isolé est souvent pire que plusieurs petits décalages répartis dans le temps. C'est un point crucial pour le diagnostic (et un détail que beaucoup de développeurs ignorent).
Les Seuils Google
- Bon : CLS ≤ 0,1
- À améliorer : 0,1 < CLS ≤ 0,25
- Mauvais : CLS > 0,25
Google mesure au 75e percentile de vos utilisateurs réels, séparé mobile/desktop. Attention : les données de laboratoire (Lighthouse) ne captent que le CLS au chargement, pas pendant toute la durée de vie de la page. Le rapport Chrome UX (CrUX), lui, mesure l'expérience complète. On y reviendra dans la FAQ.
Cause 1 : Images et Médias sans Dimensions
Les images sont responsables d'environ 60 % des problèmes de CLS. C'est la cause numéro un, et paradoxalement la plus simple à corriger.
Le Problème
Quand une image n'a pas de dimensions spécifiées, le navigateur lui attribue une hauteur de 0 pixel jusqu'à ce qu'elle soit complètement téléchargée. À ce moment-là, tout le contenu en dessous est brutalement poussé vers le bas.
C'est exactement ce que le CLS mesure. Et c'est exactement ce qui agace vos utilisateurs.
La Solution : width, height et aspect-ratio
<!-- ❌ Sans dimensions : CLS garanti -->
<img src="/images/hero.webp" alt="Bannière principale">
<!-- ✅ Avec dimensions : le navigateur réserve l'espace -->
<img
src="/images/hero.webp"
alt="Bannière principale"
width="1200"
height="600"
>Les navigateurs modernes calculent automatiquement le aspect-ratio à partir des attributs width et height, même si vous utilisez du CSS pour rendre l'image responsive. Votre CSS peut simplement faire :
img {
max-width: 100%;
height: auto; /* Le ratio est préservé grâce aux attributs HTML */
}Franchement, c'est tellement simple qu'il n'y a aucune excuse pour ne pas le faire.
Pour les Conteneurs Dynamiques : aspect-ratio en CSS
Quand la taille exacte n'est pas connue à l'avance (vidéos embarquées, iframes), utilisez la propriété CSS aspect-ratio :
/* Conteneur vidéo 16:9 */
.video-container {
width: 100%;
aspect-ratio: 16 / 9;
background-color: #f0f0f0; /* Placeholder visuel */
}
/* Iframe publicitaire avec espace réservé */
.ad-slot {
width: 100%;
aspect-ratio: 728 / 90; /* Format leaderboard */
min-height: 90px;
}Images Responsives avec l'Élément picture
Pour servir le bon format et la bonne taille sans provoquer de CLS, combinez <picture> avec des dimensions explicites :
<picture>
<source
srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1200.avif 1200w"
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 80vw, 1200px"
type="image/avif"
>
<source
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 80vw, 1200px"
type="image/webp"
>
<img
src="hero-800.jpg"
alt="Image principale"
width="1200"
height="600"
fetchpriority="high"
>
</picture>Le point clé : les attributs width et height sur l'élément <img> de fallback suffisent. Le navigateur les utilise pour calculer le ratio, quel que soit le format réellement chargé.
Cause 2 : Les Polices Web et le Problème du Reflow
Le deuxième grand coupable du CLS, c'est le chargement des polices web. Et celui-là, il est plus vicieux que les images.
Quand une police personnalisée met du temps à charger, le navigateur affiche d'abord une police de secours (fallback), puis la remplace par la police définitive. Si ces deux polices ont des métriques différentes — et elles en ont presque toujours — tout le texte se réajuste, provoquant un décalage de mise en page.
Le Piège de font-display: swap
Beaucoup de développeurs utilisent font-display: swap pour éviter le « flash of invisible text » (FOIT). C'est un bon réflexe pour le LCP, mais ça crée un problème pour le CLS : le texte est d'abord rendu avec la police de secours, puis re-rendu avec la police personnalisée, provoquant un reflow visible. Un classique du « je corrige un problème et j'en crée un autre ».
La Solution Avancée : les Font Metric Overrides
En 2026, la meilleure approche consiste à ajuster les métriques de la police de secours pour qu'elle corresponde visuellement à la police personnalisée. CSS offre quatre propriétés pour ça : size-adjust, ascent-override, descent-override et line-gap-override.
/* 1. Déclaration de la police web */
@font-face {
font-family: "Inter";
src: url("/fonts/inter-var.woff2") format("woff2");
font-display: swap;
}
/* 2. Police de secours ajustée pour correspondre à Inter */
@font-face {
font-family: "Inter Fallback";
src: local("Arial");
size-adjust: 107.64%;
ascent-override: 90.49%;
descent-override: 22.48%;
line-gap-override: 0%;
}
/* 3. Utilisation avec fallback en cascade */
body {
font-family: "Inter", "Inter Fallback", sans-serif;
}Le résultat ? Quand la police Inter se charge et remplace la police fallback ajustée, le texte ne bouge pratiquement pas. Duda, une plateforme de création de sites, a amélioré son CLS de 30 % rien qu'avec cette technique. C'est significatif.
Comment Trouver les Bonnes Valeurs
Pour calculer les valeurs de size-adjust, ascent-override et consorts, utilisez des outils comme Capsize ou le Font Metrics Adjuster. Next.js et Nuxt.js intègrent aussi des outils automatiques via la bibliothèque Fontaine. Le principe est assez direct : récupérer les valeurs « Ascender », « Descender » et « Em Square » de votre police web, puis calculer les ratios par rapport à votre police de secours.
Alternative Radicale : font-display: optional
Si le CLS causé par les polices est vraiment problématique et que vous êtes prêt à sacrifier l'apparence lors de la première visite, font-display: optional est l'option la plus sûre. Le navigateur n'échange la police que s'il la charge en moins de 100 ms — sinon, il garde la police de secours.
Zéro CLS garanti, au prix d'une première visite parfois en police système. C'est un compromis qui vaut le coup d'être considéré, surtout pour les sites à fort trafic mobile.
@font-face {
font-family: "Inter";
src: url("/fonts/inter-var.woff2") format("woff2");
font-display: optional; /* Pas d'échange tardif = pas de CLS */
}
/* Préchargement indispensable avec font-display: optional */
<link rel="preload" as="font" href="/fonts/inter-var.woff2"
type="font/woff2" crossorigin>Cause 3 : Contenus Dynamiques, Publicités et Iframes
Bon, on entre dans le territoire le plus frustrant. Les publicités et le contenu injecté dynamiquement sont parmi les contributeurs les plus destructeurs au CLS — et les plus difficiles à maîtriser, car ils proviennent souvent de scripts tiers sur lesquels vous n'avez aucun contrôle.
Le Principe : Réserver l'Espace Avant le Chargement
La règle d'or est simple : ne jamais insérer de contenu au-dessus du contenu existant sans avoir réservé l'espace au préalable.
<!-- ❌ Publicité sans espace réservé : CLS catastrophique -->
<div id="ad-banner"></div>
<!-- ✅ Espace réservé avec dimensions fixes -->
<div id="ad-banner" style="min-height: 250px; min-width: 300px;">
<!-- Le script publicitaire injectera le contenu ici -->
</div>Bannières de Consentement et Notifications
Les bannières de cookies et les notifications push sont des causes fréquentes de CLS (surtout en Europe où le RGPD rend ces bannières quasi obligatoires). La solution est de les positionner en position: fixed ou position: sticky, de sorte qu'elles ne poussent pas le contenu de la page :
.cookie-banner {
position: fixed;
bottom: 0;
left: 0;
right: 0;
z-index: 1000;
/* Ne provoque aucun décalage car retiré du flux normal */
}
.notification-bar {
position: sticky;
top: 0;
z-index: 999;
/* Reste en haut sans pousser le contenu */
}Contenu Chargé Dynamiquement avec JavaScript
Si vous injectez du contenu via JavaScript (recommandations produit, commentaires, widgets sociaux), utilisez des conteneurs avec des dimensions minimales :
/* Skeleton pour un bloc de recommandations */
.recommendations-placeholder {
min-height: 320px;
background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%);
background-size: 200% 100%;
animation: shimmer 1.5s infinite;
}
@keyframes shimmer {
0% { background-position: -200% 0; }
100% { background-position: 200% 0; }
}Attention : le skeleton doit avoir exactement la même hauteur que le contenu final. Un skeleton de 200 px pour un contenu de 350 px provoquera un décalage de 150 px — c'est mieux que 350 px, mais le CLS sera quand même impacté. Mesurez avant de deviner.
Cause 4 : Animations CSS qui Déclenchent un Recalcul de Layout
Toutes les animations CSS ne se valent pas. Si vous animez des propriétés liées à la mise en page — top, left, width, height, margin, padding — le navigateur recalcule la mise en page à chaque frame. Et chaque recalcul, c'est potentiellement un décalage supplémentaire.
La Règle : Toujours Utiliser transform
La propriété CSS transform ne déclenche ni recalcul de mise en page, ni repeinture. Elle est exécutée sur le GPU. Résultat : zéro impact sur le CLS.
/* ❌ Animation avec top/left : déclenche un layout shift */
.slide-in-bad {
position: relative;
animation: slideInBad 0.3s ease-out;
}
@keyframes slideInBad {
from { left: -100px; opacity: 0; }
to { left: 0; opacity: 1; }
}
/* ✅ Animation avec transform : zéro CLS */
.slide-in-good {
animation: slideInGood 0.3s ease-out;
}
@keyframes slideInGood {
from { transform: translateX(-100px); opacity: 0; }
to { transform: translateX(0); opacity: 1; }
}Cas Particulier : les Carrousels
Les carrousels sont un piège classique (et honnêtement, on devrait probablement en utiliser moins, mais c'est un autre débat). Un carrousel qui utilise margin-left ou left pour faire défiler les images va générer un décalage de mise en page à chaque transition.
La solution : utiliser transform: translateX() pour le défilement.
.carousel-track {
display: flex;
transition: transform 0.5s ease-in-out;
/* Le déplacement se fait via transform, pas via margin */
}
/* Pour aller au slide 2 */
.carousel-track[data-slide="2"] {
transform: translateX(-100%);
}
/* Pour aller au slide 3 */
.carousel-track[data-slide="3"] {
transform: translateX(-200%);
}Technique Avancée : CSS Containment pour Isoler les Décalages
La propriété CSS contain est une arme secrète pour le CLS. Elle permet de dire au navigateur : « rien à l'intérieur de cet élément ne peut affecter la mise en page de ce qui est à l'extérieur ». C'est ce qu'on appelle créer des îlots de mise en page.
Les Pages avec un DOM Profond
Si votre page a une profondeur DOM qui dépasse 20 niveaux (et avec les frameworks modernes, c'est plus courant qu'on ne le croit), vous pouvez souffrir de « décalages en cascade » : un petit changement au fond de l'arbre DOM se propage vers le haut et affecte des éléments éloignés. contain coupe cette propagation :
/* Isolation des sections indépendantes */
.card,
.sidebar-widget,
.comment-thread {
contain: layout style;
}
/* Isolation stricte pour les conteneurs publicitaires */
.ad-container {
contain: strict; /* Équivaut à : contain: size layout paint style */
/* Nécessite une taille explicite avec contain: strict */
width: 300px;
height: 250px;
}Prudence avec contain: strict : cette valeur inclut le confinement de taille (size), ce qui signifie que l'élément ne peut pas déduire sa taille de ses enfants. Si vous ne spécifiez pas de dimensions explicites, l'élément risque de se réduire à 0×0. Pour une approche plus sûre, utilisez contain: content (raccourci pour layout paint style sans size).
Tests Terrain : 54 ms vs 732 ms
Des tests de terrain ont mesuré des temps de rendu de 54 ms avec CSS Containment contre 732 ms sans — une réduction de 93 %. Ce n'est pas seulement bon pour le CLS, c'est aussi un boost direct pour l'INP et les performances de rendu globales. Deux problèmes réglés d'un coup.
Technique Avancée : content-visibility pour le Rendu Différé
La propriété content-visibility: auto est devenue Baseline (disponible dans tous les navigateurs majeurs) en septembre 2025. Elle indique au navigateur de différer le rendu des éléments hors écran — layout, peinture, tout — jusqu'à ce qu'ils entrent dans le viewport.
Gain de Performance : jusqu'à 7×
Dans les benchmarks, content-visibility: auto a montré une amélioration des performances de rendu initial jusqu'à 7 fois.
Mais il y a un piège. Et c'est un piège sournois.
Le Piège : CLS sans contain-intrinsic-size
Par défaut, un élément avec content-visibility: auto a une hauteur de 0 quand il est hors écran. Quand l'utilisateur scrolle et que l'élément entre dans le viewport, sa taille réelle est calculée — ce qui provoque un décalage massif. Des tests de terrain ont mesuré des régressions CLS de 0,09 sur mobile Chrome à cause de ça.
Autrement dit, vous optimisez le rendu et vous détruisez votre CLS dans la foulée. Pas idéal.
La Solution : Toujours Associer contain-intrinsic-size
/* ❌ content-visibility seul : risque de CLS */
article {
content-visibility: auto;
}
/* ✅ Avec contain-intrinsic-size : rendu optimisé ET stable */
article {
content-visibility: auto;
contain-intrinsic-size: auto 500px;
/* "auto" = le navigateur mémorise la vraie taille après le premier rendu */
/* "500px" = estimation initiale utilisée comme placeholder */
}Le mot-clé auto est crucial ici. Il indique au navigateur de mémoriser la taille réelle de l'élément après son premier rendu. Ainsi, si l'utilisateur scrolle en arrière, l'élément conserve sa taille correcte au lieu de revenir à l'estimation — ce qui élimine le saut de barre de défilement (scrollbar jumping).
Recommandation Pratique
Appliquez content-visibility à des groupes de contenu granulaires (cards individuelles, articles, sections) plutôt qu'à des sections entières de page. Les gains les plus importants proviennent d'éléments suffisamment petits pour être nombreux, mais assez grands pour que le report de leur rendu soit significatif. Trouver le bon équilibre demande un peu d'expérimentation.
Optimiser le bfcache pour un CLS Nul
Le back/forward cache (bfcache) est la technique qui a produit la plus grande amélioration du CLS en 2022 selon Google. Et en 2026, c'est toujours l'un des leviers les plus puissants — et les plus sous-utilisés.
Pourquoi le bfcache Élimine le CLS
Quand un utilisateur revient à une page via le bouton « Précédent » du navigateur, le bfcache restaure un snapshot complet de la page en mémoire : DOM construit, styles appliqués, images chargées, JavaScript prêt. Résultat : CLS de zéro, car il n'y a tout simplement aucun chargement à effectuer.
Les navigations arrière/avant représentent environ 10 à 20 % des navigations selon l'appareil. C'est loin d'être négligeable.
Les Bloqueurs Principaux du bfcache
Deux causes principales empêchent une page d'être mise en bfcache :
Cache-Control: no-store— Ce header HTTP empêche toute mise en cache. Utilisez plutôtno-cacheou une durée de cache courte pour les pages avec des données modérément sensibles.- Les gestionnaires
unload— Chrome prévoit de déprécier l'événementunload. Utilisezpagehideà la place, et déclarez ce header pour vous protéger :
Permissions-Policy: unload=()Tester l'Éligibilité au bfcache
Dans Chrome DevTools : Application → Background Services → Back/forward cache, puis cliquez sur « Test back/forward cache ». Chrome navigue automatiquement vers une autre page puis revient, et affiche les problèmes détectés.
Attention aux scripts tiers : un seul script tiers mal configuré peut rendre votre page inéligible au bfcache. Par exemple, un outil d'A/B testing utilisant le BroadcastChannel API sans fermer la connexion au bon moment rend la page incompatible — sans aucun signe visible. J'ai déjà passé des heures à traquer ce genre de problème. Testez régulièrement.
Mesurer le CLS avec la Layout Instability API
Pour diagnostiquer précisément les décalages de mise en page, rien ne vaut la mesure côté client avec la Layout Instability API. Voici comment implémenter un observateur CLS complet.
Observer les Décalages en Temps Réel
// Observer les décalages de mise en page
let clsValue = 0;
let clsEntries = [];
const clsObserver = new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
// Ignorer les décalages déclenchés par une interaction utilisateur
if (!entry.hadRecentInput) {
clsValue += entry.value;
clsEntries.push(entry);
}
}
});
clsObserver.observe({ type: "layout-shift", buffered: true });Identifier les Éléments Responsables
C'est là que ça devient vraiment utile pour le debug :
// Inspecter les sources de chaque décalage
const clsDebugObserver = new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
if (!entry.hadRecentInput && entry.value > 0.01) {
console.group(`Décalage détecté : ${entry.value.toFixed(4)}`);
console.log("Timestamp :", entry.startTime.toFixed(0), "ms");
// Identifier les éléments qui ont bougé
if (entry.sources) {
for (const source of entry.sources) {
console.log("Élément :", source.node);
console.log("Position avant :", source.previousRect);
console.log("Position après :", source.currentRect);
}
}
console.groupEnd();
}
}
});
clsDebugObserver.observe({ type: "layout-shift", buffered: true });Capturer le Score Final
// Envoyer le score CLS final quand l'utilisateur quitte la page
document.addEventListener("visibilitychange", () => {
if (document.visibilityState === "hidden") {
clsObserver.takeRecords();
clsObserver.disconnect();
// Envoyer à votre outil d'analytics
navigator.sendBeacon("/api/vitals", JSON.stringify({
metric: "CLS",
value: clsValue,
entries: clsEntries.length
}));
}
});Pour une solution clé en main, la bibliothèque web-vitals de Google fournit une abstraction de haut niveau qui gère tous les cas limites (fenêtres de session, bfcache, iframes). Si vous ne voulez pas réinventer la roue, c'est le meilleur point de départ.
Checklist CLS 2026 : les 10 Vérifications Essentielles
Avant de conclure, voici une checklist rapide que vous pouvez garder sous la main :
- Toutes les images ont des attributs
widthetheight - Les vidéos et iframes ont un
aspect-ratiodéfini - Les polices web utilisent des font metric overrides ou
font-display: optional - Les polices critiques sont préchargées avec
<link rel="preload"> - Les espaces publicitaires ont des dimensions minimales réservées
- Aucun contenu n'est injecté au-dessus du contenu visible existant
- Les animations utilisent
transformetopacityuniquement - Les sections indépendantes utilisent
contain: content content-visibility: autoest toujours associé àcontain-intrinsic-size- La page est éligible au bfcache (pas de
no-store, pas de gestionnaireunload)
Si vous cochez ces dix points, votre CLS devrait être bien en dessous de 0,1 — et vos utilisateurs (ainsi que Google) vous en remercieront.
FAQ : Questions Fréquentes sur le CLS
Quelle est la différence entre le CLS en données de laboratoire et en données de terrain ?
Les données de laboratoire (Lighthouse, PageSpeed Insights mode lab) ne mesurent le CLS que pendant le chargement initial de la page. Les données de terrain (CrUX, web-vitals) capturent le CLS pendant toute la durée de la session — y compris les décalages causés par le lazy loading, les publicités tardives, et les interactions utilisateur. C'est pour ça que votre score CrUX peut être bien pire que votre score Lighthouse. Fiez-vous en priorité aux données de terrain.
Le lazy loading des images aggrave-t-il le CLS ?
Le lazy loading en lui-même ne provoque pas de CLS, à condition que les images aient des dimensions explicites (width et height). Le navigateur réserve l'espace même si l'image n'est pas encore chargée. En revanche, ne mettez jamais loading="lazy" sur votre image LCP : un rapport Chrome UX a montré que les sites qui lazy-loadent leur élément LCP ont un LCP 35 % plus lent.
Comment savoir quels éléments causent du CLS sur ma page ?
Trois méthodes complémentaires : 1) Dans Chrome DevTools, activez « Layout Shift Regions » (via la palette de commandes) pour voir les zones qui se décalent en surbrillance bleue. 2) Utilisez la Layout Instability API avec entry.sources pour identifier les nœuds DOM responsables. 3) Consultez le rapport PageSpeed Insights qui liste les éléments contribuant le plus au CLS dans la section « Diagnostics ».
Le CLS affecte-t-il vraiment le référencement Google ?
Oui. Le CLS est l'un des trois Core Web Vitals intégrés comme facteur de classement par Google. Un score CLS supérieur à 0,25 peut pénaliser votre positionnement, surtout face à des concurrents qui respectent les seuils. En 2026, Google accorde une attention croissante à l'« Experience Equity » — la stabilité doit être assurée sur tous les appareils, pas uniquement sur le matériel récent.
Quelle est la relation entre CSS Containment et content-visibility ?
content-visibility: auto applique automatiquement contain: layout style paint et potentiellement le confinement de taille à l'élément. C'est en quelque sorte un surensemble de CSS Containment, spécialisé pour le rendu différé. Vous pouvez utiliser les deux de manière complémentaire : contain: content sur les sections visibles pour isoler les décalages, et content-visibility: auto sur les sections hors écran pour optimiser le rendu initial.