Core Web Vitals : pourquoi la vitesse compte pour votre référencement ?
LCP, INP et CLS expliqués avec des exemples concrets pour comprendre la vitesse de votre site, son référencement et les corrections utiles sur mobile.
Sur cette page6 sections
Vous avez sûrement déjà voulu appuyer sur un bouton qui s'est déplacé au dernier moment. Une image arrive, la page descend, et votre doigt ouvre autre chose. Ou le menu semble ne pas répondre : vous appuyez une deuxième fois, puis tout se déclenche d'un coup.
Quand on parle d'un site lent, on mélange souvent ces situations avec le temps nécessaire pour afficher la page. Pourtant, on peut avoir un site qui apparaît vite et qui devient pénible dès qu'on essaie de l'utiliser. Les Core Web Vitals servent à mettre des noms et des mesures sur ces sensations, plutôt qu'à répondre « chez moi, ça va ».
L'INP, pour Interaction to Next Paint, s'intéresse à la réponse visible après une interaction. Vous touchez le menu : combien de temps avant de voir quelque chose se passer ? Il regarde les interactions pendant la visite, pas seulement le premier clic. Un navigateur occupé par de gros traitements peut laisser votre geste en attente même si le serveur a déjà envoyé toute la page.
Le CLS, pour Cumulative Layout Shift, mesure les déplacements inattendus de la mise en page. C'est le cas du bouton qui vous échappe sous le doigt parce qu'un bloc prend sa place. Faire défiler volontairement une page n'est pas la même chose : on cherche ici les changements de position que l'utilisateur n'a pas demandés.
Les repères publiés par Google sur web.dev sont un LCP de 2,5 secondes au plus, un INP de 200 millisecondes au plus et un CLS de 0,1 au plus. Ils s'évaluent au 75e percentile, séparément sur mobile et ordinateur : pour chaque indicateur, au moins 75 % des visites mesurées doivent rester dans le seuil recommandé. Ce n'est donc pas votre meilleur essai qui décide si l'expérience est bonne.
Une page rapide qui n'explique pas votre prestation reste une page qui n'explique pas votre prestation. Si votre visiteur cherche un dépannage dans sa ville et qu'il trouve une présentation vague de l'entreprise, gagner quelques dixièmes de seconde ne répondra pas à sa question.
En revanche, il est dommage de travailler le référencement, de faire venir les bonnes personnes et de leur proposer ensuite un parcours qui les empêche de vous contacter. La performance sert d'abord à ne pas gâcher cette visite. C'est pour cette raison que je préfère commencer par les pages de services et le formulaire plutôt que par une page secondaire facile à faire monter à 100.
PageSpeed Insights présente un test simulé et, lorsqu'il dispose de suffisamment de données, des mesures issues de visites réelles. Le test aide à reproduire les causes d'un problème. Les données de terrain montrent ce qui s'est passé pour les visiteurs sur une période, avec leurs propres conditions.
Un petit site peut manquer de données de terrain à l'échelle d'une page. Ce n'est pas un résultat parfait ni un échec : c'est une information indisponible. Et si l'outil affiche les résultats de l'ensemble du domaine, il faut le savoir avant de les présenter comme ceux du formulaire que vous venez de tester.
Le score Lighthouse n'est pas non plus une mesure complète des interactions réelles de vos visiteurs. Un test de chargement automatique ne passe pas plusieurs minutes à ouvrir le menu et à remplir vos champs. Il faut donc garder les deux regards : le diagnostic technique et le parcours effectué à la main.
Un cache comme Varnish peut accélérer la réponse. Il ne rend pas automatiquement légère une photo de plusieurs mégaoctets, et il n'empêche pas un script de bloquer le menu. Changer d'hébergement sans regarder ce qui se passe après la réponse revient parfois à accélérer la livraison d'un colis dont personne n'arrive à déballer le contenu.
Pour le LCP, on regarde notamment le délai du serveur et ce qui retarde l'image ou le texte principal. Pour l'INP, on examine le travail demandé au navigateur au moment des interactions. Pour le CLS, on réserve la place des images et des contenus qui arrivent plus tard, afin qu'ils ne poussent pas le reste de la page.
On peut alors traiter une cause à la fois : réduire une image à une taille adaptée, retirer un widget inutilisé, limiter les scripts chargés d'entrée ou prévoir l'espace occupé par un visuel. Puis on rejoue le même scénario sur mobile. Si l'on change tout simultanément, il devient difficile de savoir ce qui a réellement amélioré la visite.
Il faut aussi vérifier que l'on n'a pas sacrifié ce qui était utile pour gagner des points. Une page vide se charge vite. Ce n'est pas pour autant une bonne page commerciale. L'objectif est de rendre votre contenu accessible rapidement, pas de le supprimer jusqu'à obtenir une bonne note.
L'article sur le site mobile complète cette lecture : un indicateur vous dit où regarder, mais il ne vérifie pas que la demande est bien arrivée dans votre boîte mail.
Les Core Web Vitals sont utiles quand ils donnent une explication à ce que le visiteur subit. Si le diagnostic permet enfin de comprendre pourquoi le menu ne répond pas, on a gagné quelque chose. Si l'on ne fait que collectionner des captures de scores verts, on a surtout gagné des captures.
Quand on parle d'un site lent, on mélange souvent ces situations avec le temps nécessaire pour afficher la page. Pourtant, on peut avoir un site qui apparaît vite et qui devient pénible dès qu'on essaie de l'utiliser. Les Core Web Vitals servent à mettre des noms et des mesures sur ces sensations, plutôt qu'à répondre « chez moi, ça va ».
Trois mesures pour trois moments de la visite
Le LCP, pour Largest Contentful Paint, observe l'affichage du plus grand élément de contenu visible au chargement, souvent une grande image ou un bloc de texte. Il ne mesure pas la fin de tous les téléchargements. Il aide à comprendre à quel moment une partie importante du premier écran devient effectivement visible.L'INP, pour Interaction to Next Paint, s'intéresse à la réponse visible après une interaction. Vous touchez le menu : combien de temps avant de voir quelque chose se passer ? Il regarde les interactions pendant la visite, pas seulement le premier clic. Un navigateur occupé par de gros traitements peut laisser votre geste en attente même si le serveur a déjà envoyé toute la page.
Le CLS, pour Cumulative Layout Shift, mesure les déplacements inattendus de la mise en page. C'est le cas du bouton qui vous échappe sous le doigt parce qu'un bloc prend sa place. Faire défiler volontairement une page n'est pas la même chose : on cherche ici les changements de position que l'utilisateur n'a pas demandés.
Les repères publiés par Google sur web.dev sont un LCP de 2,5 secondes au plus, un INP de 200 millisecondes au plus et un CLS de 0,1 au plus. Ils s'évaluent au 75e percentile, séparément sur mobile et ordinateur : pour chaque indicateur, au moins 75 % des visites mesurées doivent rester dans le seuil recommandé. Ce n'est donc pas votre meilleur essai qui décide si l'expérience est bonne.
Et Google dans tout ça
Oui, les Core Web Vitals interviennent dans les systèmes de classement de Google. Non, passer toutes les mesures au vert ne vous garantit pas la première place. Google le précise dans sa documentation : de bons résultats ne suffisent pas à obtenir un bon classement.Une page rapide qui n'explique pas votre prestation reste une page qui n'explique pas votre prestation. Si votre visiteur cherche un dépannage dans sa ville et qu'il trouve une présentation vague de l'entreprise, gagner quelques dixièmes de seconde ne répondra pas à sa question.
En revanche, il est dommage de travailler le référencement, de faire venir les bonnes personnes et de leur proposer ensuite un parcours qui les empêche de vous contacter. La performance sert d'abord à ne pas gâcher cette visite. C'est pour cette raison que je préfère commencer par les pages de services et le formulaire plutôt que par une page secondaire facile à faire monter à 100.
Pourquoi votre téléphone et le test ne racontent pas la même histoire
Vous connaissez votre site, vous l'avez déjà ouvert, ses fichiers sont peut-être en cache et vous êtes connecté au Wi-Fi. La personne qui le découvre a un autre téléphone, d'autres applications en cours et une connexion qui peut varier. Vous n'êtes pas en train de vivre la même visite.PageSpeed Insights présente un test simulé et, lorsqu'il dispose de suffisamment de données, des mesures issues de visites réelles. Le test aide à reproduire les causes d'un problème. Les données de terrain montrent ce qui s'est passé pour les visiteurs sur une période, avec leurs propres conditions.
Un petit site peut manquer de données de terrain à l'échelle d'une page. Ce n'est pas un résultat parfait ni un échec : c'est une information indisponible. Et si l'outil affiche les résultats de l'ensemble du domaine, il faut le savoir avant de les présenter comme ceux du formulaire que vous venez de tester.
Le score Lighthouse n'est pas non plus une mesure complète des interactions réelles de vos visiteurs. Un test de chargement automatique ne passe pas plusieurs minutes à ouvrir le menu et à remplir vos champs. Il faut donc garder les deux regards : le diagnostic technique et le parcours effectué à la main.
Le serveur a répondu, mais le visiteur attend encore
Imaginez une livraison. Le colis est arrivé à l'entrée, mais il reste à l'ouvrir et à installer ce qu'il contient. Une réponse rapide du serveur est un bon début ; le navigateur doit encore télécharger les images, comprendre les styles, préparer l'affichage et exécuter les scripts.Un cache comme Varnish peut accélérer la réponse. Il ne rend pas automatiquement légère une photo de plusieurs mégaoctets, et il n'empêche pas un script de bloquer le menu. Changer d'hébergement sans regarder ce qui se passe après la réponse revient parfois à accélérer la livraison d'un colis dont personne n'arrive à déballer le contenu.
Pour le LCP, on regarde notamment le délai du serveur et ce qui retarde l'image ou le texte principal. Pour l'INP, on examine le travail demandé au navigateur au moment des interactions. Pour le CLS, on réserve la place des images et des contenus qui arrivent plus tard, afin qu'ils ne poussent pas le reste de la page.
Ce qu'on corrige en premier
Je commence par ce qui empêche une personne de faire quelque chose d'utile. Un menu bloqué ou un bouton qui bouge mérite souvent davantage d'attention qu'un détail technique sans conséquence perceptible sur le parcours.On peut alors traiter une cause à la fois : réduire une image à une taille adaptée, retirer un widget inutilisé, limiter les scripts chargés d'entrée ou prévoir l'espace occupé par un visuel. Puis on rejoue le même scénario sur mobile. Si l'on change tout simultanément, il devient difficile de savoir ce qui a réellement amélioré la visite.
Il faut aussi vérifier que l'on n'a pas sacrifié ce qui était utile pour gagner des points. Une page vide se charge vite. Ce n'est pas pour autant une bonne page commerciale. L'objectif est de rendre votre contenu accessible rapidement, pas de le supprimer jusqu'à obtenir une bonne note.
Un suivi qui aide à décider
Choisissez quelques pages qui comptent : une prestation, une réalisation, les tarifs si vous en avez et le contact. Notez ce qui semble lent, mesurez-le, corrigez, puis vérifiez à nouveau dans les mêmes conditions. Les données de terrain mettent plus de temps à refléter une modification, puisqu'elles portent sur une période de visites.L'article sur le site mobile complète cette lecture : un indicateur vous dit où regarder, mais il ne vérifie pas que la demande est bien arrivée dans votre boîte mail.
Les Core Web Vitals sont utiles quand ils donnent une explication à ce que le visiteur subit. Si le diagnostic permet enfin de comprendre pourquoi le menu ne répond pas, on a gagné quelque chose. Si l'on ne fait que collectionner des captures de scores verts, on a surtout gagné des captures.
