Core Web Vitals : ce que Google mesure vraiment sur votre site

En 2020, Google a formalisé un ensemble de métriques appelées Core Web Vitals, intégrées l'année suivante à ce qu'il a baptisé le "Page Experience update". L'idée de départ était simple : jusque-là, la vitesse d'un site était évaluée avec des métriques techniques (temps de chargement total, taille de la page, nombre de requêtes) qui ne correspondaient pas forcément à ce qu'un visiteur perçoit réellement. Un site peut finir de charger en trois secondes tout en donnant l'impression d'être lent, si l'élément important à l'écran met du temps à apparaître, ou si la page bouge sous les doigts de l'utilisateur avant qu'il ait pu cliquer où il voulait.

Les Core Web Vitals ont été conçus pour combler cet écart : mesurer l'expérience perçue, pas seulement la performance brute. Trois métriques ont été retenues, chacune avec un seuil "bon", un seuil "à améliorer" et un seuil "mauvais", publiés et documentés par Google — ce ne sont pas des estimations propriétaires opaques, mais des chiffres que n'importe qui peut retrouver sur web.dev et vérifier soi-même. Cette transparence est elle-même un choix notable : contrairement à la plupart des signaux de classement de Google, dont le fonctionnement exact reste confidentiel, les Core Web Vitals sont documentés en détail, avec la méthodologie de calcul, les seuils exacts, et les recommandations de correction publiées publiquement.

Ce choix de transparence a une explication pratique : contrairement à des signaux comme la pertinence sémantique d'un contenu, qui reste difficile à quantifier objectivement, la performance technique d'une page peut être mesurée de façon reproductible et vérifiable par n'importe quel outil indépendant. Google n'a donc rien à perdre à documenter précisément ces métriques, puisqu'elles ne peuvent pas être manipulées artificiellement de la même façon qu'un signal plus subjectif pourrait l'être.

Qu'est-ce qui distingue un Core Web Vital d'une métrique de performance classique

Lighthouse, l'outil d'audit de Google, mesure des dizaines de métriques : Time to First Byte, First Contentful Paint, Total Blocking Time, Speed Index, Time to Interactive, et bien d'autres. Toutes ne sont pas des Core Web Vitals. Ce statut est réservé aux trois métriques qui, selon les équipes Chrome, corrèlent le mieux avec la perception réelle de qualité par les utilisateurs, sur la base de recherches en expérience utilisateur menées sur des millions de sessions réelles. Les autres métriques restent utiles pour diagnostiquer un problème précis, mais n'ont pas le même statut dans l'évaluation globale d'une page par Google.

Cette distinction a une conséquence pratique importante pour qui audite un site : un score Lighthouse global de 60 sur 100 ne dit pas grand-chose en soi, puisqu'il agrège des dizaines de signaux de poids différents. Ce qui compte pour l'évaluation Core Web Vitals, c'est uniquement la performance sur les trois métriques désignées — un site peut avoir un score Lighthouse médiocre pour des raisons qui n'affectent aucun des trois Core Web Vitals, et inversement obtenir une évaluation "bonne" sur les Core Web Vitals tout en ayant des marges de progression ailleurs.

LCP — Largest Contentful Paint

Le LCP mesure le temps écoulé entre le début du chargement de la page et l'affichage du plus grand élément de contenu visible dans la fenêtre du navigateur — le plus souvent une image principale, une vidéo, ou un bloc de texte volumineux comme un titre. Ce n'est pas le temps de chargement complet de la page : c'est le moment où l'utilisateur voit apparaître ce qui compte visuellement le plus, ce qui correspond assez bien à l'instant où un visiteur estime intuitivement que "la page s'est chargée", même si des éléments secondaires continuent de charger en arrière-plan.

Les seuils publiés par Google : un LCP inférieur ou égal à 2,5 secondes est considéré comme bon, entre 2,5 et 4 secondes comme à améliorer, au-delà de 4 secondes comme mauvais. Ces seuils s'appliquent au 75e percentile des chargements de page mesurés — c'est-à-dire que 75 % des visites doivent respecter le seuil pour que la page soit classée dans la catégorie correspondante, une nuance souvent ignorée quand on ne regarde qu'un score moyen. Concrètement, un site peut afficher un LCP moyen de 2 secondes tout en étant classé "à améliorer", si une part significative des visites (au-delà de 25 %) dépasse largement cette moyenne — un scénario courant quand une fraction des visiteurs utilise une connexion mobile de mauvaise qualité ou un appareil ancien.

