Optimiser le Cumulative Layout Shift

Découvrez comment éviter les changements de mise en page soudains pour améliorer l'expérience utilisateur

Addy Osmani

Barry Pollard

Publié le 5 mai 2020, dernière mise à jour le 7 février 2025

Le Cumulative Layout Shift (CLS) est l'une des trois métriques Core Web Vitals. Il mesure l'instabilité du contenu en combinant la quantité de contenu visible qui a été déplacée dans la fenêtre d'affichage et la distance parcourue par les éléments concernés.

Les décalages de mise en page peuvent distraire les utilisateurs. Imaginez que vous avez commencé à lire un article et que, tout à coup, des éléments se déplacent sur la page, vous déconcentrant et vous obligeant à retrouver votre place. Ce problème est très fréquent sur le Web, y compris lorsque vous lisez les actualités ou que vous essayez de cliquer sur les boutons "Rechercher" ou "Ajouter au panier". Ces expériences sont visuellement choquantes et frustrantes. Elles se produisent souvent lorsque des éléments visibles sont forcés de se déplacer parce qu'un autre élément a été soudainement ajouté à la page ou redimensionné.

Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer de ne pas dépasser un score CLS de 0,1 pour au moins 75 % des visites de page.

Contrairement aux autres signaux vitaux Web, qui sont des valeurs temporelles mesurées en secondes ou en millisecondes, le score CLS est une valeur sans unité basée sur le calcul de la quantité de contenu qui se déplace et de l'ampleur de ce déplacement.

Dans ce guide, nous allons vous expliquer comment optimiser les causes courantes des changements de mise en page.

Voici les causes les plus courantes d'un CLS élevé :

• Images sans dimensions.
• Annonces, éléments intégrés et iFrames sans dimensions.
• Contenu injecté de manière dynamique, comme des annonces, des éléments intégrés et des iFrames sans dimensions.
• Polices Web

Comprendre les causes des changements de mise en page

Avant de chercher des solutions aux problèmes courants de CLS, il est important de comprendre votre score de CLS et d'identifier d'où proviennent les changements.

CLS dans les outils de laboratoire et sur le terrain

