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

Les Core Web Vitals décrivent trois aspects de l’expérience : le chargement avec le LCP, la réactivité avec l’INP et la stabilité visuelle avec le CLS. Les objectifs recommandés sont un LCP d’au plus 2,5 secondes, un INP d’au plus 200 millisecondes et un CLS d’au plus 0,1.

L’évaluation porte sur le 75e percentile des visites, séparément sur mobile et ordinateur. Autrement dit, elle ne résume pas le site à un test effectué une seule fois sur une machine.

Le Largest Contentful Paint mesure le moment où la plus grande image ou zone de texte éligible visible dans la fenêtre est rendue. Il représente généralement l’apparition du contenu principal perçu au début de la page.

• Pour diagnostiquer un LCP lent, identifiez d’abord l’élément mesuré.
• Examinez ensuite la réponse du serveur, les redirections, les ressources bloquant le rendu, le chargement du média et le rendu côté client.
• La bonne correction dépend de la cause observée.

Interaction to Next Paint observe la latence des clics, touchers et frappes au clavier pendant la visite. Un INP élevé peut venir d’un travail trop long sur le thread principal, de JavaScript coûteux ou d’un rendu important déclenché par l’interaction.

Une mesure de terrain est particulièrement importante pour cette métrique. Lighthouse ne peut pas mesurer l’INP réel sans interactions utilisateur ; il utilise notamment le Total Blocking Time comme indicateur de laboratoire utile au diagnostic.

Le Cumulative Layout Shift mesure les déplacements inattendus du contenu visible. Une image sans espace réservé, un composant injecté tardivement ou certaines polices peuvent déplacer un bouton ou un texte pendant la consultation.

Déclarez les dimensions des médias, réservez l’espace des composants chargés plus tard et observez les déplacements sur de vrais parcours. Un test de chargement initial ne révèle pas nécessairement un décalage survenant après une interaction.

PageSpeed Insights peut afficher des données de terrain issues du Chrome User Experience Report lorsqu’il dispose d’un échantillon suffisant. Il fournit aussi un test Lighthouse dans un environnement simulé. Les premières décrivent des visites passées ; le second aide à reproduire et déboguer.

• Les deux peuvent diverger à cause des appareils, réseaux, contenus et interactions.
• Utilisez les données réelles pour suivre l’expérience obtenue et le laboratoire pour rechercher les causes.
• L’absence de données de terrain ne signifie ni que la page est bonne ni qu’elle est mauvaise.

Les données de terrain proviennent du Chrome User Experience Report, alimenté par les visiteurs qui utilisent Chrome, ont accepté le partage de statistiques d’usage et consultent une page publique. Elles sont agrégées sur vingt-huit jours glissants et publiées par URL quand le volume suffit, sinon par origine, c’est-à-dire pour l’ensemble du site.

Un site de PME bruxelloise avec quelques centaines de visites par mois n’atteint souvent pas le seuil par URL et parfois pas le seuil par origine. Dans ce cas, PageSpeed Insights n’affiche que le test de laboratoire, et Search Console ne remplit pas le rapport Core Web Vitals. Ce n’est pas un défaut du site, c’est une limite statistique.

Deux solutions existent. La première : installer une mesure de terrain propre au site, via une petite bibliothèque qui envoie LCP, INP et CLS de chaque visite vers un outil d’analyse, ce qui donne des données réelles dès les premiers visiteurs. La seconde : accepter le laboratoire comme guide et vérifier sur de vrais appareils, en simulant une connexion mobile moyenne.

Le temps jusqu’au LCP se décompose en quatre morceaux : le temps de réponse du serveur pour le HTML, le délai avant que le navigateur ne demande la ressource principale, le temps de chargement de cette ressource, et le délai entre son arrivée et son rendu. Chaque morceau a ses causes et ses corrections.

