LCP, INP et CLS : comprendre les Core Web Vitals sans jargon

Les Core Web Vitals sont trois mesures par lesquelles Google évalue la qualité de l'expérience utilisateur d'une page web : le LCP pour la vitesse d'affichage, l'INP pour la réactivité, le CLS pour la stabilité visuelle. Chacune porte un seuil chiffré, et se lit sur des visites réelles.

Que sont les Core Web Vitals, et pourquoi Google les a créés

Google publie ces trois données pour chaque url dans un rapport dédié de la Search Console, à partir du temps de chargement relevé sur des visiteurs réels. Les Core Web Vitals ont été introduites en 2020, puis intégrées aux critères de classement de la recherche à partir de 2021 sur mobile et de 2022 sur ordinateur. Leur objet est de rendre mesurable ce qu'un outil SEO classique ne voit pas : le temps qu'une page met à devenir utile, sa réactivité au clic, sa stabilité pendant le chargement.

Le problème qu'elles adressent est banal. Un site peut être irréprochable sur le plan technique et rester pénible : la page met quatre secondes à afficher son texte, le bouton ne répond pas tout de suite, une bannière pousse le paragraphe qu'on lisait trois lignes plus bas. Aucun de ces défauts n'apparaît dans un audit de balises, et pourtant chacun fait partir un visiteur.

Signaux web essentiels, le nom français

La documentation francophone de Google parle de signaux web essentiels. C'est la traduction officielle de Core Web Vitals, et les deux expressions désignent exactement la même chose. Le rapport de la Search Console emploie la version française, la plupart des outils techniques la version anglaise : il est utile de savoir que le vocabulaire varie selon l'écran qu'on a sous les yeux.

Le mot vitals est emprunté au vocabulaire médical, celui des signes vitaux. L'idée est la même : quelques mesures simples, prises au bon endroit, qui disent l'état général sans qu'on ait besoin d'un examen complet. Google ajoute l'adjectif core parce que ces indicateurs sont le socle commun, valable pour tous les sites, là où d'autres mesures ne concernent qu'une famille de pages.

Trois mesures, trois moments de la visite

La logique du triptyque devient évidente quand on suit une visite dans l'ordre. L'internaute clique sur un résultat de recherche : combien de temps avant qu'il voie quelque chose d'utile ? C'est le LCP. Il voit la page, il agit : combien de temps avant que son action produise un effet ? C'est l'INP. Pendant tout ce temps, le contenu reste-t-il en place ? C'est le CLS.

Chaque métrique répond donc à une question que l'utilisateur se pose sans la formuler. Aucune ne remplace les deux autres : une page peut s'afficher instantanément et devenir inutilisable dès le premier clic, ou répondre au doigt et à l'oeil tout en dansant sous le curseur. C'est pourquoi le rapport core web vitals de la Search Console les affiche côte à côte plutôt que sous la forme d'un score unique.

LCP : le temps que met le contenu principal à s'afficher

Le LCP, pour Largest Contentful Paint, mesure le temps écoulé entre le début du chargement de la page et l'affichage du plus grand élément de contenu visible à l'écran. Cet élément est presque toujours une image, une vidéo en poster, un bloc de texte volumineux ou l'illustration principale d'un article.

Ce que le LCP mesure vraiment

La nuance compte : le LCP ne dit pas quand la page a fini de charger, il dit quand l'internaute a enfin quelque chose de conséquent devant les yeux. Une page peut continuer de charger des scripts publicitaires pendant dix secondes sans que cela dégrade sa mesure, du moment que le contenu principal, lui, était là tôt.

Cette définition explique une observation déroutante : deux pages de poids identique peuvent afficher des temps très différents. Ce qui compte n'est pas le nombre total de ressources, c'est la place de l'élément principal dans la file d'attente du navigateur. Un visuel déclaré tard dans le code html, ou chargé par du javascript, attendra son tour derrière tout le reste.

Les quatre segments d'un LCP lent

Un temps trop long se décompose toujours en quatre segments, et les identifier évite de traiter au hasard :

• Le temps de réponse du serveur, ou TTFB : la durée avant que le premier octet arrive. Un hébergement saturé ou une base de données lente se voit ici.
• Le délai avant découverte de la ressource : le navigateur ne sait pas encore qu'il doit charger cette image parce qu'elle est déclarée trop loin dans le document.
• La durée de téléchargement de la ressource elle-même : un fichier de deux mégaoctets sur un réseau mobile prend le temps qu'il prend.
• Le délai d'affichage une fois la ressource reçue : une police d'écriture qui bloque le rendu, ou un script qui monopolise le navigateur, retarde encore la mise à l'écran.