Il est fréquent d'entendre des développeurs penser que le CLS mesuré par le rapport Chrome sur l'expérience utilisateur (CrUX) est incorrect, car il ne correspond pas au CLS qu'ils mesurent à l'aide des outils de développement Chrome ou d'autres outils de laboratoire. Les outils de laboratoire de performances Web tels que Lighthouse peuvent ne pas afficher le CLS complet d'une page, car ils effectuent généralement un chargement de base de la page pour mesurer certaines métriques de performances Web et fournir des conseils (bien que les user flows Lighthouse vous permettent de mesurer au-delà de l'audit de chargement de page par défaut).

CrUX est l'ensemble de données Google du programme Web Vitals. Pour cette raison, la CLS est mesurée tout au long de la durée de vie de la page, et pas seulement lors du chargement initial de la page, comme le font généralement les outils de laboratoire.

Les décalages de mise en page sont très fréquents lors du chargement d'une page, car toutes les ressources nécessaires sont récupérées pour afficher la page initialement. Toutefois, ils peuvent également se produire après le chargement initial. De nombreux décalages après le chargement peuvent se produire à la suite d'une interaction utilisateur. Ils seront donc exclus du score CLS, car il s'agit de décalages attendus, à condition qu'ils se produisent dans les 500 millisecondes suivant cette interaction.

Toutefois, d'autres changements après le chargement qui ne sont pas attendus par l'utilisateur peuvent être inclus en l'absence d'interaction éligible. Par exemple, si vous faites défiler la page plus loin et que du contenu à chargement différé est chargé, cela peut entraîner des changements. D'autres causes courantes de CLS après le chargement sont liées aux interactions de transitions, par exemple dans les applications monopages, qui prennent plus de 500 millisecondes.

PageSpeed Insights affiche le CLS perçu par l'utilisateur à partir d'une URL dans sa section "Découvrez ce que vivent vos utilisateurs", ainsi que le CLS de chargement basé sur le laboratoire dans sa section "Diagnostiquer les problèmes de performances". Les différences entre ces valeurs sont probablement dues au CLS après le chargement.

Identifier les problèmes de CLS lors du chargement

Lorsque les scores CLS CrUX et Lighthouse de PageSpeed Insights sont globalement alignés, cela indique généralement qu'il existe un problème de CLS au chargement détecté par Lighthouse. Dans ce cas, Lighthouse vous aidera grâce à deux audits. Il vous fournira plus d'informations sur les images qui provoquent un CLS en raison de l'absence de largeur et de hauteur, et listera également tous les éléments qui ont été déplacés lors du chargement de la page, ainsi que leur contribution au CLS. Vous pouvez afficher ces vérifications en filtrant sur les vérifications du CLS :

Le panneau "Performances" des outils de développement fournit de nombreuses informations sur les changements de mise en page :

Les décalages de mise en page sont mis en surbrillance dans la piste Décalages de mise en page. La ligne violette regroupe les décalages dans des clusters, et les losanges indiquent les décalages individuels dans ce cluster. La taille du losange est proportionnelle à l'ampleur du décalage, ce qui vous permet de vous concentrer sur les plus importants.

Lorsque vous cliquez sur un décalage, une fenêtre pop-up s'affiche avec une animation du décalage et met en évidence les éléments déplacés en violet.

De plus, la vue Résumé d'un enregistrement Layout Shift inclut l'heure de début, le score du décalage et les éléments décalés. Cela est particulièrement utile pour obtenir plus de détails sur les problèmes de CLS de chargement, car ils sont facilement reproductibles avec un profil de performances de rechargement.

Il renvoie également à l'insight Coupables des décalages de mise en page affiché dans le panneau Insights à gauche, qui indique le CLS total en haut, ainsi que les raisons possibles des décalages de mise en page.

Identifier les problèmes de CLS après le chargement

Un écart entre les scores CLS de CrUX et Lighthouse indique souvent un CLS après le chargement. Il peut être difficile de les identifier sans données de champ. Pour savoir comment collecter des données de champ, consultez Mesurer les éléments CLS sur le terrain.

La vue des métriques en direct du panneau "Performances" vous permet d'interagir avec la page et de surveiller le score CLS pour identifier les interactions qui entraînent des décalages de mise en page importants.

Au lieu d'utiliser les outils de développement, vous pouvez parcourir votre page Web tout en enregistrant les changements de mise en page à l'aide d'un observateur de performances collé dans la console.

Une fois la surveillance des changements de mise en page configurée, vous pouvez essayer de reproduire les problèmes de CLS après le chargement. Le CLS se produit souvent lorsque l'utilisateur fait défiler une page et que le contenu à chargement différé se charge complètement sans qu'un espace lui soit réservé. Le décalage du contenu lorsque l'utilisateur pointe dessus est une autre cause fréquente de CLS après le chargement. Tout déplacement de contenu lors de l'une de ces interactions est considéré comme inattendu, même s'il se produit en moins de 500 millisecondes.

Pour en savoir plus, consultez Déboguer les changements de mise en page.

Une fois que vous avez identifié les causes courantes du CLS, vous pouvez également utiliser le mode de flux utilisateur "Timespans" de Lighthouse pour vous assurer que les flux utilisateur typiques ne régressent pas en introduisant des changements de mise en page.

Mesurer les éléments CLS sur le terrain

La surveillance du CLS sur le terrain peut s'avérer très utile pour déterminer dans quelles circonstances le CLS se produit et pour identifier les causes possibles. Comme la plupart des outils de laboratoire, les outils de terrain ne mesurent que les éléments qui ont changé. Toutefois, cela fournit généralement suffisamment d'informations pour identifier la cause. Vous pouvez également utiliser les mesures de champ CLS pour déterminer les problèmes à résoudre en priorité.

La bibliothèque web-vitals comporte des fonctions d'attribution qui vous permettent de collecter ces informations supplémentaires. Pour en savoir plus, consultez Déboguer les performances sur le terrain. D'autres fournisseurs de RUM ont également commencé à collecter et à présenter ces données de manière similaire.

Causes courantes du CLS

Une fois que vous avez identifié les causes du CLS, vous pouvez commencer à résoudre les problèmes. Dans cette section, nous allons vous présenter quelques-unes des raisons les plus courantes de la CLS et ce que vous pouvez faire pour les éviter.

Images sans dimensions

Indiquez toujours les attributs de taille width et height sur vos images et vos éléments vidéo. Vous pouvez également réserver l'espace requis avec CSS aspect-ratio ou un outil similaire. Cette approche permet au navigateur d'allouer la bonne quantité d'espace dans le document pendant le chargement de l'image.

Historique des attributs width et height sur les images

Au début du Web, les développeurs ajoutaient des attributs width et height à leurs balises <img> pour s'assurer qu'un espace suffisant était alloué sur la page avant que le navigateur ne commence à récupérer les images. Cela permet de minimiser le reflow et la réorganisation.

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

Dans cet exemple, width et height n'incluent pas d'unités. Ces dimensions en pixels garantissent que le navigateur réserve une zone de 640 x 360 dans la mise en page. L'image s'étirait pour s'adapter à cet espace, que ses dimensions réelles correspondent ou non.

Lorsque le Responsive Web Design a été introduit, les développeurs ont commencé à omettre width et height et à utiliser CSS pour redimensionner les images :

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

Toutefois, comme la taille de l'image n'est pas spécifiée, l'espace ne peut pas lui être alloué tant que le navigateur n'a pas commencé à la télécharger et à déterminer ses dimensions. Lorsque les images se chargent, le texte se déplace vers le bas de la page pour leur faire de la place, ce qui crée une expérience utilisateur déroutante et frustrante.

C'est là qu'intervient le format. Le format d'une image correspond au rapport entre sa largeur et sa hauteur. Il est courant de voir ce format exprimé sous la forme de deux nombres séparés par un deux-points (par exemple, 16:9 ou 4:3). Pour un rapport d'aspect x:y, l'image a une largeur de x unités et une hauteur de y unités.

Cela signifie que si nous connaissons l'une des dimensions, l'autre peut être déterminée. Pour un format 16:9 :

• Si puppy.jpg a une hauteur de 360 px, la largeur est de 360 x (16 / 9) = 640 px.
• Si la largeur de puppy.jpg est de 640 px, la hauteur est de 640 x (9 / 16) = 360 px.

En connaissant le format d'une image, le navigateur peut calculer et réserver suffisamment d'espace pour la hauteur et la zone associée.

Bonnes pratiques modernes pour définir les dimensions des images

Étant donné que les navigateurs modernes définissent le format par défaut des images en fonction des attributs width et height d'une image, vous pouvez éviter les décalages de mise en page en définissant ces attributs sur l'image et en incluant le code CSS précédent dans votre feuille de style.

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

Tous les navigateurs ajouteront ensuite un format par défaut en fonction des attributs width et height existants de l'élément.

Il calcule un format basé sur les attributs width et height avant le chargement de l'image. Il fournit ces informations au tout début du calcul de la mise en page. Dès qu'une image est définie sur une certaine largeur (par exemple, width: 100%), le format est utilisé pour calculer la hauteur.

Cette valeur aspect-ratio est calculée par les principaux navigateurs lors du traitement du code HTML, plutôt qu'avec une feuille de style User-Agent par défaut (consultez cet article pour en savoir plus). Elle s'affiche donc un peu différemment. Par exemple, Chrome l'affiche comme suit dans la section "Styles" du panneau "Éléments" :

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

Safari se comporte de la même manière, en utilisant une source de style HTML Attributes. Firefox n'affiche pas du tout cette valeur aspect-ratio calculée dans son panneau Inspecteur, mais l'utilise pour la mise en page.

La partie auto du code précédent est importante, car elle permet aux dimensions de l'image de remplacer les proportions par défaut une fois l'image téléchargée. Si les dimensions de l'image sont différentes, cela entraîne toujours un décalage de mise en page après le chargement de l'image, mais cela garantit que les proportions de l'image sont toujours utilisées lorsqu'elles sont disponibles, au cas où le code HTML serait incorrect. Même si le format réel est différent de celui par défaut, il entraîne toujours moins de décalage de mise en page que la taille par défaut 0x0 d'une image sans dimensions fournies.

Pour en savoir plus sur le format et les images responsives, consultez Chargement de pages sans saccades avec les formats multimédias.

Si votre image se trouve dans un conteneur, vous pouvez utiliser CSS pour la redimensionner à la largeur du conteneur. Nous définissons height: auto; pour éviter d'utiliser une valeur fixe pour la hauteur de l'image.

img {
  height: auto;
  width: 100%;
}

Qu'en est-il des images responsives ?

Lorsque vous travaillez avec des images responsives, srcset définit les images entre lesquelles le navigateur peut choisir et la taille de chacune d'elles. Pour que les attributs de largeur et de hauteur <img> puissent être définis, chaque image doit utiliser le même rapport d'aspect.

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

Le format de vos images peut également changer en fonction de votre direction artistique. Par exemple, vous pouvez inclure une image recadrée pour les fenêtres d'affichage étroites et afficher l'image complète sur ordinateur :

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

Chrome, Firefox et Safari permettent désormais de définir width et height sur les éléments <source> d'un élément <picture> donné :

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>

Annonces, éléments intégrés et autres contenus à chargement différé

Les images ne sont pas le seul type de contenu pouvant entraîner des décalages de mise en page. Les annonces, les éléments intégrés, les iFrames et les autres contenus injectés de manière dynamique peuvent tous entraîner un décalage vers le bas du contenu qui les suit, ce qui augmente votre CLS.

Les annonces sont l'un des principaux facteurs de décalage de mise en page sur le Web. Les réseaux publicitaires et les éditeurs acceptent souvent les tailles d'annonces dynamiques. Les formats d'annonces plus grands améliorent les performances et les revenus grâce à des taux de clics plus élevés et à un plus grand nombre d'annonces en concurrence dans les enchères. Malheureusement, cela peut nuire à l'expérience utilisateur, car les annonces font défiler le contenu visible vers le bas de la page.

Les widgets intégrables vous permettent d'inclure du contenu Web portable sur votre page, comme des vidéos YouTube, des cartes Google Maps et des posts sur les réseaux sociaux. Toutefois, ces widgets ne savent souvent pas quelle est la taille de leur contenu avant le chargement. Par conséquent, les plates-formes proposant des intégrations ne réservent pas toujours d'espace pour leurs widgets, ce qui entraîne des décalages de mise en page lorsqu'ils se chargent enfin.

Les techniques pour y faire face sont toutes similaires. La principale différence réside dans le niveau de contrôle que vous avez sur le contenu à insérer. Si ce contenu est inséré par un tiers, comme un partenaire publicitaire, vous ne connaissez peut-être pas la taille exacte du contenu qui sera inséré et vous ne pourrez pas contrôler les changements de mise en page qui se produisent dans ces intégrations.

Réserver de l'espace pour le contenu à chargement différé

Lorsque vous placez du contenu à chargement différé dans le flux de contenu, vous pouvez éviter les changements de mise en page en réservant l'espace pour ce contenu dans la mise en page initiale.

Une approche consiste à ajouter une règle CSS min-height pour réserver de l'espace ou, pour le contenu responsif tel que les annonces, par exemple, à utiliser la propriété CSS aspect-ratio de la même manière que les navigateurs l'utilisent automatiquement pour les images dont les dimensions sont fournies.

Vous devrez peut-être tenir compte des différences subtiles de taille des annonces ou des espaces réservés selon les facteurs de forme à l'aide de requêtes média.

Pour les contenus dont la hauteur n'est pas fixe, comme les annonces, vous ne pourrez peut-être pas réserver l'espace exact nécessaire pour éliminer complètement le décalage de mise en page. Si une annonce plus petite est diffusée, un éditeur peut styliser un conteneur plus grand pour éviter les modifications de mise en page ou choisir la taille la plus probable pour l'emplacement d'annonce en fonction des données historiques. L'inconvénient de cette approche est qu'elle augmente la quantité d'espace vide sur la page.

Vous pouvez définir la taille initiale sur la plus petite taille qui sera utilisée et accepter un certain niveau de décalage pour les contenus plus volumineux. L'utilisation de min-height, comme suggéré précédemment, permet à l'élément parent de croître si nécessaire tout en réduisant l'impact des décalages de mise en page, par rapport à la taille par défaut de 0 px d'un élément vide.

Essayez d'éviter de réduire l'espace réservé en affichant un espace réservé si, par exemple, aucune annonce n'est renvoyée. La suppression de l'espace réservé aux éléments peut entraîner autant de CLS que l'insertion de contenu.

Placer le contenu à chargement tardif plus bas dans la fenêtre d'affichage

Le contenu injecté dynamiquement plus près du haut de la fenêtre d'affichage entraîne généralement des décalages de mise en page plus importants que le contenu injecté plus bas dans la fenêtre d'affichage. Toutefois, l'injection de contenu n'importe où dans la fenêtre d'affichage provoque toujours un certain décalage. Si vous ne pouvez pas réserver d'espace pour le contenu injecté, nous vous recommandons de le placer plus bas sur la page afin de réduire l'impact sur son CLS.

Évitez d'insérer du nouveau contenu sans interaction de l'utilisateur

Vous avez probablement déjà rencontré des décalages de mise en page dus à des éléments d'interface utilisateur qui apparaissent en haut ou en bas de la fenêtre d'affichage lorsque vous essayez de charger un site. Comme pour les annonces, cela se produit souvent avec les bannières et les formulaires qui déplacent le reste du contenu de la page :

Si vous devez afficher ces types d'affordances d'UI, réservez à l'avance suffisamment d'espace dans la fenêtre d'affichage (par exemple, à l'aide d'un espace réservé ou d'une UI squelette) afin que, lors du chargement, le contenu de la page ne se déplace pas de manière inattendue. Vous pouvez également vous assurer que l'élément ne fait pas partie du flux du document en superposant le contenu lorsque cela est pertinent. Pour obtenir d'autres recommandations sur ces types de composants, consultez l'article Bonnes pratiques concernant les bannières de cookies.

