Mesurer un site web : les Core Web Vitals sans jargon

Un site « rapide » ne veut pas dire grand-chose. Rapide à charger, à réagir, à lire sans que le texte saute ? Pour que la discussion repose sur autre chose que des impressions, Google a défini un petit ensemble de mesures appelées Core Web Vitals, qui visent à résumer ce qu’un visiteur ressent réellement. Elles sont trois, et elles sont plus simples qu’il n’y paraît.

Les trois mesures

LCP : quand le contenu principal apparaît

Le Largest Contentful Paint mesure le moment où le plus grand élément visible de la page, le plus souvent l’image principale ou un gros titre, est affiché. C’est une bonne approximation de l’instant où le visiteur a le sentiment que la page est là. Le seuil publié pour considérer le résultat comme bon est de 2,5 secondes ou moins.

INP : la réactivité quand on interagit

L’Interaction to Next Paint observe toutes les interactions d’une visite (clics, appuis, saisies au clavier) et retient une valeur proche de la pire : le délai entre le geste et le moment où l’écran se met à jour. Elle a remplacé en 2024 la mesure précédente, qui ne regardait que la toute première interaction. Un bon résultat est de 200 millisecondes ou moins.

CLS : la stabilité de la mise en page

Le Cumulative Layout Shift mesure à quel point les éléments bougent de façon inattendue pendant le chargement. Chacun a vécu ce moment où l’on s’apprête à cliquer sur un bouton et où une image, chargée en retard, le fait glisser vers le bas. Le score est sans unité, et un bon résultat est de 0,1 ou moins.

Ces seuils sont évalués sur le 75e centile des visites réelles : pour que la page soit considérée comme bonne, trois visiteurs sur quatre doivent avoir une expérience au moins aussi bonne que le seuil. Un site dont la moyenne est excellente mais dont un quart des visiteurs, souvent sur mobile, attendent longtemps, ne passe pas.

Laboratoire ou terrain : deux réponses différentes

C’est la source de confusion la plus fréquente. Il existe deux façons de mesurer, et elles ne répondent pas à la même question.

• Les mesures en laboratoire chargent la page dans un environnement contrôlé, avec un appareil et une connexion simulés. Lighthouse en est l’exemple connu. Elles sont reproductibles, idéales pour déboguer et comparer un avant et un après, mais elles ne disent pas ce que vivent vos visiteurs.
• Les mesures de terrain collectent les valeurs de vraies visites, avec leurs appareils et leurs réseaux très variés. Le rapport d’expérience utilisateur de Chrome, qu’alimentent les navigateurs des visiteurs consentants, en est la source publique, et on peut aussi collecter ses propres mesures avec la bibliothèque web-vitals.

Les deux divergent souvent. Un score Lighthouse excellent sur votre ordinateur de développement et une expérience médiocre sur un téléphone d’entrée de gamme en 4G ne sont pas contradictoires : ils mesurent des choses différentes. Le laboratoire sert à comprendre et à corriger, le terrain à savoir si l’on a réussi.

Les outils, et à quoi ils servent

• PageSpeed Insights affiche à la fois des données de terrain, quand il y en a assez pour votre adresse, et un test en laboratoire.
• Lighthouse, dans les outils de développement de Chrome, pour un diagnostic détaillé et des pistes d’amélioration.
• L’onglet Performance des mêmes outils, pour voir précisément ce qui occupe le navigateur et quand.
• Le rapport Core Web Vitals de la Search Console, qui regroupe vos pages par type de problème.
• La bibliothèque `web-vitals`, pour envoyer vos propres mesures de terrain vers l’outil d’analyse de votre choix.

Améliorer le LCP

Le LCP est presque toujours une affaire d’image principale ou de temps de réponse du serveur. Quelques pistes, par ordre d’efficacité habituelle :

1. Ne pas retarder l’élément principal. Une image placée en haut de page ne doit jamais être chargée en différé : le chargement paresseux est pour ce qui est hors écran. On peut lui donner une priorité haute avec fetchpriority="high".
2. Servir une image à la bonne taille, dans un format moderne comme WebP ou AVIF, avec des variantes déclarées par srcset pour que le mobile ne télécharge pas l’image du grand écran.
3. Réduire le temps de réponse du serveur : mise en cache, rendu côté serveur efficace, distribution depuis un point proche du visiteur.
4. Ne pas bloquer l’affichage avec des feuilles de style ou des scripts volumineux chargés avant le contenu.
5. Précharger la police utilisée par le gros titre, ou éviter qu’elle retarde le texte avec font-display: swap.

Améliorer le CLS

Presque tous les décalages de mise en page ont la même cause : le navigateur ne sait pas combien de place réserver. Les remèdes sont peu coûteux.

• Déclarer la largeur et la hauteur de chaque image et vidéo, ou utiliser la propriété CSS aspect-ratio, pour que l’espace existe avant le chargement.
• Réserver la place des publicités, des intégrations et des bandeaux, plutôt que de les insérer au-dessus d’un contenu déjà affiché.
• Choisir des polices de secours de métriques proches de la police finale, pour limiter le saut quand celle-ci arrive.

Améliorer l’INP

L’INP se dégrade quand le navigateur est occupé au moment où le visiteur agit. Le coupable est presque toujours du JavaScript trop long ou trop abondant.

• Envoyer moins de JavaScript. La tâche la plus rapide est celle qu’on n’exécute pas. Un site qui s’affiche sans script pour l’essentiel part avec une avance considérable.
• Découper les tâches longues pour que le navigateur puisse répondre à un clic entre deux morceaux.
• Alléger la réaction visible à un geste : afficher d’abord le retour attendu, faire le travail lourd ensuite.
• Examiner les scripts tiers (mesure d’audience, widgets, chat), qui pèsent souvent plus que le code du site lui-même.

Les pièges de la mesure

Un score unique est une mauvaise boussole : la note globale de Lighthouse est un résumé pondéré qui peut monter tandis que l’expérience d’un visiteur réel ne change pas. Regardez les trois mesures séparément, et sur mobile d’abord, parce que c’est là que les écarts se creusent. Les résultats de laboratoire varient d’une exécution à l’autre : répétez le test avant de conclure qu’un changement a eu un effet.

Une métrique qu’on optimise sans regarder le visiteur finit par mesurer l’optimisation.

Par où commencer

Choisissez la page qui compte le plus, souvent l’accueil ou la page d’un article très lu. Mesurez-la en laboratoire pour trouver ce qui pèse, corrigez une chose à la fois, puis vérifiez sur le terrain après quelques semaines, le temps que les données s’accumulent. Gardez ensuite un budget simple, par exemple une limite de poids de JavaScript et une taille maximale d’image, vérifié automatiquement à chaque modification, pour que les gains ne se perdent pas au prochain ajout.