Qu'est-ce que le Cumulative Layout Shift (CLS) et comment le corriger

Qu'est-ce que le Cumulative Layout Shift (CLS) ?

Le Cumulative Layout Shift (CLS) représente la partie "stabilité visuelle" des Core Web Vitals. Le Cumulative Layout Shift (CLS) mesure les mouvements de la page au fur et à mesure que le contenu s'affiche ou que du nouveau contenu apparaît sur la page. Il calcule un score basé sur la proportion de la page qui se déplace de manière inattendue et sur la distance de ce déplacement. Ces déplacements de contenu sont très ennuyeux, ils vous font perdre le fil d'un article que vous avez commencé à lire ou, pire encore, vous font cliquer sur le mauvais bouton !

Qu'est-ce qu'un bon score Cumulative Layout Shift (CLS) ?

Un bon score CLS se situe entre 0 et 0,1. Si votre score CLS est compris entre 0,1 et 0,25, il doit être amélioré. Tout score CLS supérieur à 0,25 est considéré comme médiocre. Pour valider les Core Web Vitals concernant le Cumulative Layout Shift, au moins 75 % de vos visiteurs doivent avoir un "bon" score CLS.

Importance du CLS dans les performances web et l'expérience utilisateur

Le Cumulative Layout Shift (CLS) est lié à la fois aux performances web et à l'expérience utilisateur, car il a un impact direct sur la sensation de stabilité et de prévisibilité d'une page web pendant son chargement. Voici pourquoi c'est important :

• UX, engagement et perception de la marque : Les changements de mise en page inattendus perturbent le parcours de l'utilisateur, rendant plus difficile la recherche d'informations, le clic sur les boutons et l'interaction avec la page comme prévu. Cette frustration peut conduire à de mauvaises expériences où les utilisateurs abandonnent complètement le site web. L'expérience utilisateur d'un site web reflète la marque qui se trouve derrière. Des changements de mise en page fréquents peuvent donner l'impression d'un site web mal conçu ou mal entretenu, perturber l'engagement des utilisateurs et entraîner une diminution de l'interaction, voire des taux de rebond plus élevés.
• Accessibilité : Les changements de mise en page peuvent être particulièrement perturbants pour les utilisateurs handicapés qui s'appuient sur des technologies d'assistance ou des lecteurs d'écran. Une mise en page stable garantit que chacun peut naviguer et interagir efficacement avec le site web.
• SEO et classement dans les recherches : Les Core Web Vitals constituent un facteur de classement (ranking factor) modeste mais significatif pour Google. Google, tout comme d'autres moteurs de recherche, donne la priorité aux sites web qui offrent une bonne expérience utilisateur. Le CLS est l'une des métriques des Core Web Vitals que Google prend en compte lors du classement des sites web. L'optimisation du CLS peut donner à votre site web un avantage concurrentiel dans les résultats de recherche.

Comment le CLS est-il mesuré ?

Le CLS d'une page peut être mesuré avec l'API Layout Instability. Voici une utilisation simple de cette API :

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Calcul du CLS

Le CLS est calculé à l'aide d'une formule simple mais élégante :