Dans certains cas, l'ajout dynamique de contenu est un élément important de l'expérience utilisateur. Par exemple, lorsque vous chargez plus de produits dans une liste d'articles ou lorsque vous mettez à jour le contenu d'un flux en direct. Il existe plusieurs façons d'éviter les changements de mise en page inattendus dans ces cas :

• Remplacez l'ancien contenu par le nouveau dans un conteneur de taille fixe ou utilisez un carrousel et supprimez l'ancien contenu après la transition. N'oubliez pas de désactiver les liens et les commandes jusqu'à ce que la transition soit terminée pour éviter les clics ou les appuis accidentels pendant le chargement du nouveau contenu.
• Demandez à l'utilisateur de lancer le chargement du nouveau contenu afin qu'il ne soit pas surpris par le changement (par exemple, avec un bouton "Charger plus" ou "Actualiser"). Il est recommandé de précharger le contenu avant l'interaction de l'utilisateur afin qu'il s'affiche immédiatement. Pour rappel, les décalages de mise en page qui se produisent dans les 500 millisecondes suivant une saisie utilisateur ne sont pas comptabilisés dans le CLS.
• Chargez le contenu de manière fluide hors écran et superposez une notification pour indiquer à l'utilisateur qu'il est disponible (par exemple, avec un bouton "Faire défiler vers le haut").