Les causes les plus fréquentes d'un LCP dégradé se répartissent en quatre familles. D'abord, un temps de réponse serveur trop long (TTFB élevé) : si le serveur met une seconde à répondre avant même d'envoyer le premier octet de HTML, tout le reste du chargement part avec ce retard, quelle que soit ensuite la qualité de l'optimisation front-end. Ensuite, des ressources qui bloquent le rendu — des feuilles de style ou scripts chargés de façon synchrone avant que le navigateur puisse afficher quoi que ce soit, un schéma hérité de pratiques de développement plus anciennes qui n'ont pas toujours été révisées.

Troisièmement, des images non optimisées : un format inadapté (JPEG non compressé plutôt que WebP ou AVIF, des formats plus récents offrant une compression nettement supérieure à qualité visuelle équivalente), une taille physique trop grande par rapport à l'espace d'affichage réel (une image de 4000 pixels de large affichée dans un conteneur de 800 pixels gaspille de la bande passante sans bénéfice visuel), ou l'absence de préchargement pour l'image visible immédiatement à l'écran via la directive `<link rel="preload">`. Enfin, un rendu entièrement piloté par JavaScript côté client, où le navigateur doit télécharger, exécuter et interpréter du code avant de pouvoir afficher le contenu principal — un schéma fréquent sur les applications construites avec des frameworks JavaScript sans rendu serveur, où le HTML initial envoyé au navigateur est quasiment vide et ne se remplit qu'après exécution du script.

INP — Interaction to Next Paint

L'INP a remplacé le First Input Delay (FID) comme Core Web Vital officiel en mars 2024, après une période de transition de plusieurs mois où les deux métriques coexistaient dans les outils de mesure. Le changement n'est pas cosmétique : le FID ne mesurait que le délai avant que le navigateur commence à traiter la toute première interaction de l'utilisateur, sans tenir compte du temps nécessaire pour que cette interaction produise un résultat visible à l'écran, et sans tenir compte des interactions suivantes au cours de la session. Un site pouvait ainsi afficher un excellent FID tout en restant peu réactif pour le reste de la navigation.

L'INP corrige les deux angles morts du FID : il mesure la latence complète — du clic jusqu'à l'affichage du prochain rendu visuel à l'écran — et il retient la pire interaction observée sur l'ensemble de la session, pas seulement la première. Cette approche donne une image beaucoup plus fidèle de la réactivité perçue tout au long de la visite, y compris sur des pages où l'utilisateur interagit longuement (filtre un tableau, ouvre plusieurs menus, remplit un formulaire complexe).

Seuils Google : un INP inférieur ou égal à 200 millisecondes est bon, entre 200 et 500 millisecondes à améliorer, au-delà de 500 millisecondes mauvais. Un INP élevé signale presque toujours un excès de travail JavaScript exécuté en réponse à l'action de l'utilisateur : des gestionnaires d'événements trop lourds qui recalculent des structures de données volumineuses à chaque clic, des scripts tiers (widgets de chat, outils d'analytics, pixels publicitaires, bannières de consentement) qui monopolisent le thread principal au moment précis où l'utilisateur tente d'interagir, ou des mises à jour de l'interface mal optimisées qui forcent le navigateur à recalculer l'affichage plus souvent que nécessaire — un phénomène technique appelé reflow, particulièrement coûteux en performance quand il touche une grande partie de la page.

Un point technique souvent ignoré : l'INP est particulièrement sensible aux scripts tiers, davantage que le LCP ou le CLS. Un site qui charge simultanément un outil d'analytics, un widget de chat, un gestionnaire de consentement aux cookies, et deux ou trois pixels publicitaires peut voir son INP se dégrader significativement même si son propre code est parfaitement optimisé, simplement parce que chacun de ces scripts tiers consomme sa part de temps de traitement sur le thread principal du navigateur au moment critique d'une interaction utilisateur.

CLS — Cumulative Layout Shift

Le CLS mesure l'instabilité visuelle cumulée d'une page : chaque fois qu'un élément visible se déplace de façon inattendue après son premier affichage, ce déplacement est enregistré et pondéré selon sa taille et la distance parcourue à l'écran. La somme de ces décalages sur la durée de vie de la page constitue le score CLS final.

