Core Web Vitals : LCP, INP et CLS — comprendre et améliorer les 3 signaux Google

Vos performances Google se jouent souvent sur trois signaux. LCP, INP et CLS résument la vitesse perçue, la réactivité et la stabilité visuelle d’une page. (web.dev)

L’enjeu n’est pas d’obtenir un joli score de laboratoire, mais d’offrir une expérience fluide au 75e percentile des visites réelles, sur mobile comme sur desktop. C’est ce qui explique pourquoi Google s’appuie sur des seuils précis et sur des données terrain.

Pour apprendre à lire un rapport sans vous tromper, le guide PageSpeed Insights : comment lire et corriger votre score étape par étape peut servir de point de départ. (developers.google.com)

Core Web Vitals : ce que Google mesure vraiment

Les Core Web Vitals sont trois métriques de terrain, pas trois scores abstraits. Google s’en sert pour juger si l’expérience est bonne, à améliorer ou mauvaise, en se basant sur le 75e percentile des visites plutôt que sur des cas isolés. Depuis le 12 mars 2024, INP a remplacé FID comme métrique de réactivité.

Autrement dit, une page peut sembler correcte sur un test ponctuel et rester problématique pour une part significative des utilisateurs. C’est précisément la raison pour laquelle il faut croiser les chiffres de laboratoire avec les données terrain.

Tableau récapitulatif des 3 signaux

Google applique ces seuils au 75e percentile des visites, séparément sur mobile et desktop. L’idée est simple : une page doit être bonne pour la majorité des utilisateurs, pas seulement dans les meilleurs cas.

Pourquoi PageSpeed Insights, Lighthouse et Search Console peuvent raconter des histoires différentes

PageSpeed Insights combine des données de laboratoire et des données terrain issues de CrUX, avec une fenêtre d’observation de 28 jours. Si une URL n’a pas assez de trafic, PSI bascule au niveau de l’origine. Et pour le CLS, les écarts entre laboratoire et terrain viennent souvent des décalages qui apparaissent après le chargement initial, que Lighthouse ne voit pas toujours.

Si vos rapports semblent incohérents, ce n’est pas forcément une erreur de mesure. Le plus souvent, cela indique simplement que vous comparez un test contrôlé à une réalité plus complexe, avec des interactions, du scroll, des contenus tardifs et parfois des pages vues dans des conditions très différentes.

Quand le diagnostic se complique, la checklist d’audit technique SEO aide à relier les symptômes aux causes possibles, sans se limiter à un seul score.

Comment améliorer LCP

LCP mesure le rendu du plus gros élément visible, mais il inclut aussi des coûts annexes comme le temps de connexion, les redirections et le TTFB. En pratique, cela veut dire qu’un bon LCP dépend souvent autant du serveur et de la chaîne de chargement que de l’image héro elle-même.

Le guide officiel d’optimisation du LCP recommande de découper le problème en sous-parties : TTFB, délai de chargement de la ressource, durée de chargement, puis délai de rendu de l’élément. Cette décomposition évite de corriger le symptôme au lieu de la cause. (web.dev)

• Identifiez l’élément LCP dans PageSpeed Insights ou Chrome DevTools afin de savoir si vous traitez une image, un bloc de texte ou une vidéo.
• Rendez la ressource LCP découvrable dès le HTML initial, ou préchargez-la avec une priorité forte si elle est référencée via CSS ou JavaScript.
• Réduisez ou limitez les feuilles de style bloquantes quand elles retardent le rendu de l’élément principal.
• Optimisez l’image héro si le temps de chargement de la ressource est vraiment le goulot d’étranglement, mais gardez en tête qu’une simple compression ne suffit pas si le problème est ailleurs.

Le point de vigilance principal est là : compresser davantage une image ou changer de format peut être utile, mais cela ne réduit pas toujours le LCP final si le temps perdu se déplace simplement vers le rendu de l’élément.

Comment améliorer INP

INP mesure la latence des interactions utiles sur toute la visite, puis retient la plus lente, parfois en écartant des valeurs aberrantes. Il se décompose en délai d’entrée, durée de traitement et délai de présentation du prochain frame.

Le guide officiel d’optimisation de l’INP insiste sur un point : il faut réduire les longues tâches, fractionner le travail dans les callbacks et libérer régulièrement le thread principal pour que l’interface réponde vite.

• Réduisez l’évaluation JavaScript au chargement, car la compilation et l’exécution de gros scripts créent des tâches longues qui retardent la réponse aux clics et aux tapotements.
• Découpez les callbacks lourds en plusieurs tâches plus courtes pour éviter de bloquer le thread principal trop longtemps.
• Évitez le layout thrashing, qui force le navigateur à recalculer la mise en page de façon synchrone après une mise à jour de style.
• Limitez le rendu côté client lorsque vous affichez beaucoup de HTML, car le navigateur ne peut pas toujours rendre et répondre en même temps.
• Quand une tâche lourde ne peut pas être supprimée, déléguez-la autant que possible à un Web Worker pour sortir du thread principal. (web.dev)

Le vrai objectif n’est pas seulement de rendre la page “moins lente”, mais de faire en sorte que chaque interaction démarre vite, s’exécute vite et se reflète vite à l’écran. C’est cette chaîne complète qui fait baisser l’INP.

