# Core Web Vitals échoués : identifier et résoudre les problèmes de CLS > URL: https://4eck-media.de/fr/blog/12156/ > Language: fr > Description: Comment nous avons corrigé des problèmes de CLS sur plus de 100 000 pages de notre portail et repassé les Core Web Vitals. --- Pendant près de trois mois, nous avons été confrontés à des **problèmes de CLS** sur notre portail TutKit.com. Nous avons consacré beaucoup de temps et d’énergie à **identifier et résoudre les Cumulative Layout Shifts**. Dans ce retour d’expérience, je souhaite te donner un aperçu de la façon dont nous avons procédé. ## Introduction : pourquoi le CLS est un problème Le Cumulative Layout Shift (CLS) est l’une des trois métriques centrales des **Core Web Vitals** de Google. Ces métriques sont déterminantes pour évaluer la convivialité des sites et influencent le classement dans les résultats de recherche. Le CLS mesure la stabilité visuelle d’une page et indique combien de fois des décalages de mise en page inattendus surviennent pendant le chargement. ### Que signifie concrètement le CLS ? Quand des éléments d’un site changent soudainement de position pendant le chargement, cela peut être frustrant pour les utilisateurs. Tu connais peut-être la situation : un contenu de page saute parce qu’une annonce s’affiche d’un coup. Ou un bouton qui s’apprête à être cliqué change soudain de position et active à la place un autre lien. De tels décalages inattendus sont gênants et nuisent à l’expérience utilisateur. Pour éviter ces problèmes et **optimiser correctement** le site, il faut garder un œil sur la valeur CLS et l’améliorer de manière ciblée. La valeur CLS est calculée à partir de la taille de l’élément déplacé et de la distance qu’il parcourt dans le viewport. Google considère une valeur CLS inférieure à 0,1 comme bonne, entre 0,1 et 0,25 comme à améliorer, et au-delà comme mauvaise. Voici un extrait de notre Search Console. En jaune, les valeurs entre 0,1 et 0,25 ; en rouge, les pages qui dépassent ce seuil. Les causes classiques de valeurs CLS élevées sur la plupart des sites sont des images trop grandes, dans des formats dépassés (JPG/PNG) et/ou sans dimensions fixes. Sans hauteur et largeur définies, les images peuvent provoquer des décalages, car le navigateur réserve de l’espace pendant le chargement en fonction de leur ratio (largeur/hauteur). Autres causes : des contenus dynamiques comme les annonces, pop-ups ou contenus embarqués qui apparaissent en cours de chargement génèrent un saut cumulé. Le rendu lent des polices peut aussi affecter la mise en page si une police système est d’abord chargée puis remplacée par une webfont. Le texte peut se décaler — par exemple, un paragraphe qui passe de six à sept lignes décale le contenu situé en dessous. Comme chaque police a une largeur de glyphes différente, un changement de police peut entraîner des sauts de ligne. Bien que nous ayons d’excellents scores PageSpeed sur TutKit.com, nous ne validions tout simplement plus les Core Web Vitals pour la plupart des pages depuis mi-décembre 2024. Cela paraissait fou : score PageSpeed mobile de 95 ou 97, mais Core Web Vitals non validés. Le problème, c’était le CLS. Comme le CLS prend en compte **non seulement le premier viewport, mais aussi les interactions à l’intérieur de la page**, la cause était difficile à identifier. Dans ce billet, nous partageons notre expérience : comment nous avons identifié et résolu ces problèmes avec succès. ## Analyse des causes : pourquoi le CLS est-il apparu chez nous ? Ces dernières semaines, plusieurs experts SEO que je suis sur LinkedIn ont rapporté des alertes CLS soudaines, signalées dans la Google Search Console depuis décembre 2024 et janvier 2025. Cela pourrait être lié au Core Update de décembre 2024 que Google a déployé mi-décembre. Des sites qui auparavant affichaient des valeurs CLS au vert ont soudain été classés comme problématiques — comme les nôtres. Une cause possible est un ajustement du système d’évaluation des signaux utilisateurs par Google. Il y a des indices que les interactions à l’intérieur des pages comptent davantage dans l’évaluation. Les valeurs Core Web Vitals peuvent ainsi se détériorer même sans modification technique. Ce qui passait auparavant pose désormais problème. Chez nous, en raison de la diversité des types de pages, sections et fonctionnalités, plusieurs zones ont provoqué les problèmes de CLS : - Google AdSense : le chargement différé des annonces provoquait des décalages. - Tables des matières : le chargement dynamique via JavaScript provoquait des sauts de mise en page. - Images sans attributs width/height : des images apparaissant subitement modifiaient la structure de la page. - Webfonts : le chargement tardif des polices entraînait des sauts de ligne inattendus. - Modules FAQ : les questions ouvertes par défaut provoquaient des décalages imprévisibles. - Sliders et onglets accordéon : les contenus n’étaient rendus qu’après coup et se décalaient. - Google Reviews : les contenus chargés depuis l’extérieur influaient sur la structure de la page. Ces problèmes n’étaient pas faciles à détecter, car les tests de laboratoire comme Lighthouse et PageSpeed Insights n’affichaient pas de valeurs CLS suspectes. ## Le chemin difficile pour détecter des décalages de mise en page cachés Pourquoi les problèmes de CLS étaient-ils si difficiles à identifier ? 1. Lighthouse et PageSpeed Insights affichaient des valeurs optimales, car ils ne mesurent que le premier chargement et ne simulent pas de scénarios utilisateurs réels. Ils testent la page dans un environnement de laboratoire avec des réseaux stables et des conditions de chargement idéales. Beaucoup de décalages survenant lors d’interactions réelles ne sont donc pas détectés. 2. La Google Search Console signalait le CLS comme un problème, car elle analyse de vraies données utilisateurs (Field Data). Ces données proviennent d’utilisateurs réels avec des appareils, des réseaux et des comportements variés, et révèlent des problèmes qui n’apparaissent pas en laboratoire. 3. L’API CrUX et BigQuery ne fournissaient pas de données en temps réel, mais des valeurs agrégées sur les 28 derniers jours. Les améliorations ne sont donc visibles qu’avec retard, et une évaluation immédiate n’est pas possible. Dans la Search Console, les types d’URL ayant des problèmes de CLS étaient indiqués, ce qui constituait un premier bon indice du non-respect des Core Web Vitals, même si le contrôle classique via PageSpeed Insights ou Lighthouse ne révélait pas de valeurs CLS trop élevées. Nous devions trouver notre propre méthode pour rendre les erreurs CLS visibles. ### Analyse avec Chrome DevTools → onglet Performance L’ensemble du site a été rechargé section par section et type de page par type de page, à la recherche de décalages. Nous n’avons pas utilisé Lighthouse ni PageSpeed pour cela, mais l’onglet Performance des Chrome DevTools. Les éléments particulièrement problématiques ont été marqués et testés plusieurs fois avec différents paramètres de throttling. En réduisant artificiellement la vitesse Internet à « Slow 4G », nous pouvions mieux simuler les retards de chargement des éléments individuels et reproduire les décalages. Voici une capture où un layout shift est devenu visible avec un throttling réseau et CPU : Nous avons consigné tous les problèmes CLS et avons ainsi pu identifier les composants problématiques du site. Nous n’avons pas seulement testé les types de pages signalés par la Search Console : nous avons inclus tous les types de pages et toutes les sections, afin de résoudre le problème durablement, même si les exigences pour les exploitants de sites venaient à se durcir à l’avenir. Tous les tests simples et rapides peuvent être effectués avec **DevTools → Performance** et un rechargement de la page via F5 à différentes positions, ou par un test plus intensif via un enregistrement Performance. Certains décalages sont presque impossibles à remarquer lors de tests ordinaires. Il peut arriver que le type de page A ne présente aucun décalage et que le type de page B non plus, mais que la navigation entre les deux pages (avant/arrière) fasse apparaître le problème CLS qui n’était pas identifiable lors d’un contrôle isolé des pages. Teste donc toujours des parcours utilisateurs complets, et pas seulement des pages isolées, pour identifier des décalages cachés. L’analyse du comportement utilisateur réel révèle souvent des erreurs que les tests standardisés ne voient pas. On peut ainsi détecter en amont les problèmes potentiels et maintenir une performance stable. ### Tests avec différentes résolutions d’écran Par défaut, Lighthouse et PageSpeed Insights testent avec une taille d’écran fixe. Dans la Google Search Console, l’indication des types d’URL problématiques nous a montré que certains problèmes CLS n’apparaissaient que pour certains groupes d’utilisateurs, par ex. des visiteurs venant de Suède avec certains appareils mobiles. Nous avons en plus mené des tests mobiles avec différentes résolutions pour identifier les problèmes spécifiques qui surgissent en conditions réelles. Pour cela, nous avons exporté les données de Google Analytics et réalisé les tests sur 200 résolutions mobiles différentes, afin de détecter des problèmes uniquement visibles dans une résolution spécifique. Pour donner une idée de l’étendue des résolutions utilisées : sur une période de quatre semaines, l’export Google Analytics indiquait 4 083 résolutions différentes pour desktop, tablette et mobile. Nous les avons triées par nombre d’utilisateurs. Même au rang 200, nous avions encore 88 utilisateurs venus chez nous avec la résolution 412×778 sur cette même période. Google a récemment ajouté un outil qui permet d’ajuster le throttling de ton PC ou notebook aux différents appareils mobiles. Cette démarche systématique nous a aidés à identifier les zones précises de problème et à implémenter des correctifs ciblés. Il est important de comprendre que certains problèmes CLS ne surviennent que dans des conditions spécifiques, mais qu’ils peuvent discréditer l’évaluation globale de la page. ## Nos solutions pour les problèmes CLS identifiés Après avoir déterminé les causes des décalages, nous avons mis en œuvre des mesures ciblées pour y remédier : ### Définition des dimensions des images Problème : des images sans dimensions de largeur et de hauteur définies provoquaient des changements de mise en page inattendus. Tu vois ici, par exemple, un résultat PageSpeed mobile à 92 en performance sans problème CLS apparent. Avec nos tests DevTools dans l’onglet Performance, nous avons identifié le problème dans le comportement utilisateur réel. La valeur CLS affichait 0,22… nettement trop élevée. Solution : sur une partie des images, l’indication width-height manquait encore. Nous avons créé une requête pour toutes les images du portail et avons ajouté cette indication automatiquement dans le code. Le frontend sait désormais, au chargement, la taille de chaque image et réserve immédiatement l’espace nécessaire selon le bon ratio. Aucun saut au chargement de l’image. Joli effet de bord : la valeur PageSpeed mobile s’est encore améliorée. Voici la même URL après le merge de notre fix CLS, dans le même test avec PageSpeed Insights et les DevTools : ### Optimisation des webfonts Problème : le chargement tardif des polices provoquait des sauts de ligne et des décalages. Chez nous, le problème particulier était que la police système par défaut (ici Arial) était d’abord chargée, puis remplacée par la police Noto en webfont. Nous utilisons sur notre portail la webfont Noto. Google l’a fait concevoir pour supporter tous les systèmes d’écriture existants, des caractères latins au cyrillique, en passant par l’arabe, jusqu’à des systèmes plus exotiques comme le khmer ou le tamoul. C’est précisément ce qui rend cette police idéale pour une plateforme multilingue comme TutKit.com, où des contenus sont proposés aux publics les plus variés. Le grand avantage de Noto est sa large prise en charge linguistique — c’est aussi devenu un défi technique. Couvrant autant de systèmes d’écriture, la famille de polices est extrêmement volumineuse. Par défaut, on charge souvent plus de caractères que ce qui est réellement nécessaire. Pour les utilisateurs mobiles en particulier, cela peut allonger les temps de chargement et nuire à l’expérience utilisateur et au SEO. Solution : nous avons vérifié quelles graisses (de 100 à 900) étaient chargées et avons aligné leur nécessité avec l’interface utilisateur, ce qui nous a permis de réduire les graisses utilisées. D’autre part, les fichiers de polices ont été réduits aux seuls glyphes nécessaires. Seules deux polices sont désormais chargées, pour une taille totale de 105 ko. Pour les différentes langues, nous n’utilisons plus non plus les fichiers de police complets, mais seulement des subsets. À l’ouverture de notre sélecteur de langues, les caractères spéciaux scandinaves et slaves, ainsi que les jeux pour le grec, le cyrillique, le japonais et le coréen, sont chargés. Les subsets sont, à deux exceptions près, très petits en taille. Cela nous a permis de réduire les temps de chargement et de garantir que les textes s’affichent correctement dès le début, sans changement visible de la police système vers la webfont. ### Autres ajustements pour corriger le CLS Nous nous sommes en parallèle attaqués aux autres problèmes CLS identifiés. Notamment : **Optimisation Google AdSense** Problème : le chargement différé des annonces provoquait des décalages de mise en page. Solution : adapter les paramètres AdSense pour utiliser des emplacements statiques qui réservent dès le chargement l’espace nécessaire. **Passage des tables des matières de JavaScript à PHP** Problème : le chargement dynamique via JavaScript provoquait des sauts de mise en page. Solution : rendre les tables des matières des articles de blog côté serveur en PHP, pour qu’elles soient disponibles dès le chargement de la page et ne provoquent pas de décalages a posteriori. **Adaptation des modules FAQ** Problème : les questions ouvertes par défaut provoquaient des décalages de mise en page imprévisibles. Solution : retirer la fonction d’ouverture par défaut des questions, afin d’éviter les changements de mise en page inattendus. **Optimisation des éléments slider et accordéon** Problème : les contenus n’étaient rendus qu’après coup, ce qui provoquait des décalages de mise en page. Solution : précharger les éléments et fixer des hauteurs définies pour les sliders, afin de garantir une mise en page stable durant le chargement. **Amélioration de l’intégration des avis Google** Problème : les contenus chargés depuis l’extérieur influaient sur la structure de la page et provoquaient des décalages. Solution : utiliser le lazy loading avec des placeholders fixes, pour s’assurer que l’espace nécessaire est réservé dès le chargement de la page. Comme je n’ai pas documenté chaque fix par une image, voici un extrait de JIRA, notre outil de gestion de projet, où sont filtrées les tâches liées au CLS. Au début, nous créions un ticket pour chaque anomalie et lancions la validation dans la Search Console après chaque merge. Mais cela n’a pas suffi : d’un côté, la validation échouait ; de l’autre, de nouveaux problèmes étaient identifiés à l’étape suivante. Nous avons donc fini par regrouper les problèmes CLS dans trois tickets (« List of CLS problems »), jusqu’à ce que tous soient corrigés. Il y a finalement eu plus de problèmes qu’attendu. Le nombre de tickets et l’éventail de numéros montrent à quel point les problèmes CLS nous ont occupés. Là où le portail d’actualités [Heise a pu corriger ses problèmes CLS — causés par le bandeau cookies de consent — avec une seule ligne de code](https://4eck-media.de/fr/https://www.heise.de/blog/Wie-eine-Zeile-CSS-den-Cumulative-Layout-Shift-CLS-deutlich-verbessert-9831725.html), il nous a fallu un peu plus de lignes à traiter. Après la mise en œuvre des dernières mesures, nous avons constaté que les améliorations n’étaient pas immédiatement visibles dans la Google Search Console. Le processus de validation était annoncé pour durer jusqu’à 28 jours. Cela tient au fait que la Search Console se base sur des données utilisateurs réelles, agrégées sur 28 jours. Il peut donc s’écouler jusqu’à quatre semaines avant que les effets des changements soient pleinement reflétés. Dans notre cas, les premières améliorations sont apparues au bout de neuf jours. ## As-tu fait tes devoirs ? L’un des experts SEO qui partageait sur LinkedIn ses problèmes de CLS a exprimé sa reconnaissance envers toutes les équipes qui réussissent à valider les Core Web Vitals sur leurs projets : *« J’admire toutes les équipes qui valident les Core Web Vitals ! Parce que moi-même, je n’y arrive pas… »* Cette reconnaissance est justifiée, car satisfaire aux Core Web Vitals sur des sites volumineux suppose un fort accent sur la technique, le PageSpeed et l’expérience utilisateur. En racontant ici comment nous avons résolu nos problèmes de CLS, on pourrait, vu la quantité de zones identifiées, avoir l’impression que beaucoup d’aspects techniques étaient en piteux état chez nous. Ce n’est absolument pas le cas. Avec le déploiement du multilinguisme, nous avons été confrontés à de nombreux nouveaux défis et avons donc consacré plusieurs mois à des refactorings CSS et JS, à la [réduction des requêtes en base de données](https://4eck-media.de/fr/https://4eck-media.de/fr/blog/optimisation-efficace-de-la-base-de-donnees-reduction-des-requetes-de-base-de-donnees/) et à d’autres améliorations PageSpeed comme l’[optimisation du TTFB](https://4eck-media.de/fr/https://4eck-media.de/fr/blog/ameliorer-le-ttfb-comment-grace-au-route-caching-nous-avons-reduit-notre-temps-de-premiere-reponse-serveur-de-88/). Aujourd’hui, PageSpeed Insights affiche un score PageSpeed mobile de 95 pour notre page d’accueil. Le rapport ne contient plus que quelques recommandations qui suggèrent encore des marges d’amélioration. Voici par exemple une sous-page qui présentait encore récemment des problèmes CLS. Regarde le petit nombre de recommandations émises par PageSpeed Insights. Le deuxième point concernant les éléments d’image ne porte même pas sur l’image principale de la page, mais sur deux flèches qui servent d’éléments de navigation. (Heureusement que j’ai écrit ce billet : j’ai déjà ouvert un ticket pour ajouter aussi ces indications, afin que le frontend sache encore plus vite quelle taille prévoir.) Malgré cette base déjà saine de TutKit.com, des problèmes CLS sont apparus. Notre chance était d’avoir, pour 2024, accompli en bonne partie nos devoirs en matière de standards d’optimisation PageSpeed. Pour l’[expert SEO de LinkedIn qui a honnêtement reconnu ses propres problèmes avec les Core Web Vitals](https://4eck-media.de/fr/https://www.linkedin.com/posts/fabianjaeckert_corewebvitals-cls-googlesearchconsole-activity-7282802018937462784-eM_X/), c’est différent. J’ai inspecté son site. Rien que les fichiers de polices chargés au démarrage sont immenses. Par rapport à TutKit.com, on charge ici un multiple de fichiers et de tailles, alors que la page d’accueil est plus petite que la nôtre. Voici : Nous avons effectivement constaté que les problèmes de PageSpeed et de CLS vont souvent de pair avec une politique de polices sous-optimale. Quand la page est testée avec PageSpeed Insights, les valeurs sont désastreuses. Les recommandations de Google sont en conséquence très longues (à droite sur l’image) : Sur ce site, du point de vue performance, beaucoup de choses ne vont pas. Lors des tests que j’ai menés par échantillonnage selon notre méthode, plusieurs zones des sous-pages présentaient des problèmes CLS. Pour finir, un bandeau a surgi, ajoutant un layout shift supplémentaire. Même si des développeurs se penchent uniquement sur les problèmes CLS, ils ne pourront pas faire l’impasse sur les standards des sites modernes : résoudre les problèmes de polices, passer à des [formats d’image modernes comme AVIF](https://4eck-media.de/fr/https://4eck-media.de/fr/blog/avif-le-meilleur-format-de-fichier-pour-le-seo-des-images-et-le-pagespeed/), refactoriser les fichiers CSS et JS, charger les images du bas de page en lazy loading, etc. Sans ces optimisations de fond, un fix CLS rapide ne suffira pas, ou ne durera pas. Combien de recommandations PageSpeed Insights te donne-t-il encore ? As-tu déjà fait tes devoirs ? ## Aparté : PageSpeed 100 et pourtant Core Web Vitals non validés Tout le monde, en Allemagne, connaît la Karrierebibel et ses bons conseils sur la candidature et la vie professionnelle. L’an dernier, un relaunch y a été mené — qui, selon moi, visait aussi à réaliser des optimisations techniques. Et de fait, je trouve des valeurs PageSpeed exceptionnelles : la page d’accueil affiche 99 sur mobile et 100 sur desktop. Chapeau. Du point de vue design, en revanche, je ne m’habitue toujours pas à la police maison : Arial. C’est non. Cela me rappelle directement le courrier administratif. Mais la Karrierebibel y gagne un avantage technique. Aucun fichier de police n’est chargé. Le site indique simplement dans le code source que la police est Arial. Comme celle-ci est de toute façon préinstallée sur chaque système en Allemagne, le site ne perd pas de temps à charger des fichiers de polices. Il évite ainsi directement l’une des causes de problèmes PageSpeed : le chargement des polices. Mais : PageSpeed et CLS doivent toujours être considérés globalement. C’est pourquoi il est important d’observer aussi de manière systématique les différentes résolutions. Le **tableau CrUX** pour desktop affiche beaucoup de problèmes CLS sur les vues desktop. Si je teste une sous-page avec PageSpeed Insights, j’obtiens un PageSpeed de 100 pour desktop, mais les Core Web Vitals ne sont pas validés. C’est possible, comme tu peux le constater dans cet exemple. Utilise donc plusieurs outils de contrôle pour repérer les erreurs qui font que tu n’atteins pas certaines métriques importantes. Car en ne validant pas les Core Web Vitals, tu rates aussi un important signal de classement pour Google. Il y a peut-être un lien lorsque certains **signaux** et métriques ne sont pas respectés et que la visibilité en ligne chute sur Google. Sur l’image, on voit qu’en l’espace d’un an, la visibilité est passée de plus de 64 à la trentaine. Les raisons ne tiennent sûrement pas qu’aux Core Web Vitals, mais il vaut toujours mieux avoir fait ses devoirs pleinement. Les conditions extérieures, nous ne pouvons pas les influencer ; ce qui se passe sur notre propre site, si. ## Conclusion : nos enseignements Considérer le CLS de manière isolée est possible si des optimisations PageSpeed ont déjà été réalisées en amont. Pourtant, l’impact reste énorme si les problèmes CLS empêchent de valider les Core Web Vitals. L’impact que peut avoir un échec sur les Core Web Vitals devient clair en regardant ce qui suit. Dans le tableau CrUX de notre portail, on voit clairement comment, depuis octobre 2024, les problèmes de CLS sur les usages mobiles s’accumulaient. L’image n’indique que les valeurs CLS pour les appareils mobiles. Voici la répartition par téléphone, desktop et tablette, c’est-à-dire la part des usages sur TutKit.com : Il ne s’agit pas d’avoir gagné des utilisateurs desktop. Non — nous avons simplement perdu une partie de nos utilisateurs mobiles. Au quotidien, ce sont des clics à cinq chiffres. Cela fait honnêtement mal. Nous avons désormais enfin résolu les problèmes CWV et la Search Console affiche exclusivement de bonnes valeurs pour les URL : Nous avons donc très hâte de voir si les clics se rétablissent et si nous pourrons enregistrer un retour des usages mobiles dans la Search Console. Je publierai à ce sujet une mise à jour de ce billet dans quelques mois. Les changements récents montrent que l’**optimisation CLS** reste un travail exigeant. Nos principaux enseignements : - Prendre en compte les problèmes CLS dès la phase de développement - Les données de laboratoire ne suffisent pas — les vraies données utilisateurs sont décisives - Le CLS a un impact énorme sur les Core Web Vitals en tant que signal de classement, et donc sur la visibilité chez Google À long terme, une approche systématique aide à minimiser durablement les problèmes CLS et à **garantir une expérience utilisateur optimale** — car cela aussi fait partie du SEO. Si tu rencontres des problèmes de CLS en particulier ou de performance en général, n’hésite pas à nous contacter. Nous avons développé une compréhension fine du sujet et pourrons sûrement t’aider.