Seuils : un CLS inférieur ou égal à 0,1 est bon, entre 0,1 et 0,25 à améliorer, au-delà de 0,25 mauvais — c'est la seule des trois métriques à ne pas s'exprimer en temps, mais en une valeur sans unité représentant une fraction de l'écran affecté par les décalages. Les causes les plus courantes : des images ou vidéos sans dimensions déclarées dans le HTML, qui poussent le contenu existant une fois leur poids réel connu par le navigateur au moment où le fichier finit de se télécharger ; des bannières publicitaires ou des iframes tierces injectées dynamiquement sans espace réservé à l'avance dans la mise en page ; des polices de caractères personnalisées qui provoquent un changement de mise en page une fois chargées (le texte s'affiche d'abord avec une police de secours système, puis se redimensionne visuellement une fois la police personnalisée disponible, un phénomène appelé FOUT pour Flash of Unstyled Text) ; et du contenu inséré au-dessus de ce que l'utilisateur est déjà en train de lire, comme une notification, un bandeau de consentement aux cookies, ou une invite d'inscription à une newsletter qui apparaît après coup et repousse le contenu vers le bas.

C'est, en pratique, la métrique la plus simple à corriger une fois identifiée : réserver l'espace nécessaire (attributs width et height sur les balises image et vidéo, ou propriété CSS aspect-ratio pour les contenus au format variable) suffit à éliminer la grande majorité des décalages liés aux médias. Pour les polices personnalisées, la propriété CSS font-display, combinée à un préchargement de la police, permet de réduire l'écart visuel entre la police de secours et la police finale. Pour les bannières et contenus injectés dynamiquement, réserver un espace fixe correspondant à la taille attendue de l'élément avant même son chargement effectif évite le décalage, quitte à afficher un espace vide temporaire plutôt qu'un contenu qui pousse le reste de la page.

TTFB, FCP, TBT : les métriques satellites à connaître

Bien qu'elles ne soient pas des Core Web Vitals à proprement parler, plusieurs métriques mesurées par Lighthouse et PageSpeed Insights restent précieuses pour diagnostiquer la cause profonde d'un Core Web Vital dégradé. Le Time to First Byte (TTFB) mesure le délai avant que le navigateur reçoive le premier octet de réponse du serveur — un TTFB élevé est presque toujours la première cause à vérifier en cas de LCP dégradé, puisque tout le reste du chargement dépend de ce point de départ.

Le First Contentful Paint (FCP) mesure l'affichage du tout premier élément de contenu, qui peut être bien plus rapide que le LCP si le premier élément affiché n'est pas le plus grand de la page — un écart important entre FCP et LCP indique souvent qu'un élément spécifique (une image, une vidéo) retarde significativement l'affichage complet malgré un début de chargement rapide. Le Total Blocking Time (TBT), utilisé en données de laboratoire comme approximation de l'INP, mesure le temps cumulé pendant lequel le thread principal est occupé par des tâches trop longues pour permettre une réponse rapide aux interactions — un TBT élevé en laboratoire est un signal d'alerte précoce pour un INP potentiellement dégradé une fois le site en conditions réelles.

Données de terrain contre données de laboratoire

PageSpeed Insights peut afficher deux catégories de résultats bien distinctes, souvent confondues par ceux qui découvrent l'outil. Les données de terrain proviennent du Chrome User Experience Report (CrUX) : des mesures anonymisées, collectées sur de vrais visiteurs utilisant le navigateur Chrome avec la collecte de statistiques activée, agrégées sur une fenêtre glissante de 28 jours. Les données de laboratoire, elles, proviennent d'une simulation unique effectuée au moment précis du test, dans un environnement contrôlé qui ne représente qu'un seul scénario de connexion et d'appareil, généralement calibré pour représenter un appareil mobile de milieu de gamme sur une connexion 4G simulée.

Un site récent ou à faible trafic n'a souvent pas assez de visites pour que Google constitue un échantillon de données de terrain fiable et statistiquement significatif — ce n'est pas une anomalie technique, seulement un manque de volume de trafic. Dans ce cas, seules les données de laboratoire sont disponibles, ce qui donne une photographie plus théorique que représentative de l'expérience réelle vécue par les visiteurs. Les deux sources peuvent aussi diverger sur un site à fort trafic : la donnée de terrain reflète un mélange d'appareils, de connexions et de conditions réseau très variées observées dans la réalité, alors que le test de laboratoire simule des conditions fixes et reproductibles, généralement plus favorables ou plus défavorables selon la configuration exacte choisie par l'outil de test.

C'est aussi pour cette raison que Google privilégie les données de terrain pour son évaluation de classement, quand elles sont disponibles : elles reflètent l'expérience réellement vécue, pas une simulation isolée. Un site qui optimise uniquement en fonction de son score de laboratoire, sans jamais vérifier ses données de terrain réelles via Search Console, risque de corriger des problèmes qui n'affectent en réalité qu'une fraction marginale et non représentative de ses visiteurs.

