Core Web Vitals, ce que Google mesure vraiment (LCP, INP, CLS)

Elles portent des noms anglais et des sigles, ce qui décourage tout le monde. Elles recouvrent pourtant 3 questions très simples.

LCP, la vitesse d’affichage. Au bout de combien de temps le plus gros élément de la page apparaît-il ? En général votre image principale ou votre titre. Seuil, moins de 2,5 secondes. Le coupable habituel est une image trop lourde.

INP, la réactivité. Quand le visiteur clique, en combien de temps la page réagit-elle ? Seuil, moins de 200 millisecondes. Le coupable habituel est un excès de code JavaScript à exécuter.

CLS, la stabilité. Est-ce que le contenu bouge pendant le chargement ? Vous connaissez la situation, vous visez un bouton et la page se réorganise sous votre doigt. Seuil, moins de 0,1. Les coupables habituels sont les images sans dimensions déclarées et les bandeaux publicitaires.

Et une 4e mesure qui n’en est pas une, le TTFB. Le délai avant le premier octet, c’est-à-dire le temps que met votre serveur à commencer à répondre. Il ne compte pas officiellement, mais rien ne peut s’afficher avant lui. Un TTFB médiocre plombe le LCP sans qu’on comprenne pourquoi.

Une affirmation circule beaucoup en ce moment, et elle est fausse. Nous la traitons ici parce qu’elle pousse des entreprises à dépenser dans l’urgence.

Ce qu’on entend. Google aurait agrégé les 3 mesures en un score composite, et l’on ne pourrait plus compenser une mauvaise mesure par 2 bonnes.

Ce que dit la documentation de Google. Une page est jugée bonne si elle atteint les seuils recommandés pour les 3 mesures, au 75e centile des visites. Autrement dit, il a toujours fallu passer les 3. Il n’y a jamais eu de compensation, donc il n’y a rien de nouveau à annoncer.

Le 75e centile, ce que ça veut dire. On ne regarde pas votre visiteur moyen, on regarde le quart le plus mal servi. Il faut donc que 3 visites sur 4 tiennent le seuil. C’est exigeant, et c’est volontaire, parce qu’une moyenne masque toujours les visiteurs qui souffrent.

Le signal d’alerte. Quand un contenu annonce un bouleversement sans citer la page de documentation qui l’établit, il vend de l’urgence. C’est le même réflexe que pour les astuces de croissance sans date.

C’est la partie que personne ne cite, alors qu’elle décide de l’effort que vous devriez y consacrer.

Il n’existe aucun signal de classement unique. Google écrit noir sur blanc qu’une bonne note à ces mesures ne garantit pas de bien se classer, et que l’expérience de page ne se réduit pas à ces scores.

Le critère joue surtout comme départage. Google précise que l’expérience de page compte davantage quand plusieurs contenus utiles répondent à la même question, et beaucoup moins quand un seul convient vraiment. Traduction, la vitesse vous départage à contenu équivalent. Elle ne remplace pas un contenu qui répond mieux.

Ce que ça change dans vos priorités. Un internaute accepte d’attendre une page lente qui répond exactement à sa question. Il quitte une page rapide qui ne répond qu’à moitié. Si vous devez choisir entre écrire la page qui manque et gagner 300 millisecondes, écrivez la page.

Et là où la vitesse compte vraiment. Pas dans le classement, dans la conversion. Un formulaire qui rame et un bouton qui se dérobe coûtent des contacts tous les jours, quelle que soit votre position dans les résultats.

Les 3 mesures deviennent beaucoup plus claires quand on sait ce qui les dégrade. Dans presque tous les cas, c’est l’un de ces 3 mécanismes.

Pour l’affichage, un script qui bloque la lecture de la page. Le navigateur lit votre page de haut en bas. S’il croise un fichier de code dans l’en-tête, il s’arrête le temps de le télécharger et de l’exécuter. Il n’a donc pas encore atteint la ligne où se trouve votre image principale, et celle-ci ne commence à être téléchargée qu’après. Le remède tient en un mot posé sur le script, defer, qui autorise le navigateur à continuer sa lecture.

Pour la stabilité, une image dont on ignore la taille. Le navigateur ne peut pas réserver la place d’un élément dont il ne connaît pas les dimensions. Il pose donc le reste de la page, puis il l’écarte quand l’image arrive. Déclarer la largeur et la hauteur suffit à obtenir une mesure à zéro, même en connexion lente, puisque la place est réservée avant l’arrivée du fichier.

Pour la réactivité, une tâche trop longue. Le navigateur ne fait qu’une chose à la fois. Si un clic déclenche un traitement de 2 secondes, tout le reste attend, y compris l’affichage. Rien ne bouge, l’internaute reclique, et ça empire. Le remède est de découper le travail en petits morceaux et de rendre la main entre chacun, pour que la page reste vivante pendant le calcul.

Ce que ça vous dit en tant que dirigeant. Ces 3 remèdes sont du ressort de celui qui a fait votre site, pas du vôtre. Mais savoir les nommer change la conversation, et vous saurez si on vous répond ou si on vous noie.

3 outils, gratuits, et il faut les prendre dans cet ordre pour ne pas se tromper de diagnostic.

• La Search Console, rubrique expérience sur la page. C’est la vue d’ensemble, elle vous dit combien de vos adresses sont bonnes, à améliorer ou mauvaises.
• PageSpeed Insights, pour une page précise. ⚠ Il affiche 2 blocs très différents, et confondre les 2 est l’erreur la plus répandue, cf le score à 100 qui ne sert à rien.
• Les outils de développement du navigateur, pour le diagnostic fin, une fois qu’on sait quoi chercher.

Le piège du classement par gravité. La Search Console trie par nombre d’adresses concernées. Une alerte sur 400 pages de blog peu visitées passe donc devant une alerte sur votre page de contact. Commencez toujours par les pages qui rapportent, pas par celles qui sont nombreuses.

Si vous êtes un commerce local, votre situation est particulière et souvent mal comprise, nous la traitons à part dans la vitesse d’un site de commerce local.