Animations

Les modifications apportées aux valeurs des propriétés CSS peuvent nécessiter une réaction du navigateur. Certaines valeurs, telles que box-shadow et box-sizing, déclenchent une nouvelle mise en page, une nouvelle peinture et une nouvelle composition. La modification des propriétés top et left entraîne également des décalages de mise en page, même lorsque l'élément déplacé se trouve sur son propre calque. Évitez d'animer ces propriétés.

D'autres propriétés CSS peuvent être modifiées sans déclencher de réorganisation. Cela inclut l'utilisation d'animations transform pour traduire, mettre à l'échelle, faire pivoter ou incliner des éléments.

Les animations composées à l'aide de translate ne peuvent pas avoir d'impact sur d'autres éléments et ne sont donc pas comptabilisées dans le CLS. Les animations non composées n'entraînent pas non plus de réorganisation. Pour savoir quelles propriétés CSS déclenchent des changements de mise en page, consultez Animations hautes performances.

Polices Web

Le téléchargement et l'affichage des polices Web sont généralement gérés de l'une des deux manières suivantes avant le téléchargement de la police Web :

• La police de secours est remplacée par la police Web, ce qui entraîne un FOUT (Flash of Unstyled Text).
• Le texte "invisible" s'affiche à l'aide de la police de remplacement jusqu'à ce qu'une police Web soit disponible et que le texte soit rendu visible (FOIT, flash de texte invisible).