CLS = somme(fraction d'impact * fraction de distance)

La fraction d'impact (impact fraction) mesure quelle proportion du contenu visible de la page s'est déplacée. La fraction de distance (distance fraction) mesure la distance sur laquelle le contenu s'est déplacé. Si, par exemple, 50 % de la page (quelle proportion) s'est déplacée de 25 % (quelle distance) du viewport (fenêtre d'affichage) de la page, le score CLS = 0,50 * 0,25 = 0,125.

Changements de mise en page attendus vs inattendus

Tous les changements de mise en page ne sont pas mauvais, seulement ceux auxquels vous ne vous attendez pas. Lorsque vous cliquez sur un lien "charger plus d'éléments", par exemple, vous vous attendez à ce que plus d'éléments apparaissent sur la page et que le contenu de la page se décale.

C'est pourquoi seuls les changements de mise en page inattendus contribueront au CLS. Par exemple, si un utilisateur clique sur un bouton et qu'en réponse du nouveau contenu est ajouté à la page (par exemple un menu déroulant), le changement de mise en page sera exclu du CLS. Pour être précis : les changements de mise en page qui se produisent dans les 500 millisecondes suivant une saisie utilisateur (user input) seront exclus des calculs.

Sessions de changements de mise en page

Lorsque le CLS a été introduit pour la première fois, certains sites ont été injustement pénalisés avec un mauvais score CLS. Par exemple, une page implémentant un défilement infini (infinite scrolling) aurait vu l'impact du nouveau contenu ajouté s'ajouter au score CLS total pour chaque nouveau défilement. C'est pourquoi le CLS est désormais calculé par sessions. Chaque session a une durée maximale de 5 secondes et un écart d'une seconde entre les changements de mise en page. La session ayant le score CLS le plus élevé deviendra le score CLS final.

Si, par exemple, lors de la première session le score CLS est de 0,095, puis dans la session suivante le CLS est de 0,15, et pour la dernière session le score CLS est de 0, le score CLS final sera le plus élevé des trois : 0,15.

Le CLS et les Core Web Vitals

Le Cumulative Layout Shift (CLS) est une métrique importante, centrée sur l'utilisateur, permettant de mesurer la stabilité visuelle. Le Cumulative Layout Shift (CLS) fait partie des Core Web Vitals, au même titre que le Largest Contentful Paint (LCP) et l'Interaction to Next Paint (INP). Ensemble, ces trois métriques mesurent les performances de chargement, l'interactivité et la stabilité visuelle.

Comment mesurer les problèmes de CLS

1. Utiliser Lighthouse pour trouver les Cumulative Layout Shifts

La méthode la plus simple pour trouver les changements de mise en page consiste à utiliser Lighthouse dans votre propre navigateur Chrome. Il suffit d'exécuter un audit Lighthouse en faisant un clic droit n'importe où sur la page. Sélectionnez ensuite Inspecter, sélectionnez l'onglet Lighthouse dans la console désormais ouverte et exécutez l'audit.

Les résultats de l'audit afficheront le score Cumulative Layout Shift (CLS). Faites défiler vers le bas jusqu'à Diagnostics et développez les informations du Cumulative Layout Shift pour voir quels nœuds (nodes) sont à l'origine du changement de mise en page.

Pour être honnête, je n'utilise presque jamais cette méthode moi-même. Le manque de détails sur la distance exacte du changement de mise en page rend ces résultats plus difficiles à interpréter.

2. Utiliser le CLS Visualizer pour trouver les Cumulative Layout Shifts

Le CLS Visualizer est une extension Chrome que j'ai écrite. D'un simple clic sur un bouton, tous les changements de mise en page sur la page sont visualisés. C'est la première solution vers laquelle je me tourne lorsque j'essaie de déterminer un changement de mise en page sur une page. C'est facile et cela donnera un excellent aperçu visuel du Cumulative Layout Shift.

3. Utiliser l'onglet Performances de Chrome pour trouver le CLS

La meilleure façon, et de loin, de déboguer un changement de mise en page est via l'onglet Performance (Performances) de Chrome. Pour ouvrir l'onglet Performance, naviguez vers n'importe quelle page dans Chrome et utilisez cette combinaison de raccourcis :

• Appuyez sur Ctrl+Shift+I (Ouvrir les Dev Tools)
• Appuyez sur Ctrl+Shift+E (Démarrer le profilage et recharger la page)

Inspectez maintenant la timeline (chronologie) image par image en survolant avec votre souris la timeline en haut et cherchez les changements de mise en page (les layout shifts sont également colorés en rouge dans la section Expérience de l'onglet Performance).

4. Utiliser des outils RUM comme CoreDash

RUM signifie Real User Monitoring et les données RUM peuvent fournir de précieuses informations en temps réel sur les Core Web Vitals. Les outils RUM comme CoreDash peuvent décomposer les Cumulative Layout Shifts en segments comme le navigateur, l'élément, le type de navigation, l'URL spécifique ou le type de page. Cela aidera à identifier et à corriger les pages peu performantes et les éléments incriminés.

Causes fréquentes du Cumulative Layout Shift et comment les corriger

L'origine de tous les changements de mise en page est fondamentalement la même. À un moment donné, un élément qui était placé au-dessus d'un autre élément a pris plus ou moins d'espace qu'auparavant. Ceci est généralement dû à l'une ou plusieurs de ces causes :

• Images, iframes ou vidéos sans dimensions explicites
• Publicités se chargeant tardivement dans le viewport
• Contenu injecté dynamiquement
• Animations CSS utilisant des propriétés déclenchant une modification de la mise en page (layout-triggering)
• Interactions utilisateur lentes
• Polices web avec des polices de secours (fallbacks) non correspondantes

CLS causé par les images, les vidéos et les iframes

Les images, les vidéos et les iframes sont les suspects habituels en ce qui concerne le Cumulative Layout Shift, car ces éléments constituent la majorité des problèmes de CLS. Pour un guide détaillé sur cette cause spécifique, voir comment corriger le changement de mise en page causé par le redimensionnement automatique des images.

Les changements de mise en page causés par des images, des vidéos ou des iframes sont toujours dus à des dimensions manquantes. Le plus souvent, c'est parce que la hauteur et la largeur de l'élément ne sont pas définies dans le HTML. Un modèle courant et une bonne pratique consistent à définir la largeur intrinsèque de l'image dans le HTML et à utiliser le style (CSS) pour mettre à l'échelle automatiquement l'image afin de la contenir dans son conteneur parent.

Définir des attributs explicites width et height

Le moyen le plus simple et le plus efficace d'empêcher le CLS dû aux images et aux iframes est de toujours inclure les attributs width (largeur) et height (hauteur) directement dans le HTML. Les navigateurs modernes utilisent ces attributs pour calculer le ratio d'aspect (aspect ratio) avant le chargement de la ressource, réservant ainsi la bonne quantité d'espace.

<!-- Images : toujours inclure width et height -->
<img src="hero.jpg" width="800" height="450" alt="Image de héros">

<!-- Iframes : même principe -->
<iframe src="https://example.com/embed"
    width="560" height="315"
    title="Contenu intégré">
</iframe>

<!-- Vidéos : toujours inclure les dimensions -->
<video width="640" height="360" controls>
    <source src="video.mp4" type="video/mp4">
</video>

<style>
img, iframe, video {
    max-width: 100%;
    height: auto;
}
</style>

Utiliser la propriété CSS aspect-ratio

Pour les mises en page responsives ou lorsque les dimensions exactes en pixels ne sont pas disponibles, la propriété CSS aspect-ratio offre un moyen alternatif de réserver de l'espace. Ceci est particulièrement utile pour les conteneurs qui hébergent du contenu dynamique ou des médias intégrés.

<style>
/* Réserver de l'espace pour un conteneur vidéo 16:9 */
.video-wrapper {
    aspect-ratio: 16 / 9;
    width: 100%;
    background: #f0f0f0;
}

/* Réserver de l'espace pour une image carrée */
.avatar {
    aspect-ratio: 1 / 1;
    width: 80px;
    object-fit: cover;
}

/* Conteneur iframe responsive */
.embed-container {
    aspect-ratio: 560 / 315;
    width: 100%;
}
.embed-container iframe {
    width: 100%;
    height: 100%;
}
</style>

CLS causé par les polices web

Un Cumulative Layout Shift peut être causé par des polices web. Les polices web (web fonts) sont des polices qui ne sont pas installées sur votre ordinateur ou téléphone local mais téléchargées sur Internet. Tant que la police web n'est pas encore téléchargée, la page est généralement affichée avec une police de secours (fallback font). La taille de cette police de secours peut différer de la police finale. Dans cet exemple, la police de secours est légèrement plus petite que la police web finale. Pour plus d'informations, voir comment s'assurer que le texte reste visible pendant le chargement de la police web.

Il existe plusieurs méthodes pour corriger le changement de mise en page causé par les polices web. Elles sont basées sur deux techniques :

1. Faire en sorte que la police de secours corresponde plus étroitement à la police web. La manière la plus efficace consiste à remplacer (override) les descripteurs @font-face.

2. Accélérer les polices web. Cela les rendra disponibles pour le navigateur avant qu'il ne commence le rendu. Une façon courante de le faire est d'auto-héberger vos polices web et de précharger (preload) vos polices web critiques.

Faire correspondre la police de secours avec des remplacements de métriques

La technique la plus efficace pour éliminer le CLS dû aux polices web consiste à créer une définition de police de secours (fallback) qui correspond étroitement aux dimensions de votre police web. En utilisant les descripteurs size-adjust, ascent-override, descent-override et line-gap-override, vous pouvez faire en sorte que la police de secours occupe un espace presque identique. Combiné avec font-display: swap, cela garantit que le texte est visible immédiatement avec un changement de mise en page minimal lorsque la police web se charge.

<style>
/* Définir une police de secours correspondante */
@font-face {
    font-family: 'My Font Fallback';
    src: local('Arial');
    size-adjust: 105.2%;
    ascent-override: 93%;
    descent-override: 24%;
    line-gap-override: 0%;
}

/* Utiliser la police web avec la solution de secours correspondante */
@font-face {
    font-family: 'My Font';
    src: url('/fonts/myfont.woff2') format('woff2');
    font-display: swap;
}

body {
    font-family: 'My Font', 'My Font Fallback', sans-serif;
}
</style>

<!-- Précharger la police web critique pour un chargement plus rapide -->
<link rel="preload" href="/fonts/myfont.woff2"
    as="font" type="font/woff2" crossorigin>

Des outils comme le Fallback Font Generator peuvent calculer automatiquement les valeurs de remplacement (override) correctes pour votre paire de polices spécifique. Pour Google Fonts en particulier, l'auto-hébergement de vos polices vous donne un contrôle total sur les déclarations font-face et la stratégie de préchargement (preloading).

CLS causé par les animations CSS

Les animations et transitions CSS peuvent déclencher des changements de mise en page inattendus lorsqu'elles animent des propriétés qui affectent la disposition des éléments environnants. Des propriétés telles que top, left, width, height, margin et padding forcent le navigateur à recalculer la mise en page de l'ensemble de la page, ce qui se traduit par du CLS. Pour une explication détaillée, voir comment corriger un changement de mise en page causé par des transitions CSS.

La solution consiste à utiliser des propriétés CSS composées (composited) comme transform et opacity pour les animations. Ces propriétés sont gérées par le compositeur du GPU et ne déclenchent pas de recalculs de mise en page (layout recalculations), elles ne produisent donc aucun CLS.

<style>
/* MAUVAIS : Animer top/left provoque des layout shifts */
.slide-in-bad {
    position: relative;
    animation: slide-bad 0.3s ease-out;
}
@keyframes slide-bad {
    from { top: -50px; opacity: 0; }
    to   { top: 0; opacity: 1; }
}

/* BON : Animer transform NE provoque PAS de layout shifts */
.slide-in-good {
    animation: slide-good 0.3s ease-out;
}
@keyframes slide-good {
    from { transform: translateY(-50px); opacity: 0; }
    to   { transform: translateY(0); opacity: 1; }
}
</style>

Selon le Web Almanac du HTTP Archive, 39 % des pages mobiles et 42 % des pages de bureau ont des animations non composées (non-composited animations) qui contribuent au CLS. Vérifiez toujours vos animations pour vous assurer qu'elles n'utilisent que transform et opacity plutôt que des propriétés déclenchant des modifications de la mise en page.

Utiliser le confinement CSS (CSS containment) pour isoler les changements de mise en page

La propriété CSS contain indique au navigateur que le contenu d'un élément est indépendant du reste de la page. Cela limite la portée des recalculs de mise en page et peut empêcher les changements de mise en page de se propager aux éléments environnants.

<style>
/* Isoler les conteneurs de publicité du reste de la page */
.ad-slot {
    contain: layout style;
    min-height: 250px;
}

/* Pour le contenu hors écran, utiliser content-visibility */
.below-fold-section {
    content-visibility: auto;
    contain-intrinsic-size: 0 500px;
}
</style>

La déclaration contain: layout garantit que toute modification de taille à l'intérieur de l'élément ne déclenchera pas de recalculs de mise en page pour les éléments situés à l'extérieur. La propriété content-visibility: auto va plus loin en permettant au navigateur d'ignorer complètement le rendu du contenu hors écran (off-screen), contain-intrinsic-size fournissant une taille estimée pour éviter les changements de mise en page lorsque le contenu défile dans la vue.

Problèmes de CLS causés par des interactions utilisateur lentes

Dans l'exemple ci-dessous, le bouton "charger plus" déclenche clairement un changement de mise en page. Cependant, le changement de mise en page ne sera pas ajouté aux métriques CLS. C'est parce que ce changement de mise en page est intentionnel.

Le navigateur le sait car les éléments désormais visibles ont un attribut appelé "hadRecentInput". Lorsque cet attribut est défini sur true ET que le changement de mise en page se produit dans les 500 ms suivant l'événement de saisie (le clic sur le bouton), le changement de mise en page ne sera pas signalé par le navigateur.

Assurez-vous que les interactions de l'utilisateur se terminent dans les 500 ms. Si une interaction prend plus de temps que cela, tout changement de mise en page résultant comptera dans le score CLS. Ceci est particulièrement pertinent pour les requêtes AJAX qui injectent du nouveau contenu. Pour des conseils sur l'optimisation des éléments interactifs, voir comment créer un widget de chat avec des Core Web Vitals parfaits.

Problèmes de CLS causés par AJAX et le contenu injecté dynamiquement

AJAX permet de mettre à jour les pages web de manière asynchrone en échangeant des données avec un serveur web en arrière-plan. L'injection de nouveau contenu dans n'importe quelle page web pourrait entraîner un changement de mise en page massif. C'est pourquoi il est sage de réserver l'espace qui est utilisé pour le nouveau contenu. Vous ne connaissez pas la hauteur du nouveau contenu à l'avance, mais ce que vous pouvez faire, c'est une estimation éclairée.

Par exemple, si le contenu AJAX moyen occupe 50 % de l'écran, il est judicieux de réserver ces 50 %. Lorsque le nouveau contenu finit par occuper 40 ou 60 % de l'écran, le CLS (50 % moins 40 % = 10 % de fraction de distance) est toujours beaucoup plus faible qu'une fraction de distance de 50 %.

Voici un exemple de la façon de procéder :

<style>
   #ajax { height: 400px; }
   #ajax.loaded { height: auto; }
</style>
<script>
   fetch('/ajax-content')
   .then(response => response.json())
   .then(result => {
      let el = document.getElementById('ajax');
      el.innerHTML = result.html;
      el.classList.add('loaded');
   })
</script>

CLS après le chargement (post-load) : contenu dynamique et éléments à chargement tardif

Les changements de mise en page ne se produisent pas seulement lors du chargement initial de la page. Le CLS post-chargement est causé par du contenu qui apparaît ou change de taille après que la page a déjà été rendue. Les causes fréquentes incluent :

• Publicités à chargement tardif : Les réseaux publicitaires injectent souvent du contenu plusieurs secondes après le chargement de la page. Si l'emplacement publicitaire (ad slot) n'a pas d'espace réservé, l'annonce pousse tout le contenu environnant vers le bas.
• Bannières de consentement aux cookies : Les bannières qui poussent le contenu de la page vers le bas au lieu de se superposer (overlay) provoquent un CLS important. Utilisez un modèle de superposition (position: fixed) ou réservez de l'espace en haut de la page.
• Contenu chargé en différé (lazy-loaded) au-dessus de la ligne de flottaison : Contenu chargé via l'Intersection Observer qui était initialement masqué mais qui apparaît dans le viewport sans espace réservé.
• Scripts de test A/B : Les outils de test qui modifient le DOM après le rendu initial peuvent provoquer des décalages inattendus. Exécutez les modifications de test A/B côté serveur ou dans le HTML initial lorsque c'est possible.
• Implémentations de défilement infini (infinite scroll) : Le nouveau contenu ajouté au bas d'une liste peut provoquer des décalages s'il modifie la disposition des éléments existants. Assurez-vous que le nouveau contenu n'est ajouté qu'en dessous de la position de défilement actuelle.

Le modèle de fenêtre de session (décrit ci-dessus) signifie que même les changements de mise en page post-chargement comptent dans le CLS s'ils se produisent pendant la pire session. Surveillez vos données d'attribution CLS dans CoreDash pour identifier quels éléments se décalent après le chargement.

Résoudre les problèmes de CLS causés par les publicités

Les publicités se chargeront souvent beaucoup plus tard sur la page. Cela rend les Cumulative Layout Shifts causés par les publicités particulièrement ennuyeux. Lorsque plusieurs annonces se chargent dans le viewport visible, la page ne restera tout simplement pas immobile. Pour y remédier, réservez l'espace pour les publicités, en particulier les publicités dans le viewport visible.

<style>
/* Réserver de l'espace pour l'annonce mobile rectangulaire */
.ad {
    min-height: 250px;
    background: #dedede;
    contain: layout style;
}
/* Réserver de l'espace pour l'annonce de bannière de bureau */
@media only screen and (min-width: 600px) {
    .ad { min-height: 90px; }
}
</style>

Étude de cas : Rakuten 24 et l'impact commercial du CLS

Rakuten 24, une importante plateforme de commerce électronique japonaise, a mené une étude détaillée sur l'impact du Cumulative Layout Shift sur ses mesures commerciales. En réduisant le CLS sur ses pages de produits et de catégories, Rakuten 24 a obtenu des résultats remarquables :

• Augmentation de 53,37 % des revenus par visiteur pour les utilisateurs ayant bénéficié d'un faible CLS par rapport à ceux ayant un CLS élevé.
• Augmentation de 33,13 % du taux de conversion pour la même cohorte ayant vu son CLS s'améliorer.
• Diminution de 15,20 % du taux de rebond (bounce rate) parmi les visiteurs bénéficiant d'expériences de page stables.

Ces chiffres démontrent que le CLS n'est pas simplement une métrique technique. L'instabilité visuelle coûte directement des revenus aux entreprises en frustrant les utilisateurs lors de leur navigation et de leur parcours d'achat. Lorsque des éléments se déplacent de manière inattendue, les utilisateurs perdent confiance, cliquent à côté et abandonnent leurs sessions. L'étude de Rakuten 24 confirme qu'investir dans l'optimisation du CLS a un retour sur investissement mesurable, en particulier pour les sites de commerce électronique où chaque interaction compte.

Ce que montrent les données CLS dans le monde réel

Les données de CoreDash montrent que le CLS est le Core Web Vital le plus performant, avec 92,8 % des chargements de page sur corewebvitals.io obtenant un score "bon" et pratiquement aucun écart d'appareil (device gap) entre mobile et ordinateur (desktop). Le bureau (92,8 % de bons) et le mobile (92,7 % de bons) obtiennent des scores CLS presque parfaits, avec un p75 de 0 sur les deux types d'appareils.

Cela contraste avec des métriques comme le LCP et l'INP, où les performances sur mobile sont nettement pires que sur ordinateur. Le CLS est exceptionnellement meilleur sur mobile que sur bureau sur l'ensemble du web, ce qui est l'inverse de tous les autres Core Web Vitals.

À l'échelle mondiale, selon le Web Almanac 2025, le tableau est moins optimiste :

• 72 % des sites web obtiennent globalement de bons scores CLS, tandis que 11 % ont un mauvais CLS.
• 66 % des pages mobiles ont au moins une image sans dimensions (en baisse par rapport aux 72 % en 2022, mais toujours un contributeur majeur au CLS).
• 39 % des pages mobiles ont des animations non composées (non-composited) qui contribuent au CLS.
• Seulement 11 % des pages préchargent des polices web, ce qui signifie que la grande majorité des sites sont vulnérables aux changements de mise en page dus à la permutation des polices (font-swap).

Le CLS a montré une amélioration régulière d'une année sur l'autre à l'échelle mondiale, mais les données révèlent que les images sans dimensions et les animations non composées restent les deux causes les plus courantes. Régler ces deux problèmes à eux seuls éliminerait les changements de mise en page pour une grande partie du web.

Foire aux questions sur le CLS

Guides connexes

Explorez ces guides détaillés pour des techniques d'optimisation spécifiques au CLS :

• Corriger le changement de mise en page causé par les transitions CSS : apprenez à identifier et à remplacer les animations CSS déclenchant des modifications de la mise en page (layout-triggering) par des alternatives composées.
• Corriger le changement de mise en page causé par le redimensionnement automatique des images : une présentation complète pour l'ajout de dimensions appropriées aux images et aux conteneurs responsifs.
• Auto-héberger Google Fonts : réduisez le CLS lié au chargement des polices en hébergeant vous-même les polices avec des stratégies d'affichage (font-display) et de préchargement (preloading) appropriées.
• Assurer la visibilité du texte pendant le chargement des polices web : configurez font-display et les remplacements (overrides) des métriques de police pour éliminer les changements de mise en page liés à la permutation des polices.
• Créer un widget de chat avec des Core Web Vitals parfaits : une étude de cas sur la mise en œuvre de widgets tiers sans introduire de régressions CLS, INP ou LCP.

Pour un aperçu complet de toutes les métriques et stratégies d'optimisation des Core Web Vitals, visitez l'Aperçu des Core Web Vitals ou utilisez la Checklist Ultime des Core Web Vitals pour auditer votre site.