Core Web Vitals expliqués : LCP, INP et CLS

Les Core Web Vitals sont trois métriques que Google utilise pour décrire l’expérience des utilisateurs réels : le Largest Contentful Paint (LCP) pour le chargement, l’Interaction to Next Paint (INP) pour la réactivité et le Cumulative Layout Shift (CLS) pour la stabilité visuelle. Une page est validée quand au moins 75 % des visites atteignent un LCP de 2,5 secondes ou moins, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins. Ce guide explique ce que mesure chaque métrique, comment lire vos scores et quelles corrections les font généralement progresser.

Les trois métriques en un coup d’œil

Google publie des seuils fixes pour chaque métrique et classe les résultats en trois catégories. Les valeurs ci-dessous proviennent de la présentation des Core Web Vitals sur web.dev (en anglais).

Deux détails comptent plus qu’on ne le pense souvent :

• C’est le 75e percentile qui décide. Google ne regarde ni votre visite la plus rapide ni votre moyenne. Il retient la valeur atteinte ou dépassée par 75 % des chargements de pages, séparément pour le mobile et le desktop. Quelques téléphones lents sur des connexions faibles peuvent donc faire basculer une page dans la catégorie « à améliorer ».
• L’INP a remplacé le FID en mars 2024. Le First Input Delay ne mesurait que le délai avant le traitement de la première interaction. L’INP examine la latence des interactions sur toute la visite, ce qui constitue un test bien plus exigeant pour les pages chargées en JavaScript.

Données terrain et données de laboratoire

Quand vous testez une page sur corewebvitals.page, vous obtenez deux types de résultats, qui divergent souvent.

• Les données terrain (ce que vivent vos utilisateurs réels) proviennent du Chrome User Experience Report. Elles couvrent de vrais utilisateurs de Chrome sur une fenêtre glissante de 28 jours. Ce sont elles qui comptent pour l’évaluation des Core Web Vitals dans la Search Console.
• Les données de laboratoire (le score Lighthouse) correspondent à un seul chargement simulé sur un appareil bridé. Elles sont idéales pour le débogage parce qu’elles sont reproductibles, mais elles ne peuvent pas du tout mesurer l’INP, puisque personne ne clique pendant le test. Lighthouse utilise le Total Blocking Time comme approximation.

Comme les données terrain ont jusqu’à 28 jours de décalage, une correction mise en ligne aujourd’hui apparaîtra progressivement. Utilisez les tests de laboratoire pour confirmer que la modification fonctionne, puis surveillez la stabilisation des chiffres terrain. Notre guide pour mesurer correctement la vitesse d’un site détaille un test avant/après fiable.

Comment améliorer le LCP

Le LCP est souvent la plus difficile des trois métriques à valider, mais généralement la plus simple à diagnostiquer. Google le découpe en quatre parties, décrites dans l’article sur le LCP de web.dev (en anglais) :

1. Time to First Byte : le temps que met le serveur à commencer à envoyer le HTML.
2. Délai de chargement de la ressource : l’écart entre le premier octet et le moment où le navigateur commence à charger l’image LCP.
3. Durée de chargement de la ressource : le temps de téléchargement de l’image LCP elle-même.
4. Délai de rendu de l’élément : le temps entre l’arrivée de l’image et son affichage effectif.

Regardez quelle partie domine avant de modifier quoi que ce soit. Le panneau Performance des Chrome DevTools affiche l’élément LCP et la répartition de son temps.

Réponse du serveur lente

Si le TTFB seul consomme une seconde ou plus, aucun réglage d’image ne vous fera passer sous les 2,5 secondes. Les causes fréquentes sont des pages non mises en cache, générées par PHP et une base de données à chaque requête, un serveur éloigné de la plupart des visiteurs, et des extensions lentes. Le cache de pages, sur le serveur ou en edge, est la correction habituelle. Consultez le guide pour réduire le TTFB pour la liste complète.

L’image LCP est découverte tardivement