Les deux approches peuvent entraîner des décalages de mise en page. Même si le texte est invisible, il est toujours mis en page à l'aide de la police de secours. Ainsi, lorsque la police Web se charge, le bloc de texte et le contenu environnant se déplacent de la même manière que pour la police visible.

Les outils suivants peuvent vous aider à minimiser le décalage du texte :

• font-display: optional peut éviter une nouvelle mise en page, car la typographie Web n'est utilisée que si elle est disponible au moment de la mise en page initiale.
• Assurez-vous que la police de remplacement appropriée est utilisée. Par exemple, l'utilisation de font-family: "Google Sans", sans-serif; garantit que la police de secours sans-serif du navigateur est utilisée pendant le chargement de "Google Sans". Si vous ne spécifiez pas de police de remplacement en utilisant uniquement font-family: "Google Sans", la police par défaut sera utilisée. Sur Chrome, il s'agit de "Times", une police avec serif qui est moins adaptée que la police sans-serif par défaut.
• Réduisez les différences de taille entre la police de remplacement et la police Web à l'aide des nouvelles API size-adjust, ascent-override, descent-override et line-gap-override, comme indiqué dans l'article Amélioration des polices de remplacement.
• L'API Font Loading peut réduire le temps nécessaire pour obtenir les polices requises.
• Chargez les polices Web essentielles le plus tôt possible à l'aide de <link rel=preload>. Une police préchargée aura plus de chances de répondre au premier affichage, auquel cas il n'y aura pas de décalage de mise en page.