Mobile et desktop : deux évaluations séparées

Google évalue les Core Web Vitals séparément pour mobile et pour desktop, avec des résultats qui peuvent diverger fortement sur un même site. Ce n'est pas anodin : depuis le passage à l'indexation mobile-first, c'est la version mobile du site qui sert de référence principale pour le classement, y compris pour les recherches effectuées depuis un ordinateur de bureau. Un site qui affiche d'excellents scores sur desktop mais des scores dégradés sur mobile — un cas très fréquent, les appareils mobiles disposant de moins de puissance de calcul et de connexions réseau souvent plus lentes et plus variables que le wifi ou la fibre généralement utilisés sur desktop — doit prioriser la correction côté mobile en premier lieu.

Cette différence s'explique aussi par des choix de conception fréquents : certains sites servent un contenu identique sur mobile et desktop, avec les mêmes images en haute résolution et les mêmes scripts, simplement redimensionnés visuellement par CSS — une pratique qui pénalise doublement les performances mobiles, puisque l'appareil télécharge et traite la même quantité de données qu'un ordinateur de bureau, tout en disposant de ressources matérielles généralement inférieures pour les traiter.

Un facteur de classement, mais pas le seul ni le plus déterminant

Google a confirmé que les Core Web Vitals font partie des signaux de classement, mais avec une nuance importante souvent oubliée dans le discours marketing autour du sujet : il s'agit d'un signal parmi plusieurs dizaines, dont le poids relatif reste modeste comparé à la pertinence du contenu par rapport à la requête de recherche. Un contenu médiocre mais rapide ne dépassera pas un contenu excellent mais plus lent dans les résultats de recherche. En revanche, entre deux contenus de qualité comparable répondant à la même requête, la performance peut faire pencher la balance — c'est davantage un facteur de départage qu'un levier de classement à lui seul capable de compenser un contenu faible.

Cette nuance a une conséquence pratique importante dans la priorisation d'un plan d'action SEO : investir massivement dans l'optimisation des Core Web Vitals d'un site dont le contenu ne répond pas correctement aux besoins des utilisateurs produira un retour sur investissement décevant. La performance technique agit comme un multiplicateur sur un contenu déjà pertinent, pas comme un substitut à la pertinence elle-même.

Prioriser les corrections plutôt que tout traiter d'un coup