Un outil de mesure indique lequel de ces quatre segments pèse le plus. C'est la première information à chercher, avant toute optimisation : réduire le poids d'une image ne sert à rien si le problème est un serveur qui met une seconde et demie à répondre.

Ce qui dégrade le LCP le plus souvent

Dans la pratique, quelques causes reviennent sans cesse. L'image principale servie en pleine résolution alors que l'écran n'en affiche qu'une fraction. Le chargement différé, ou lazy loading, appliqué par erreur à l'illustration du haut de page, ce qui retarde précisément ce qu'il fallait afficher en premier. Un carrousel dont la première diapositive n'apparaît qu'après l'exécution complète d'une bibliothèque javascript. Une police personnalisée qui laisse le texte invisible le temps de son téléchargement.

La mise en cache est le levier le plus rentable dès que le service d'hébergement est en cause : une page servie depuis un cache répond en quelques millisecondes là où une page recalculée à chaque visite mobilise le processeur. Sur les images, le bon réflexe tient en trois gestes : redimensionner au format réellement affiché, choisir un format moderne, et déclarer explicitement les dimensions dans le code source.

Le CSS mérite une attention particulière, car il bloque le rendu par nature : tant que la feuille de style n'est pas téléchargée, l'affichage attend. Alléger le CSS critique et différer le reste est souvent nécessaire sur un site web construit avec un thème générique, dont la feuille de style couvre des composants que la page n'utilise jamais.

INP : la réactivité de la page aux actions de l'internaute

L'INP, pour Interaction to Next Paint, mesure le délai entre le moment où l'utilisateur agit, par un clic, une pression sur l'écran ou une frappe au clavier, et le moment où la page affiche visuellement le résultat de cette action. Il ne retient pas la moyenne des interactions mais l'une des plus lentes de la visite, ce qui en fait une mesure sévère et représentative du pire ressenti.

Ce que l'INP a changé par rapport au FID

Jusqu'en mars 2024, la métrique de réactivité s'appelait FID, pour First Input Delay. Elle ne mesurait que le délai avant que le navigateur commence à traiter la première interaction, et s'arrêtait là. Une page pouvait donc obtenir un excellent FID tout en mettant deux secondes à afficher le résultat du clic, puisque le traitement lui-même et son affichage sortaient du périmètre.

L'INP a corrigé ce point aveugle sur trois plans : il couvre toute la durée, jusqu'à l'affichage effectif ; il observe l'ensemble des interactions et non la première ; et son seuil est bien plus exigeant. Le remplacement est effectif depuis mars 2024, et le FID a été retiré des rapports dans la foulée. Une documentation ou un audit qui parle encore de first input delay comme d'un signal actif date d'avant cette bascule.

Le thread principal, cause quasi unique

Un navigateur exécute le javascript sur une file d'exécution unique, le thread principal, qui sert aussi à repeindre l'écran. Tant qu'une tâche longue occupe cette file, rien d'autre ne peut se produire : le clic est enregistré, mais son traitement attend, et l'écran reste figé. C'est la cause de la quasi-totalité des mauvais scores d'INP.

Les coupables habituels sont connus. Les scripts de mesure d'audience et les balises publicitaires qui se déclenchent au chargement. Les gestionnaires d'événements qui recalculent toute une liste à chaque frappe dans un champ de recherche. Les bibliothèques d'interface qui reconstruisent une portion entière de la page pour un changement mineur. La solution consiste rarement à supprimer ces fonctionnalités : elle consiste à découper les tâches longues en tranches courtes, pour que le navigateur puisse répondre entre deux.

Les applications web dont l'interface se reconstruit en permanence sont les plus exposées, puisque chaque changement d'état y déclenche un recalcul complet. Sur ce type de site, l'équipe technique gagne à mesurer l'INP en conditions réelles avant de choisir quoi alléger : l'impact d'un même script varie énormément selon la page où il s'exécute et selon le matériel de l'utilisateur.

CLS : la stabilité visuelle de la mise en page

Le CLS, pour Cumulative Layout Shift, mesure à quel point les éléments déjà affichés se déplacent pendant que la page finit de charger. C'est la seule des trois métriques qui ne s'exprime pas en unité de temps : son résultat est un score sans dimension, et plus il est bas, plus la page est stable.

Comment le score se calcule