Comment améliorer CLS

CLS mesure la stabilité visuelle sur toute la durée de vie de la page. Les décalages inattendus comptent, même après le chargement initial, alors que certains décalages déclenchés par l’utilisateur sont exclus s’ils surviennent dans la fenêtre de 500 ms après l’interaction. (web.dev)

Le guide officiel d’optimisation du CLS rappelle que les images sans dimensions, les publicités, les embeds, les iframes et les polices web font partie des causes les plus fréquentes de décalages de mise en page.

• Définissez toujours `width` et `height` sur les images et les vidéos, ou réservez l’espace avec `aspect-ratio` pour éviter que le navigateur ne recalcule la mise en page à l’arrivée du média.
• Réservez de la place pour les publicités, widgets et iframes avec `min-height` ou `aspect-ratio`, surtout quand le contenu arrive tardivement.
• Évitez d’insérer des bannières ou des formulaires au-dessus du contenu sans réserver l’espace nécessaire dès le départ.
• Soignez les polices web avec une police de secours proche, et préchargez les polices critiques quand elles ont un impact sur le premier affichage.
• Surveillez les SPA et les contenus chargés après coup, car les décalages post-chargement sont souvent ceux que le laboratoire ne reflète pas bien.

Si votre CLS est bien meilleur dans Lighthouse que dans les données terrain, c’est souvent le signe d’un problème post-load. Dans ce cas, il faut observer le comportement réel de la page, pas seulement son chargement initial.

Prioriser les corrections sans perdre de temps

Le meilleur ordre de travail est souvent le plus simple : mesurer, isoler le signal qui passe en rouge, corriger la cause principale, puis revalider sur de vraies visites. Google insiste sur le 75e percentile justement pour éviter qu’un petit nombre de cas atypiques dicte le diagnostic global.

1. Commencez par la page qui génère le plus de trafic ou le plus de conversions, car c’est là que l’impact utilisateur est le plus visible.
2. Regardez quel signal est le plus dégradé en données terrain, pas seulement dans un test rapide.
3. Corrigez d’abord le goulot d’étranglement principal, puis retestez avant de passer au point suivant.
4. Remettez la mesure dans un contexte SEO plus large, car la vitesse n’est qu’un levier parmi d’autres.

Si vous voulez replacer ces gains dans une stratégie plus globale, le guide comment améliorer son référencement Google aide à relier la technique, le contenu et la popularité.

Et si vous travaillez aussi la structure du site, le maillage interne reste un autre levier SEO à ne pas négliger.

FAQ

Faut-il optimiser LCP, INP ou CLS en premier ?

Commencez par le signal qui vous place en zone rouge en données terrain, parce que c’est lui qui dégrade le plus l’expérience réelle. Si aucun signal n’est catastrophique, les pages très visuelles commencent souvent par LCP, les interfaces interactives par INP, et les pages riches en embeds, publicités ou contenus tardifs par CLS. Google évalue les trois métriques au 75e percentile, donc il vaut mieux traiter la cause la plus visible plutôt que multiplier les micro-correctifs.

Pourquoi mon CLS diffère-t-il entre Lighthouse et PageSpeed Insights ?

Lighthouse observe surtout le chargement initial, alors que les données terrain de CrUX couvrent toute la vie de la page. Résultat : un CLS peut sembler faible en laboratoire et plus élevé en réel si des décalages apparaissent après le chargement, par exemple au scroll, dans une SPA ou lors du chargement de contenus différés. PageSpeed Insights affiche justement ces deux lectures, ce qui permet de comprendre si le problème est lié au load CLS ou au post-load CLS.

INP a-t-il vraiment remplacé FID ?

Oui. Depuis le 12 mars 2024, INP est la métrique Core Web Vital de la réactivité et FID a été remplacé. En pratique, cela veut dire que les vieux articles qui parlent encore seulement de FID sont à lire avec prudence. Si vous auditez aujourd’hui un site, c’est bien l’INP qu’il faut suivre dans vos outils et vos priorités de correction. (web.dev)

Comment savoir si mon LCP est bloqué par l’image héro ?

La bonne approche consiste à identifier l’élément LCP dans PageSpeed Insights, Chrome DevTools ou WebPageTest, puis à regarder la chaîne de chargement réseau. Si la ressource démarre tard, le problème vient souvent d’un élément difficile à découvrir dans le HTML, d’un style bloquant ou d’un script qui retarde son apparition. Le guide d’optimisation LCP recommande aussi de précharger la ressource quand elle est découverte via CSS ou JavaScript.

Un bon score en laboratoire garantit-il une bonne expérience réelle ?

Non, pas forcément. Les outils de laboratoire servent surtout à déboguer dans un environnement contrôlé, alors que les données terrain reflètent des utilisateurs réels, des appareils différents et des connexions variables. C’est pour cela que Google s’appuie sur CrUX, sur le 75e percentile et sur des fenêtres de mesure plus larges. Un bon test de labo est utile, mais il ne suffit pas à conclure.

Et maintenant ?

Si vous voulez transformer ces principes en plan d’action, commencez par la page d’accueil de Sharp Articles, puis passez à PageSpeed Insights et à l’audit technique SEO pour prioriser les correctifs les plus rentables.