Face à un rapport listant plusieurs problèmes de performance, l'erreur commune consiste à vouloir tout corriger en même temps, sans distinction de priorité ni d'effort requis. Une approche plus efficace distingue les corrections rapides à faible risque (réserver les dimensions d'images, différer le chargement des scripts non essentiels via l'attribut defer ou async, activer la compression Gzip ou Brotli des réponses serveur, activer la mise en cache navigateur pour les ressources statiques) des corrections structurelles plus lourdes (changer d'architecture de rendu pour du rendu serveur ou statique, migrer vers un hébergeur plus performant, refondre un système de gestion de contenu devenu obsolète, réduire le nombre de scripts tiers embarqués).

Commencer par les premières donne des résultats mesurables rapidement, sans engager de chantier technique disproportionné par rapport au problème réel — une bannière publicitaire mal intégrée peut, à elle seule, dégrader significativement le CLS d'un site par ailleurs parfaitement optimisé, et sa correction ne demande que quelques lignes de CSS plutôt qu'une refonte complète.

Cas pratique : diagnostiquer un LCP dégradé étape par étape

Face à un LCP classé "mauvais", la démarche de diagnostic suit généralement un ordre logique. Première étape : vérifier le TTFB dans l'onglet Réseau des outils de développement du navigateur. Un TTFB supérieur à 600-800 millisecondes indique un problème côté serveur ou hébergement, à traiter avant toute optimisation front-end, puisqu'aucune optimisation de l'affichage ne peut compenser un serveur lent à répondre.

Deuxième étape : identifier précisément quel élément de la page est désigné comme l'élément LCP — les outils de développement Chrome affichent cette information directement dans le panneau Performance. Si l'élément est une image, vérifier son format, sa taille de fichier, sa taille d'affichage réelle, et l'absence ou la présence d'un préchargement. Si l'élément est un bloc de texte, vérifier qu'aucune police personnalisée ne retarde son affichage, et que le CSS nécessaire à son rendu n'est pas bloqué par des ressources non critiques chargées en amont.

Troisième étape : examiner la chronologie complète du chargement pour repérer les ressources qui bloquent le rendu avant l'affichage de l'élément LCP — souvent des feuilles de style volumineuses chargées de façon synchrone, ou des scripts placés dans l'en-tête du document sans attribut defer ni async, qui interrompent le parsing du HTML le temps de leur téléchargement et exécution complète.

Les pièges de l'optimisation excessive

Une optimisation mal comprise peut parfois dégrader l'expérience plutôt que l'améliorer. Le lazy loading — différer le chargement des images hors du champ de vision initial — est une bonne pratique générale, mais appliquée par erreur à l'image qui constitue justement l'élément LCP, elle retarde son affichage au lieu de l'accélérer, puisque le navigateur doit alors attendre un signal supplémentaire avant de commencer le téléchargement de cette image pourtant prioritaire.

De même, une préoccupation excessive pour le CLS peut conduire à réserver des espaces disproportionnés pour du contenu dynamique dont la taille finale reste incertaine, créant des vides visuels inesthétiques en attendant le chargement effectif — un compromis à doser plutôt qu'une règle à appliquer aveuglément. L'objectif reste l'expérience réelle du visiteur, dont les Core Web Vitals ne sont qu'une mesure approximative, pas une fin en soi déconnectée du ressenti final.

Outils pour mesurer et suivre dans la durée

• PageSpeed Insights : le point d'entrée le plus accessible, combine données de terrain et de laboratoire pour une URL donnée, gratuit et sans inscription requise.
• Google Search Console, rapport "Signaux Web essentiels" : vue agrégée par groupe d'URLs similaires sur l'ensemble du site, plus adaptée pour repérer un problème de gabarit qui affecte de nombreuses pages à la fois plutôt qu'une URL isolée.
• Chrome DevTools, panneau Performance : pour un diagnostic fin, ligne par ligne, de ce qui bloque le rendu ou consomme le thread principal au moment précis d'une interaction.
• CrUX Dashboard : historique des données de terrain sur plusieurs mois, utile pour vérifier qu'une correction a bien produit un effet durable et pas seulement un pic ponctuel lié à des conditions de test favorables.
• Lighthouse CI : pour intégrer une vérification automatique des Core Web Vitals directement dans le processus de déploiement, avant même la mise en production d'un changement.
• web-vitals (bibliothèque JavaScript officielle de Google) : pour collecter ses propres données de terrain en temps réel, indépendamment du délai de 28 jours de CrUX.

Questions fréquentes

Pourquoi mon score change-t-il d'un test à l'autre ? Les données de laboratoire dépendent des conditions au moment précis du test (charge du serveur qui exécute le test, état du cache, variations réseau ponctuelles) — une petite variation d'un test à l'autre est normale et ne signale pas nécessairement une régression réelle. Seule une tendance observée sur plusieurs mesures, ou les données de terrain agrégées sur 28 jours, permettent de conclure à une évolution réelle et durable.

Un bon score garantit-il un bon classement ? Non. C'est une condition qui retire un frein potentiel au classement, pas un levier qui pousse mécaniquement une page vers le haut des résultats. Un site avec d'excellents Core Web Vitals mais un contenu peu pertinent pour la requête de l'utilisateur ne sera pas mieux classé pour autant, quelle que soit la qualité de sa performance technique.

Faut-il viser 100/100 partout ? Non plus. Le seuil qui compte pour l'évaluation Google est celui de la catégorie "bon" — au-delà, chaque optimisation supplémentaire a un coût d'ingénierie croissant pour un bénéfice marginal décroissant, à mettre en balance avec d'autres priorités du site qui pourraient avoir un meilleur retour sur investissement.

Les Core Web Vitals sont-ils identiques pour tous les types de pages d'un site ? Non, chaque URL est évaluée individuellement, même si Google agrège aussi les résultats par groupe de pages similaires (par exemple toutes les fiches produit d'un site e-commerce partageant le même gabarit) pour faciliter le diagnostic à l'échelle du site plutôt que page par page.

Un CDN suffit-il à résoudre un LCP dégradé ? Un réseau de diffusion de contenu peut réduire significativement le TTFB en rapprochant géographiquement les fichiers statiques des visiteurs, mais il ne résout pas les causes liées au poids des images, aux scripts bloquants, ou à un rendu entièrement piloté par JavaScript — des causes qui demandent des corrections spécifiques indépendantes de l'infrastructure de diffusion.

Seoditum vérifie ce point automatiquement, avec preuve à l'appui, sur l'ensemble de votre site.