Chaque déplacement inattendu reçoit une note, produit de deux fractions. La première décrit la part de l'écran concernée par le mouvement, la seconde la distance parcourue rapportée à la hauteur de l'écran. Un petit bloc qui glisse de trois pixels ne pèse presque rien ; une image qui apparaît en haut et repousse tout l'article vers le bas pèse lourd.

Le score final ne totalise pas tous les déplacements de la visite : il retient la rafale la plus pénalisante, en regroupant les mouvements proches dans le temps. Cette subtilité explique qu'une page longue, parcourue pendant plusieurs minutes, ne soit pas mécaniquement pénalisée par rapport à une page courte.

Un point est essentiel à comprendre : un déplacement provoqué par l'utilisateur lui-même ne compte pas. Ouvrir un menu déroulant, déplier une section, cliquer sur un onglet qui change le contenu, tout cela est attendu et sort de la mesure. Le CLS ne sanctionne que le mouvement subi.

Les quatre causes classiques

• Les images sans dimensions déclarées. Le navigateur ignore la place à réserver, affiche le texte, puis le repousse quand l'image arrive. Indiquer largeur et hauteur dans le code suffit à supprimer le problème.
• Les encarts insérés dynamiquement. Une bannière, un bandeau de consentement ou un message d'alerte ajouté après coup pousse tout ce qui se trouve dessous. La parade est de réserver l'espace dès le départ.
• Les polices d'écriture personnalisées. Le texte s'affiche d'abord dans une police de substitution, puis change quand la police définitive arrive, ce qui modifie la longueur des lignes.
• Les contenus intégrés à taille variable : une vidéo, une carte ou un module social dont la hauteur réelle n'est connue qu'après chargement.

Les seuils, et le piège du 75e centile

Les trois Core Web Vitals se lisent selon les mêmes bandes : bonne, à améliorer, médiocre. Voici les valeurs de référence publiées par Google.

Ces seuils sont fixés par Google et peuvent évoluer : la documentation officielle reste la référence à jour. Le fait que l'INP soit venu remplacer le FID montre que le dispositif n'est pas figé. Elle propose aussi des guides d'optimisation propres à chacune des trois mesures.

La subtilité la plus souvent ignorée tient à la façon dont ces valeurs sont évaluées. Google ne retient ni la moyenne ni la médiane, mais le 75e centile : une page est considérée comme bonne lorsque trois visites sur quatre respectent le seuil. Autrement dit, un quart des utilisateurs peut avoir une expérience dégradée sans que la page bascule au rouge, mais il suffit qu'un tiers du trafic soit lent pour que le verdict tombe.

Concrètement, pour évaluer une page il faut obtenir une valeur inférieure au seuil sur au moins trois visites sur quatre. Une moyenne inférieure au seuil ne suffit donc pas : quelques visites très lentes emportent le verdict, et c'est exactement ce que cette méthode de calcul cherche à capturer. C'est le travers habituel des indicateurs agrégés, qu'on retrouve ailleurs en référencement : un chiffre unique recouvre souvent deux situations contraires, qui n'appellent pas le même correctif.

Deux conséquences pratiques en découlent. La première : optimiser pour son propre ordinateur ne prouve rien, puisque la mesure agrège des appareils et des réseaux très divers. La seconde : mobile et ordinateur sont évalués séparément, et un site peut parfaitement afficher du vert sur l'un et du rouge sur l'autre. C'est même le cas le plus fréquent, le matériel mobile d'entrée de gamme exécutant le javascript bien plus lentement.

Données de terrain et données de laboratoire

C'est la distinction que la moitié des articles sur le sujet passe sous silence, et elle explique la plupart des incompréhensions.

Les données de terrain proviennent d'utilisateurs réels. Google les collecte via le rapport d'expérience utilisateur de Chrome, connu sous le nom de CrUX, auprès des internautes qui ont accepté le partage de statistiques. Elles couvrent une fenêtre glissante de vingt-huit jours et reflètent la diversité réelle du parc : vieux téléphones, connexions instables, navigation en itinérance. Ce sont ces données, et elles seules, qui alimentent le classement.

Le dispositif est conçu pour respecter la vie privée : les mesures sont agrégées par origine et par type de page, jamais rattachées à un utilisateur identifiable. C'est aussi ce qui explique le grain assez grossier du rapport, qui regroupe les url en fonction de leur ressemblance plutôt que de les traiter une par une.

