Ce que Core Web Vitals Mesurent Réellement, et Lequel vous Pouvez Ressentir

Core Web Vitals sont trois nombres, et presque tout ce qui en est écrit explique ce qu’ils mesurent. La question la plus utile est dont ils mesurent l’expérience, car la réponse est dans la définition et elle décide ce que vous pouvez conclure d’un score vert.

Les trois et celui qui a disparu

Les seuils propres de Google, en trois bandes chacun :

• Largest Contentful Paint (LCP): Bon 2500 ms or less, A améliorer 2501 to 4000 ms, Mauvais over 4000 ms.
• Interaction to Next Paint (INP): Bon 200 ms or less, A améliorer 201 to 500 ms, Mauvais over 500 ms.
• Cumulative Layout Shift (CLS): Bon 0.1 or less, A améliorer 0.11 to 0.25, Mauvais over 0.25.

LCP est le chargement : combien de temps jusqu’à ce que la plus grande chose de l’écran arrive. INP est l’interactivité : vous touchez quelque chose, et combien de temps avant que la page affiche une réponse. CLS est la stabilité visuelle, et c’est le seul qui n’est pas une durée ; c’est un score de combien la mise en page a bougé après que vous ayez pu la voir.

First Input Delay n’en fait plus partie. INP a remplacé FID et est devenu stable en 2024, ce qui importe principalement parce que tout guide écrit avant cela nomme une métrique qui n’est plus mesurée. Si quelqu’un vous remet un rapport de performance avec une colonne FID, il vous parle d’un web différent.

Lequel vous pouvez ressentir

C’est la partie qui vaut la peine d’avoir, car un utilisateur ne signale jamais une métrique. Il signale une sensation, et la sensation vous dit lequel des trois regarder.

« J’ai attendu en regardant rien. » C’est le LCP. La page a été atteinte, le serveur a répondu, et la chose pour laquelle la personne est venue n’était pas arrivée. Rien n’est cassé et rien n’a d’erreur.

« Je l’ai touché et rien ne s’est passé, alors je l’ai touché à nouveau. » C’est le INP, et le deuxième appui est la moitié diagnostique. Une page qui n’affiche pas de réponse en quelques centaines de millisecondes se fait appuyer deux fois, ce qui est ainsi qu’une action intentionnelle devient deux soumises.

« Ça a sauté et j’ai appuyé sur la mauvaise chose. » C’est le CLS. Une image tardive ou une police web arrivant après le premier affichage pousse le bouton ailleurs entre le moment où l’oeil décide et le moment où le doigt atterrit.

Donc « le site se sent lent » est au moins trois défauts différents, et les mots que quelqu’un choisit le réduisent avant que vous ayez mesuré quoi que ce soit. C’est d’une valeur supérieure à ce qu’il semble, car les trois n’ont rien en commun en dessous : LCP est généralement des octets et des allers-retours, INP est généralement du JavaScript occupant le thread principal, et CLS est généralement une mise en page pour laquelle vous n’aviez pas réservé d’espace.

Le 75e percentile c’est toute l’histoire

Voici la phrase qui change comment vous lisez un score. L’évaluation est faite au 75e percentile des chargements de page, segmentés entre appareils mobiles et de bureau.

Pas la moyenne, et pas votre visite. Trois quarts des chargements doivent être au seuil ou en dessous pour qu’une page passe, ce qui signifie un chargement sur quatre est autorisé à être pire que votre nombre vert tandis que le nombre reste vert. Ce n’est pas un défaut de la métrique ; c’est ce que dit la métrique.

Le raisonnement de Google pour choisir ce percentile est publié et vaut la peine de connaître, car il explique pourquoi la queue est délibérée : le 75e assure qu’une majorité de visites a expérimenté le niveau de performance cible, tandis que les percentiles plus élevés donnent un poids indu aux mauvaises expériences sporadiques. Avec cent visites, déplacer la barre au 75e percentile nécessite que vingt-cinq d’entre elles soient affectées avant que le score ne se déplace. Au 95e il en faut cinq.

Ainsi, la décision de conception consiste à être robuste contre les valeurs aberrantes. Le coût de cette robustesse est qu’un vrai problème répétable affectant un cinquième de vos visiteurs peut rester sous un score de passage indéfiniment.

Pourquoi votre propre expérience n’est jamais la mesure

Ouvrez votre propre site et vous êtes presque certainement dans les trois quarts confortables, et pas par chance. Vous êtes sur une machine choisie pour le travail de développement, sur une connexion que vous payez, avec le cache déjà réchauffé, les polices déjà téléchargées et le service worker déjà installé, probablement près d’un emplacement de limite qui vous sert en millisecondes à un seul chiffre.

Le quart lent est quelqu’un sur un téléphone de milieu de gamme dans un train avec un cache froid. Ils ne sont pas une anomalie. Ils sont la partie de la mesure que vous ne pouvez pas atteindre à partir de votre bureau, ce qui est aussi la partie que le score est conçu pour tolérer.

C’est pourquoi « c’est bien pour moi » est une vraie déclaration et non une preuve de quoi que ce soit, et pourquoi une page peut se sentir lente tandis que chaque métrique serveur dit qu’elle est rapide.

Ce qu’un score de terrain ne peut pas faire

Core Web Vitals tels que Google les évalue sont des données de terrain : un agrégat sur une population de vraies visites. C’est ce qui les rend utiles, et c’est aussi la limite.

Un agrégat ne peut pas répondre à une question sur une seule visite. Quand une personne spécifique dit que le paiement était inutilisable mardi après-midi, aucun percentile ne vous dit ce qui leur est arrivé, et une page qui passe vous dit seulement qu’au moins trois quarts des visites étaient bien. La plainte vient tout à fait possiblement du quart que le seuil a été conçu pour absorber.

Ainsi, les deux choses font des travaux différents et ni l’un ni l’autre ne se substitue à l’autre. Le score de terrain vous dit si l’expérience est largement acceptable et où dépenser le temps d’ingénierie. Une visite capturée vous dit ce qui s’est passé pour la personne en face de vous. Atteindre le premier quand quelqu’un vous demande du deuxième est comment un vrai rapport se ferme comme non reproductible.

Que faire avec une plainte de lenteur

Trois étapes, dans l’ordre qui coûte le moins.

Lisez les mots de la métrique. En attente, qui ne répond pas ou qui bouge. Cela seul choisit lequel des trois enquêter et élimine les deux autres.

Obtenez la seule visite plutôt que l’agrégat. Quand cela s’est passé, sur quel appareil et connexion, et ce que la page faisait à ce moment. Un percentile ne peut pas être réduit à une personne, mais une session capturée l’est déjà.

Ensuite vérifiez le score de terrain, pour découvrir si vous chassez la queue ou le milieu. Si la page passe et la plainte est réelle, vous êtes dans le quart conçu, et cela change la décision plutôt que de la terminer.

En un paragraphe

Core Web Vitals sont LCP à 2500 ms, INP à 200 ms et CLS à 0,1, évalués au 75e percentile des chargements et divisés entre mobile et bureau, avec FID retraité en faveur de INP. Chacun correspond à une plainte qu’une personne fait réellement : attendre, appuyer deux fois, ou appuyer sur le mauvais bouton. Et le percentile signifie qu’un quart de vos visites sont autorisées à être pire que votre score de passage, ce qui est pourquoi un tableau de bord vert et un utilisateur mécontent sont généralement tous deux corrects, et pourquoi le régler a besoin d’une visite capturée plutôt qu’une meilleure moyenne.