Trois lettres reviennent dans chaque audit de vitesse : LCP, INP, CLS. Elles forment les Core Web Vitals, les métriques que Google publie et qu’il utilise comme signal de classement parmi d’autres. Le problème n’est pas de les ignorer — la plupart des sites les surveillent déjà — c’est de les traiter comme un bloc unique, à corriger dans le désordre, alors qu’une seule d’entre elles concentre presque toujours le vrai retard.
Ce que chaque métrique mesure réellement
Le LCP (Largest Contentful Paint) chronomètre l’affichage du plus grand élément visible à l’écran — souvent une image de mise en avant ou un titre. Il répond à une question simple : combien de temps le visiteur attend-il avant de voir quelque chose de substantiel ? L’INP (Interaction to Next Paint) mesure la réactivité : le délai entre un clic, un appui sur une touche, et la réponse visible à l’écran. Le CLS (Cumulative Layout Shift) quantifie les sautes de mise en page — une image qui charge en poussant le texte, un bouton qui se déplace au moment où le doigt allait le toucher.
Données de laboratoire contre données de terrain
Un audit lancé depuis un outil de test simule une visite unique, dans des conditions contrôlées : c’est une donnée de laboratoire, utile pour déboguer mais qui ne dit rien de l’expérience réelle. Les données de terrain, elles, proviennent des visiteurs eux-mêmes, agrégées sur plusieurs semaines par navigateur Chrome, et c’est cette moyenne de terrain que le rapport Signaux Web essentiels de la Google Search Console affiche et que le classement prend en compte. Un site peut afficher un excellent score en laboratoire, avec un serveur au repos et une connexion rapide, et un score médiocre en terrain, où la moitié des visites arrivent depuis un réseau mobile chargé. Les définitions précises et les seuils retenus sont publiés par Google sur web.dev, mis à jour à chaque évolution de la métrique.
Pourquoi le LCP est presque toujours le point bloquant
Sur la majorité des sites de contenu ou de vente en ligne, le LCP est l’élément qui déborde des seuils recommandés, loin devant l’INP et le CLS. La raison est mécanique : le LCP dépend de tout ce qui précède l’affichage — le temps de réponse du serveur, le poids de l’image principale, le chargement de la police de caractères, les scripts qui s’exécutent avant le rendu. Chacun de ces maillons ajoute son propre délai, alors que le CLS se corrige souvent avec une seule ligne de CSS (réserver l’espace d’une image avant qu’elle ne charge) et que l’INP ne devient critique que sur des interfaces très chargées en scripts.
Ce qui améliore réellement le LCP : compresser et dimensionner correctement l’image du hero, précharger la police au lieu de la laisser bloquer l’affichage, et réduire le temps de réponse du serveur en amont de tout le reste. Ce qui ne l’améliore presque jamais : les réglages cosmétiques — minifier un fichier CSS déjà petit, ajouter une troisième couche de cache sur un serveur déjà rapide, ou changer de thème sans toucher au poids réel des images.
| Métrique | Ce qu’elle mesure | Seuil « bon » | Levier principal |
|---|---|---|---|
| LCP | Temps d’affichage du plus grand élément visible | 2,5 secondes ou moins | Image du hero, police, temps de réponse serveur |
| INP | Délai entre une interaction et sa réponse visible | 200 millisecondes ou moins | Volume et découpage des scripts JavaScript |
| CLS | Somme des déplacements de mise en page | 0,1 ou moins | Espace réservé pour images et publicités avant chargement |
La bonne méthode de diagnostic part donc du rapport de terrain dans la Search Console, identifie laquelle des trois métriques dépasse le seuil, et concentre l’effort sur celle-là avant de toucher aux deux autres. Corriger le CLS d’un site dont le vrai problème est un LCP à cinq secondes ne change rien au classement ni à l’expérience — ça occupe un sprint pour un résultat qui ne se verra jamais. Nous revenons dans notre rubrique dédiée aux outils sur la manière de lire ce rapport sans se noyer dans les graphiques.
