Core Web Vitals : mesurer LCP, INP et CLS, puis corriger son site
Un diagnostic concret des Core Web Vitals : seuils Google, données réelles et tests de laboratoire, avec l’exemple documenté de la refonte Sanegon.
Une page peut afficher un bon score de performance et rester difficile à utiliser. Pour décider quoi corriger, il faut comprendre ce que mesure chaque indicateur, sur quelle page et dans quelles conditions. Voici une méthode applicable à un site vitrine, un portfolio ou une boutique.
Les trois indicateurs à lire
Le LCP mesure l’apparition du plus grand contenu visible, l’INP la réactivité aux interactions et le CLS les déplacements inattendus de la mise en page. Les seuils « bons » sont respectivement 2,5 secondes, 200 millisecondes et 0,1, évalués au 75e percentile, séparément sur mobile et ordinateur. INP a remplacé FID en mars 2024. Définition et seuils Google.
Ces indicateurs contribuent aux systèmes de classement de Google, mais de bons résultats ne garantissent pas une position. Ils ne remplacent ni un contenu pertinent ni une offre claire. Expérience sur la page et recherche Google.
Commencer par une mesure exploitable
Ouvrez PageSpeed Insights avec l’adresse exacte de la page. Séparez les données d’utilisateurs réels, lorsqu’elles existent, du test Lighthouse réalisé à cet instant. Notez la date, le mode mobile ou ordinateur, l’URL et les conditions du test.
Sur un site peu visité, les données de terrain peuvent manquer. Cela ne signifie ni que la page est rapide ni qu’elle échoue. Utilisez alors le laboratoire pour trouver des causes, puis testez vous-même les actions importantes : ouvrir le menu, filtrer des produits, envoyer un formulaire.
Ne comparez pas le score d’un accueil sur ordinateur avec celui d’une page produit sur mobile. Rejouez le même scénario après la correction et conservez les deux rapports.
Exemple documenté : la refonte Sanegon
L’étude de cas Sanegon présente un relevé mobile du 25 juillet 2026. Le nouveau site obtenait un score Lighthouse Performance de 95/100, contre 67/100 pour l’ancienne version. Le LCP du test passait de 4,8 à 2,9 secondes et le CLS de 0,227 à 0.
Cet exemple montre pourquoi il faut lire les métriques : 95/100 ne signifie pas que le LCP respecte déjà la cible de 2,5 secondes. Il s’agit de mesures de laboratoire datées, pas d’une preuve de hausse des ventes ou de validation des Core Web Vitals chez les visiteurs réels. Les liens vers les outils et le périmètre de la comparaison figurent dans l’étude de cas.
Corriger selon le symptôme
LCP lent : trouver ce qui retarde le contenu principal
Identifiez l’élément concerné avant de modifier le site. Pour une grande photo, vérifiez le fichier réellement téléchargé, ses dimensions et son ordre de chargement. Une image principale ne doit pas attendre un défilement ou l’ouverture d’un composant. Pour un titre, examinez le chargement des polices et les styles nécessaires à son affichage.
Si la réponse HTML arrive tard, cherchez du côté du serveur et du cache. Compresser une photographie ne corrigera pas une requête serveur bloquée. Le guide des images détaille le diagnostic visuel.
Interaction lente : reproduire une action précise
Un menu peut être rapide alors qu’un filtre de catalogue bloque. Enregistrez l’action problématique dans les outils de performance du navigateur. Cherchez les calculs, les composants ou les scripts tiers exécutés au clic. Découpez les traitements longs et affichez un retour immédiat à l’utilisateur.
Sur le catalogue LR Studios, la fonction essentielle consiste à trouver un jeu puis accéder à sa plateforme de téléchargement. Un parcours simple sert ici davantage le besoin qu’un système d’animation complexe.
Mise en page instable : réserver la place nécessaire
Donnez un ratio aux images et aux vidéos. Prévoyez l’emplacement des messages de formulaire et des contenus intégrés. Rechargez avec un réseau ralenti et observez les boutons : aucun ne devrait se déplacer sous le doigt quand un autre élément apparaît.
Un contrôle avant chaque publication
Gardez une petite liste de pages représentatives : accueil, prestation principale, article, réalisation ou produit. Pour chacune, vérifiez le chargement, une interaction et la stabilité visuelle. Notez la correction et son résultat. Une amélioration mesurée sur une page ne doit pas masquer une régression ailleurs.
Pour préparer un diagnostic, envoyez l’URL, l’action qui pose problème et un rapport daté. Mes prestations de performance et de refonte partent de ces observations pour définir les travaux utiles.