Les données de laboratoire viennent d'un test déclenché à la demande, dans des conditions simulées et constantes. Lighthouse fonctionne ainsi : il charge la page sur une machine virtuelle, avec un réseau et un processeur bridés selon un profil fixe. Le résultat est reproductible et sert au diagnostic, mais il ne dit rien de ce que vivent vos visiteurs.

Un écart entre les deux n'est donc pas une anomalie à corriger. Il signifie simplement que votre audience réelle ne ressemble pas au profil simulé. Une précision importante : l'INP ne peut pas être mesuré en laboratoire, faute d'interactions humaines à observer. Un test synthétique le remplace par une estimation du blocage du thread principal, qui en est un indice utile mais pas la valeur.

Une dernière limite mérite d'être connue : une page qui reçoit peu de trafic n'apparaît pas dans les données de terrain, faute d'un échantillon suffisant. Le rapport bascule alors sur une valeur agrégée à l'échelle du site, voire n'affiche rien du tout. Ce n'est pas un dysfonctionnement, c'est une condition de fiabilité statistique.

Où lire ses Core Web Vitals

Quatre outils suffisent, tous gratuits, et chacun répond à une question différente. Aucun ne remplace les autres : PageSpeed Insights juge une url isolée, la Search Console juge un site entier, et l'extension de Chrome sert à voir le défaut se produire sous les yeux.

PageSpeed Insights

C'est le point d'entrée le plus direct : on saisit une url, et l'outil affiche côte à côte les données de terrain issues du CrUX et le résultat du test de laboratoire. La lecture correcte consiste à regarder d'abord le bloc du haut, celui des utilisateurs réels, et à n'utiliser le score synthétique que comme piste de diagnostic. Beaucoup de déceptions viennent de l'inverse : on se focalise sur la note sur cent, qui est une mesure de laboratoire, alors que le classement ne s'appuie que sur le terrain.

Le rapport de la Search Console

La Google Search Console propose un rapport dédié, qui présente l'ensemble des pages du site regroupées par similarité. C'est le seul outil qui donne une vue globale plutôt que page par page, et qui indique combien d'url sont concernées par chaque problème. Il s'agit de l'endroit où commencer quand on veut hiérarchiser : corriger un défaut qui touche un groupe de deux cents pages n'a pas la même portée que corriger une page isolée.

Le rapport signale aussi une amélioration une fois la correction en ligne, après un délai de validation. Ce délai surprend souvent : il faut compter plusieurs semaines, puisque la fenêtre de mesure elle-même couvre vingt-huit jours de données. Une correction déployée aujourd'hui ne peut pas produire un effet visible demain.

Lighthouse et l'extension Chrome

Lighthouse est intégré aux outils de développement de Chrome et fournit, en plus des mesures, une liste de recommandations classées par gain estimé. L'extension officielle Web Vitals, elle, affiche les trois valeurs en direct pendant la navigation, ce qui rend le CLS beaucoup plus concret : on voit le déplacement se produire et le score monter au même instant. Ces recommandations aident à créer un plan de travail sans le remplacer : elles ignorent le contexte du site et peuvent conseiller une optimisation lourde pour un gain marginal. Pour choisir des solutions complémentaires, notre comparatif des outils SEO détaille directement ce que couvrent les principales plateformes du marché.

Quel impact réel sur le référencement

La question revient systématiquement, et elle mérite une réponse mesurée plutôt qu'une promesse. Les Core Web Vitals sont un signal de classement confirmé par Google, mais un signal parmi des centaines, et son poids est modeste comparé à la pertinence du contenu. Une page rapide et vide ne dépassera pas une page lente qui répond mieux à la requête.

Leur rôle est celui d'un critère de départage. À qualité éditoriale comparable, l'expérience de la page peut faire la différence entre deux résultats voisins. C'est particulièrement sensible sur les requêtes concurrentielles, où plusieurs pages traitent le sujet avec le même sérieux. Le conseil qui en découle est simple : chercher à améliorer ses Core Web Vitals a du sens quand le contenu tient déjà la comparaison, beaucoup moins avant.

Il existe cependant un effet indirect, souvent plus important que le signal lui-même. Une page lente ou instable fait fuir : le taux de rebond monte, le taux de conversion baisse, et les signaux d'engagement se dégradent. Ce sont ces conséquences commerciales, autant que le classement, qui justifient le travail. Beaucoup de sites y perdent d'ailleurs plus par des erreurs SEO plus banales que par leurs métriques de performance.