Pour découvrir d'autres bonnes pratiques concernant les polices, consultez Bonnes pratiques pour les polices.

Réduire le CLS en s'assurant que les pages sont éligibles au bfcache

Une technique très efficace pour maintenir un score CLS bas consiste à s'assurer que vos pages Web sont éligibles au cache Précédent/Suivant (bfcache).

Le cache amélioré conserve les pages dans la mémoire du navigateur pendant une courte période après que vous les avez quittées. Si vous y revenez, elles seront restaurées exactement telles que vous les aviez laissées. Cela signifie que la page entièrement chargée est disponible instantanément, sans aucun décalage qui peut normalement être observé lors du chargement pour l'une des raisons mentionnées précédemment.

Bien que cela puisse encore entraîner des changements de mise en page lors du chargement initial de la page, les utilisateurs ne sont pas confrontés aux mêmes changements de mise en page à plusieurs reprises lorsqu'ils reviennent en arrière. Vous devez toujours essayer d'éviter les changements de mise en page, même lors du chargement initial. Toutefois, si cela est plus difficile à résoudre complètement, vous pouvez au moins réduire l'impact en les évitant lors des navigations bfcache.

La navigation vers l'arrière et vers l'avant est courante sur de nombreux sites. Par exemple, revenir à une table des matières, à une page de catégorie ou à des résultats de recherche.

Lorsque cette fonctionnalité a été déployée dans Chrome, nous avons constaté une amélioration notable du CLS.

Le bfcache est utilisé par défaut par tous les navigateurs, mais certains sites ne sont pas éligibles au bfcache pour diverses raisons. Consultez le guide sur le cache amélioré pour en savoir plus sur la façon de tester et d'identifier les problèmes qui empêchent l'utilisation du cache amélioré. Vous pourrez ainsi vous assurer d'exploiter pleinement cette fonctionnalité pour améliorer le score CLS global de votre site.

Conclusion

Il existe plusieurs techniques pour identifier et améliorer le CLS, comme indiqué plus haut dans ce guide. Des marges sont intégrées aux Core Web Vitals. Ainsi, même si vous ne pouvez pas éliminer complètement le CLS, l'utilisation de certaines de ces techniques devrait vous permettre de réduire son impact. Nous espérons que cela vous permettra de respecter ces limites et d'offrir une meilleure expérience aux utilisateurs de votre site Web.