Un serveur lent — hébergement mutualisé saturé, CMS sans cache, redirection en chaîne — se corrige par la mise en cache ou le changement d’hébergement. Un délai de découverte élevé signifie que l’image principale est chargée par du JavaScript ou par du CSS plutôt que déclarée dans le HTML ; la solution est de la déclarer directement et de la marquer prioritaire.

• Un chargement long vient du poids ou du format de l’image, et se corrige par redimensionnement et conversion.
• Un rendu tardif après l’arrivée indique que du CSS ou du JavaScript bloquant retient l’affichage.
• Mesurer les quatre parties, ce que les outils de développement des navigateurs permettent, évite de corriger au hasard.

L’INP retient, pour une visite, l’une des interactions les plus lentes — clic, toucher, frappe — en excluant les cas extrêmes. Une page peut donc être rapide au chargement et mauvaise en INP si l’ouverture du menu mobile, la sélection d’une variante ou la validation d’un formulaire déclenche un travail lourd.

Les coupables habituels sont des scripts tiers qui écoutent chaque clic, des bibliothèques d’animation qui recalculent toute la page, des gestionnaires d’événements qui font trop de choses de façon synchrone, et des sites entièrement rendus côté client sur des téléphones modestes. Le Total Blocking Time du laboratoire aide à repérer les longues tâches, mais seule la mesure de terrain identifie l’interaction précise.

Les corrections consistent à faire moins de travail à l’interaction : reporter ce qui n’est pas nécessaire au retour visuel immédiat, découper les longues tâches, retirer les scripts qui n’apportent rien, et donner un retour visuel instantané même si le traitement continue derrière. Une page qui répond en moins de deux cents millisecondes paraît instantanée, quel que soit le temps total.

Un test de laboratoire mesure le CLS pendant le chargement initial, sur une fenêtre fixe. Les décalages réels arrivent souvent plus tard : un bandeau de consentement qui pousse tout le contenu vers le bas au lieu de se superposer, une image chargée au défilement sans espace réservé, une police de remplacement remplacée par la police finale avec une largeur différente, un encart qui s’insère après un appel réseau.

Pour les trouver, naviguez sur le site avec un téléphone réel et une connexion ralentie, en regardant ce qui bouge. Les outils de développement des navigateurs peuvent aussi enregistrer une session et lister chaque décalage avec l’élément responsable.

Les corrections sont presque toujours les mêmes : déclarer les dimensions de chaque image et vidéo, réserver l’espace des composants insérés plus tard, superposer les bandeaux au lieu de les insérer dans le flux, et régler l’affichage des polices pour limiter le changement de largeur. Aucune ne demande de refonte ; toutes demandent d’avoir vu le décalage.

Une fois par mois, ouvrez le rapport Core Web Vitals de Search Console s’il est disponible, et notez le nombre d’URL bonnes, à améliorer et mauvaises, sur mobile et sur ordinateur. Une variation d’un mois à l’autre est un signal, pas une alerte ; deux mois consécutifs dans le même sens méritent une enquête.

Testez ensuite trois gabarits représentatifs — accueil, page de service ou de produit, article — dans PageSpeed Insights, et comparez les métriques de laboratoire à celles du mois précédent, en gardant à l’esprit qu’elles varient de quelques pour cent d’un test à l’autre. Notez les résultats dans un tableau simple, avec la date et les changements faits sur le site entre-temps.

Ce tableau devient la mémoire du site. Quand une métrique se dégrade, il montre quelle mise en production a coïncidé avec la dégradation, ce qui réduit l’enquête à quelques minutes. Sans lui, chaque problème de performance repart de zéro.

Google recommande de bons Core Web Vitals pour l’expérience utilisateur et indique que cette recommandation, avec d’autres aspects de l’expérience sur la page, correspond à ce que ses principaux systèmes de classement cherchent à récompenser. Un score vert ne garantit toutefois ni position, ni trafic, ni conversion.

Commencez par les modèles de page et la métrique qui posent problème, confirmez la cause, corrigez-la, testez la régression puis surveillez les données de terrain. Le temps et l’effort nécessaires ne peuvent être estimés sérieusement avant le diagnostic.