Les navigateurs trouvent les images en analysant le HTML. Si votre image hero est définie en arrière-plan CSS, injectée par JavaScript ou chargée en différé, le navigateur la découvre tard. Corrections :

• Utilisez un élément <img> classique pour l’image hero.
• N’ajoutez jamais loading="lazy" à l’image LCP.
• Ajoutez fetchpriority="high" ou une indication de préchargement pour que le navigateur la récupère tôt :

<link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">

L’image LCP est trop lourde

Un JPEG de 3000 pixels de large affiché à 1200 pixels gaspille de la bande passante à chaque visite. Servez des formats modernes comme WebP ou AVIF, dimensionnez l’image en fonction de la mise en page et utilisez srcset pour les différents écrans. Notre guide pour optimiser les images pour le web traite ce point en détail.

CSS et polices bloquant le rendu

De grosses feuilles de style et des scripts synchrones dans le <head> retardent l’affichage même une fois l’image prête. Intégrez le CSS critique directement dans la page, différez les scripts non essentiels et gardez des polices web légères.

Comment améliorer l’INP

L’INP mesure le temps entre une interaction de l’utilisateur et l’image suivante affichée par le navigateur. C’est presque toujours un problème de JavaScript, pas de réseau. L’article de web.dev sur l’INP le décompose en délai d’entrée, temps de traitement et délai de présentation.

Causes et corrections typiques :

• Tâches longues sur le thread principal. Tout script qui s’exécute plus de 50 ms empêche la page de répondre. Découpez les traitements longs en morceaux plus petits et rendez la main au navigateur entre chacun.
• Trop de JavaScript tiers. Widgets de chat, gestionnaires de balises, outils d’A/B testing et scripts publicitaires se disputent tous le thread principal. Faites l’inventaire de ce qui est chargé et supprimez ce que personne n’utilise.
• Gestionnaires d’événements lourds. Un clic qui déclenche une grosse mise à jour du DOM, le re-rendu d’une liste de produits entière ou des lectures de mise en page synchrones paraîtra poussif. Ne mettez à jour que ce qui a changé et affichez un retour visuel immédiat avant d’effectuer le travail coûteux.
• DOM trop volumineux. Les pages de plusieurs milliers d’éléments mettent plus de temps à recalculer les styles et la mise en page après chaque interaction. Les constructeurs de pages en sont une source fréquente.

Un CDN ou un cache n’aide l’INP qu’indirectement : moins de temps de téléchargement signifie que les scripts sont prêts plus tôt, mais le code doit toujours s’exécuter sur l’appareil du visiteur.

Comment améliorer le CLS

Le CLS évalue la plus forte série de décalages de mise en page inattendus pendant que la page est ouverte. Les décalages survenant dans les 500 ms suivant une interaction de l’utilisateur ne comptent pas : un accordéon qui s’ouvre après un clic ne pose donc aucun problème. L’article de web.dev sur le CLS explique le calcul du score.

Les suspects habituels :

• Images et vidéos sans dimensions. Sans attributs width et height (ou un aspect-ratio en CSS), le navigateur ne réserve aucun espace et pousse le contenu vers le bas à l’arrivée du fichier.
• Publicités, contenus intégrés et bannières insérés au-dessus du contenu. Réservez-leur un emplacement fixe, ou placez-les sous la ligne de flottaison.
• Bandeaux cookies qui poussent la page. Affichez-les en superposition au lieu de les insérer en haut du document.
• Remplacement des polices web. Quand une police de secours est remplacée par la police web, le texte peut se réorganiser. font-display: swap garde le texte visible tôt ; des métriques de police de secours ajustées (par exemple avec size-adjust) évitent que ce remplacement ne fasse bouger les éléments.

Les Core Web Vitals influencent-ils le classement ?

Les Core Web Vitals font partie des signaux d’expérience de page (en anglais) de Google. Google indique que ses systèmes de classement récompensent une bonne expérience de page, mais aussi que la pertinence et la qualité du contenu passent avant. En pratique, valider les Core Web Vitals ne propulsera pas une page faible en tête, et les rater ne fera pas couler une page qui est clairement la meilleure réponse.