Un dernier point de vigilance : les Core Web Vitals ne compensent pas un problème d'indexation. Si Google ne connaît pas vos url, leur vitesse n'a aucune importance, puisqu'elles ne concourent nulle part. L'ordre des priorités est donc l'indexation, puis la pertinence du contenu, puis l'expérience de la page. Aucun correctif spécifique aux Core Web Vitals ne rattrape un site que le moteur n'explore pas.

Ce que les Core Web Vitals ne mesurent pas

Une confusion fréquente consiste à ranger parmi les Core Web Vitals toutes les valeurs affichées par les outils, avec l'aide involontaire des tableaux de bord qui les alignent. Le TTFB, le temps de réponse du serveur, et le FCP, l'instant où le premier élément quelconque apparaît, sont des métriques de diagnostic. Elles sont très utiles pour comprendre d'où vient un mauvais LCP, mais elles ne sont pas des Core Web Vitals et n'ont pas de seuil opposable.

Il en va de même pour le score global sur cent de Lighthouse, qui mélange une dizaine d'indicateurs selon une pondération qui lui est propre. On peut afficher 95 sur cent en laboratoire et être au rouge sur le terrain, ou l'inverse. Le score est un outil de travail, pas un verdict.

Enfin, aucune de ces trois mesures ne dit quoi que ce soit de l'accessibilité, de la lisibilité ou de la qualité de l'information. Une page peut être techniquement irréprochable et rester médiocre pour son lecteur. L'expérience utilisateur au sens large dépasse largement ce que trois indicateurs peuvent capturer.

Les questions qui reviennent le plus souvent

Combien de temps avant de voir une amélioration ?

Comptez environ quatre semaines après la mise en ligne du correctif. La mesure de terrain repose sur une fenêtre glissante de vingt-huit jours : tant que cette fenêtre contient encore des visites antérieures à la correction, la valeur affichée reste mélangée.

Faut-il viser un score parfait ?

Non. L'objectif est de passer dans la bande verte des trois métriques, pas de chercher le maximum. Au-delà du seuil, l'effort supplémentaire n'apporte aucun bénéfice de classement et se fait souvent au détriment de fonctionnalités utiles.

Mon site n'affiche aucune donnée de terrain, est-ce grave ?

Non, cela signifie seulement que le trafic est insuffisant pour constituer un échantillon fiable. Utilisez alors les mesures de laboratoire pour le diagnostic, en gardant à l'esprit qu'elles décrivent un profil simulé et non votre audience.

Le FID existe-t-il encore ?

Non. Le first input delay a été remplacé par l'INP en mars 2024, puis retiré des rapports. Un audit qui le présente comme un signal actif s'appuie sur une documentation périmée.

Un thème ou une extension peuvent-ils suffire à corriger le problème ?

Rarement en totalité. Une extension de mise en cache résout souvent une partie du LCP, mais l'INP dépend du javascript réellement exécuté et le CLS de la façon dont la page est construite. Ces deux points demandent une intervention sur le code ou sur le modèle de page. Une extension peut améliorer le résultat, elle ne le garantit pas.

Par où commencer quand tout est au rouge

L'erreur la plus courante consiste à tout attaquer en même temps. Une démarche efficace tient en cinq étapes, et vaut comme guide de dépannage pour un site web dont les trois indicateurs sont au rouge.

1. Identifier le groupe de pages le plus large. Le rapport de la Search Console regroupe les url par similarité : une correction apportée au modèle d'article corrige d'un coup toutes les pages qui l'utilisent.
2. Traiter le CLS en premier. C'est presque toujours le plus rapide à corriger, souvent par la simple déclaration des dimensions des images, et le gain est immédiatement visible.
3. Attaquer le LCP par son segment dominant. Serveur, découverte, téléchargement ou affichage : l'outil désigne le coupable, il suffit de ne pas traiter les trois autres.
4. Réduire le javascript pour l'INP. Repousser les scripts non essentiels après l'affichage, et découper les traitements longs, produit l'essentiel du gain.
5. Mesurer à nouveau après quatre semaines, sur les données de terrain, et suivre en parallèle l'évolution des positions. Un outil de suivi de position permet de rapporter le travail technique à son effet réel sur le classement.

Cette progression a un mérite : elle donne un résultat mesurable dès la première semaine, ce qui peut aider à tenir un chantier technique dans la durée. Et elle rappelle l'ordre naturel des choses : les Core Web Vitals récompensent un site déjà pertinent, ils ne remplacent jamais le travail sur le contenu.