La meilleure raison de s’en soucier, ce sont vos visiteurs. Un chargement lent, des boutons qui réagissent avec retard et une mise en page qui saute vous coûtent des demandes de contact et des ventes, quoi que fasse un algorithme. Considérez ces seuils comme un niveau de qualité pour les utilisateurs, pas comme une astuce SEO.

Comment fast.site vous aide

fast.site se place devant votre hébergement existant : vous gardez votre hébergeur et votre CMS. Vous faites pointer les serveurs de noms de votre domaine vers fast.site, et le trafic passe ensuite par un réseau edge avec des régions en Amérique du Nord, en Europe, en Asie-Pacifique et en Amérique du Sud, selon votre offre.

Pour le LCP, Fast Edge Cache™ sert les pages et ressources en cache depuis l’edge le plus proche du visiteur : un cache HIT n’attend donc pas votre serveur d’origine. Cela agit sur les parties TTFB et téléchargement du LCP. L’optimisation des images convertit à la volée les JPEG et PNG en WebP pour les navigateurs compatibles, avec l’AVIF disponible selon votre offre.

L’option d’optimisation HTML cible directement les problèmes courants de LCP et de CLS : elle précharge l’image hero détectée, ajoute la largeur et la hauteur aux images pour limiter les décalages de mise en page et ajoute font-display: swap aux polices web. Les détails se trouvent dans la documentation sur l’optimisation HTML.

fast.site ne peut pas corriger un JavaScript lent : le travail sur l’INP reste donc dans votre code. Mesurez avant et après sur votre propre site : l’en-tête fs-cache indique HIT, MISS ou BYPASS, et les statistiques affichent le TTFB et le taux de cache hit. Vous pouvez tester tout cela avec un essai gratuit de 7 jours, sans carte bancaire. Consultez les offres pour les détails.

Questions fréquentes

Qu’est-ce qu’un bon score Core Web Vitals ?

Une page est validée quand, au 75e percentile des visites, le LCP est de 2,5 secondes ou moins, l’INP de 200 millisecondes ou moins et le CLS de 0,1 ou moins. Les trois doivent être « bons » pour que l’évaluation soit réussie. Le mobile et le desktop sont évalués séparément.

Pourquoi mon score PageSpeed est-il bon alors que la Search Console indique un échec ?

Le score Lighthouse est un seul test de laboratoire sur un appareil simulé, tandis que la Search Console utilise 28 jours de données d’utilisateurs réels de Chrome. Les vrais visiteurs utilisent des téléphones et des réseaux plus lents que le test, et les tests de laboratoire ne peuvent pas mesurer l’INP. Fiez-vous aux données terrain pour l’évaluation et servez-vous du test de laboratoire pour le débogage.

Combien de temps faut-il pour voir les améliorations des Core Web Vitals ?

Les données terrain couvrent une fenêtre glissante de 28 jours : les améliorations apparaissent donc progressivement sur environ quatre semaines. La Search Console peut mettre un peu plus de temps à mettre à jour ses rapports. Les tests de laboratoire montrent le changement immédiatement.

Un CDN améliore-t-il les Core Web Vitals ?

Un CDN aide surtout le LCP en réduisant le temps de réponse du serveur et le temps de téléchargement pour les visiteurs éloignés de votre origine. Il peut réduire indirectement le CLS s’il propose des optimisations HTML comme l’ajout des dimensions d’image. L’INP dépend surtout du JavaScript exécuté dans le navigateur : un CDN y a donc peu d’effet direct.

Qu’est-ce qui a remplacé le First Input Delay (FID) ?

L’Interaction to Next Paint (INP) a remplacé le FID comme Core Web Vital en mars 2024. L’INP prend en compte les interactions de toute la visite au lieu de la seule première, et il inclut le temps d’affichage du résultat.