Core Web Vitals — pourquoi votre score PageSpeed mesure autre chose

La plupart des prestations vendues sous l’étiquette optimisation de site web se résument à un seul objectif : un score vert au-dessus de 90 points dans les outils d’audit populaires. Les dirigeants poursuivent la note parfaite en pensant qu’elle se traduira par un meilleur classement dans les résultats de recherche. Or, du point de vue de Google, la vitesse de chargement d’un site n’est pas un chiffre unique de 0 à 100. Le score que vous voyez dans la plupart des outils de test n’est qu’une évaluation de laboratoire. Pour comprendre ce qui influence réellement la visibilité d’un site, il faut séparer la simulation des métriques concrètes utilisées par l’algorithme — les Core Web Vitals.

Score Lighthouse ou Core Web Vitals

Lorsque vous lancez un test de vitesse dans le navigateur, c’est le moteur Lighthouse qui travaille en coulisses. Il vaut la peine de regarder de quoi se compose sa note finale. Dans Lighthouse 13, qui n’a rien changé au modèle de notation, les poids se répartissent ainsi selon la documentation officielle :

• First Contentful Paint (FCP) : 10 %
• Speed Index : 10 %
• Largest Contentful Paint (LCP) : 25 %
• Total Blocking Time (TBT) : 30 %
• Cumulative Layout Shift (CLS) : 25 %

Le poids le plus lourd du score de laboratoire — 30 % entiers — revient au TBT. Le problème, c’est que le TBT n’est pas une métrique Core Web Vitals et que l’algorithme de classement ne l’utilise pas. À l’inverse, Interaction to Next Paint, métrique de classement à part entière, n’apparaît pas du tout dans le score Lighthouse.

La raison de cette absence est banale, mais mérite d’être retenue, car elle explique tout le reste de l’article : dans un laboratoire, personne ne clique. Lighthouse charge la page et mesure ce qui se passe de lui-même. INP mesure la réaction à une action de l’utilisateur ; sans utilisateur, il n’y a rien à mesurer. Le TBT est l’approximation de laboratoire du même problème — il vérifie combien de temps le fil principal du navigateur était occupé et n’aurait pas pu répondre si quelqu’un avait cliqué.

Les deux autres éléments de la liste valent d’être connus par leur nom, car ils apparaissent dans chaque rapport. First Contentful Paint est le moment où quelque chose apparaît à l’écran — le premier texte ou la première image. Speed Index décrit la vitesse à laquelle la zone visible de la page se remplit. Toutes deux mesurent raisonnablement l’impression que « quelque chose se passe », toutes deux sont des mesures de laboratoire, et aucune n’est un Core Web Vital.

Conséquence pratique : celui qui investit pour atteindre 90 points optimise pour un indicateur exclu du classement et ne mesure pas celui qui en fait partie. Cela ne rend pas le score Lighthouse inutile — c’est un bon outil de diagnostic, et nous verrons plus loin quand il peut être le seul dont vous disposez. Cela signifie seulement que ce n’est pas l’évaluation que réalise le moteur de recherche.

Trois métriques et trois seuils

Le moteur de recherche n’évalue pas un site avec une moyenne pondérée de laboratoire ; il mesure la vitesse d’un site web à travers des expériences concrètes des utilisateurs. Selon web.dev, une page respecte la norme Core Web Vitals lorsqu’elle tient trois seuils :

• Largest Contentful Paint (LCP) : ≤ 2,5 s — le temps d’affichage du plus grand bloc de texte ou de la plus grande image visible sans défiler.
• Interaction to Next Paint (INP) : ≤ 200 ms — la métrique qui a remplacé FID en mars 2024. Le navigateur observe toutes les interactions pendant une visite et rapporte une seule valeur, proche de la pire d’entre elles — ni une somme ni une moyenne. Sur les pages comportant de nombreuses interactions, les cas extrêmes isolés sont écartés, afin qu’un blocage accidentel ne décide pas de la note.
• Cumulative Layout Shift (CLS) : ≤ 0,1 — la stabilité visuelle. Elle repère les décalages inattendus de la mise en page, par exemple quand un texte « s’échappe » sous votre doigt parce qu’une bannière vient de se charger.

Les seuils ne concernent pas un test isolé. Pour réussir, une page doit tenir ces valeurs au 75e centile des visites — au moins 75 visites réelles sur 100 doivent rester sous le seuil. Et une précision sur laquelle on trébuche facilement : le centile est calculé séparément pour les appareils mobiles et pour les ordinateurs. Un site peut réussir sur ordinateur et échouer sur téléphone, et c’est une situation courante, pas une exception.

Laboratoire ou terrain

L’écart entre un score élevé après l’installation d’une extension d’accélération et l’absence d’effet réel vient de la manière dont les données sont collectées. Lighthouse est un environnement de laboratoire. Il simule un seul chargement depuis un seul serveur de test, en appliquant des limites de débit prédéfinies — ce qui rend les résultats reproductibles, mais détachés de la réalité.

Pour son évaluation, Google utilise le Chrome User Experience Report (CrUX) — un ensemble de données anonymes issues de vrais utilisateurs de Chrome. CrUX intègre des conditions rudes : des téléphones vieux de cinq ans, des pertes de réseau passagères dans les transports publics, des Wi-Fi saturés, des connexions lentes. Sur le terrain, ce qui compte n’est pas la façon dont la page se charge chez un développeur sur la fibre, mais son comportement chez vos clients.

Il est aussi utile de savoir comment ces données sont calculées, car cela détermine le calendrier de toute correction. CrUX fournit une moyenne glissante sur 28 jours, mise à jour chaque jour vers 4 h UTC, et le jeu de données a environ deux jours de retard sur la date du jour, le temps de réunir les données complètes et de les traiter.

Conséquence pratique : une correction déployée le lundi n’apparaîtra pas dans le rapport le mardi, et lorsqu’elle commencera à apparaître, elle sera diluée par trois semaines d’anciennes mesures. L’image complète après un changement n’est visible qu’au bout d’environ quatre semaines. Qui juge un déploiement après trois jours juge surtout du bruit.

D’où une conclusion pratique pour vos échanges avec votre prestataire : une capture d’écran d’un score vert ne prouve pas que quelque chose s’est amélioré. Elle prouve que, lors d’un chargement simulé, la page s’est bien comportée. La preuve, ce sont les données de terrain collectées pendant plusieurs semaines après le changement — si vous en avez.

Pourquoi votre site n’a peut-être aucune donnée de terrain

C’est la partie qui manque dans la plupart des guides, et pour une petite entreprise, c’est la plus importante.

Pour qu’une adresse entre dans CrUX, elle doit remplir deux conditions : être publiquement accessible et suffisamment populaire. La documentation de Chrome formule la seconde condition clairement : une page est suffisamment populaire si elle compte un nombre minimum de visiteurs, et « the exact number is not disclosed » — il a été choisi pour que l’échantillon ait un sens statistique. Les adresses et les domaines qui ne franchissent pas ce seuil ne figurent pas dans le jeu de données CrUX.

Il n’y a pas de demi-mesure. Vous n’obtenez pas des données moins bonnes ou assorties de réserves — vous n’en obtenez aucune. Un site d’entreprise avec quelques centaines de visites par mois n’existe généralement pas dans CrUX, et ouvrir PageSpeed Insights pour une telle adresse n’affichera que la partie laboratoire, sans section de données réelles.

Ce qui en découle en pratique :

• Impossible de vérifier si votre site « réussit » les Core Web Vitals s’il n’a pas de données de terrain. On ne peut qu’estimer à partir du laboratoire.
• Le score de laboratoire devient alors le seul outil dont vous disposez — et il vaut la peine de l’utiliser, en se rappelant ce qu’il est. C’est un argument pour Lighthouse, pas contre lui.
• Une mesure propre auprès de vrais utilisateurs est possible et ne nécessite aucune autorisation de Google : les données Core Web Vitals peuvent être collectées dans les navigateurs de vos propres visiteurs. C’est une fonction standard que le prestataire active une fois. Il ne faut pas la confondre avec le monitoring de disponibilité : celui-ci dit si quelque chose vient de tomber en panne, celle-là comment le site se comporte pour les utilisateurs au cours des dernières semaines ; nous décrivons la différence dans l’article sur le monitoring de site web.
• Ne tirez pas de conclusions de l’absence de données. L’absence de section terrain dans PageSpeed ne signifie ni que le site est lent, ni que Google le pénalise. Elle signifie que le trafic est trop faible pour que Google ait quelque chose à moyenner.

Où passe vraiment le temps du LCP

Admettons que le LCP soit trop long. La question est : quoi payer pour le raccourcir. La documentation web.dev découpe ce temps en quatre phases et indique la part que chacune devrait représenter.

• Time to First Byte — environ 40 %. Le temps entre le clic sur un lien et le premier octet de la réponse. C’est le serveur : où il se trouve, sa charge, la mise en cache ou non de la réponse.
• Délai de démarrage de la ressource — moins de 10 %. Du premier octet au moment où le navigateur commence à télécharger le plus grand élément.
• Chargement de la ressource — environ 40 %. Le chargement de cet élément lui-même. Sur un site d’entreprise, c’est presque toujours une photo.
• Délai d’affichage — moins de 10 %. Du téléchargement de l’élément à son apparition à l’écran.

Quatre-vingts pour cent du budget, c’est le serveur et une image. Ce sont deux décisions dont aucune n’est une décision de programmation : la première relève de l’achat (où vous prenez votre hébergement et ce qu’il coûte), la seconde de la rédaction (quelle photo vous placez en haut de la page, et à quelle taille). Une extension marquée « optimisation » ne touche ni à l’une ni à l’autre.

Inutile de deviner de quel élément il s’agit. Les outils d’audit l’indiquent directement — le rapport contient une ligne qui nomme l’élément considéré comme le plus grand. Sur un site d’entreprise, c’est généralement la photo d’en-tête, plus rarement un bloc de texte avec un grand titre. Et c’est là que survient la première surprise : l’élément LCP s’avère souvent être quelque chose que personne n’avait prévu — l’arrière-plan de la section d’accueil, ou une image qui occupe la moitié de l’écran sur un téléphone alors qu’elle n’est qu’une décoration latérale sur ordinateur.

Les deux phases « de délai » sont censées être le reste. Si l’une d’elles a grandi, c’est un signal de diagnostic, pas une raison d’acheter un serveur plus puissant — quelque chose bloque le démarrage du téléchargement ou l’affichage. C’est alors qu’il est judicieux de recourir à Lighthouse, car c’est exactement le type de problème qu’un laboratoire montre bien.

Ce qui influence réellement le TTFB lors du choix d’un serveur fait l’objet d’un article séparé sur l’hébergement et les domaines.

INP : trois phases, et pourquoi ce n’est pas FID

INP est la plus jeune des trois métriques et la plus souvent mal décrite — généralement comme « le successeur de FID », ce qui laisse penser à un simple changement de nom. Ce n’est pas un changement mineur.

FID mesurait le délai de la première interaction : combien de temps s’écoulait avant que le navigateur ne commence à traiter le premier clic. Il ne mesurait ni la durée du traitement lui-même, ni le moment où l’utilisateur voyait le résultat. Une page pouvait donc réussir FID tout en réagissant très mal — il suffisait que le premier clic soit rapide et que chacun des suivants mette une seconde à répondre.

INP mesure tout le trajet, en trois phases :

• Délai d’entrée — du clic au début du traitement. Ce que mesurait FID.
• Durée de traitement — le temps d’exécution du code responsable de la réaction.
• Délai de présentation — de la fin du code au moment où le changement est visible à l’écran.

Seule la somme de ces trois segments décrit ce qu’un utilisateur appelle « la page a figé ». Pour le propriétaire d’un site, la conclusion est concrète : INP se dégrade à cause de ce que vous ajoutez — scripts de suivi, chats, extensions qui exécutent leur part de code à chaque clic. Il se dégrade rarement à cause du modèle lui-même.

C’est pourquoi INP et le nombre de modules installés relèvent en pratique de la même discussion que les mises à jour et tout ce qui a été ajouté au site.

CLS — le moins cher à corriger

CLS est la seule des trois métriques que l’on peut généralement corriger sans dépenser d’argent en infrastructure, car ses causes sont dénombrables et répétitives :

• Images sans dimensions déclarées. Le navigateur ne sait pas combien d’espace réserver ; il n’en réserve aucun et repousse tout le reste quand la photo arrive.
• Contenus insérés au-dessus du contenu existant — bannières de consentement, bandeaux promotionnels, messages chargés après le démarrage de la page.
• Polices remplacées après le chargement. Le texte s’affiche dans une police de substitution, puis bascule vers la police prévue, d’une autre largeur, et tout le paragraphe saute.

Le seuil lui-même peut induire en erreur, car 0,1 n’est ni une unité de temps ni de distance. C’est le produit de deux fractions : quelle part de l’écran s’est déplacée et sur quelle distance. Cela donne une règle facile à retenir : déplacer la moitié de l’écran visible d’un cinquième de sa hauteur épuise tout le budget d’un coup. Une seule bannière de consentement qui s’insère au-dessus du contenu peut l’épuiser entièrement.

Chacun de ces trois points a une solution standard côté prestataire, et c’est un travail qui se compte en heures, pas en semaines. Si le travail est commandé dans le cadre d’un contrat de maintenance, il vaut la peine de l’inscrire comme tâche distincte avec une mesure avant et après, plutôt que comme partie des « corrections courantes ». Si votre budget performance est limité, c’est sur le CLS que le rapport effet/coût est le meilleur — et c’est aussi la métrique que les utilisateurs ressentent le plus vivement, car elle se traduit par un clic sur le mauvais bouton.

Ce qu’un bon score achète, et ce qu’il n’achète pas

Il faut dire ici une chose que la branche qui vend de l’optimisation ne dit pas. Google la formule avec une prudence surprenante dans sa documentation pour les propriétaires de sites.

Premièrement : « There is no single signal » — il n’existe pas d’indicateur unique de « page experience » que l’algorithme insère dans une formule. Les systèmes de classement examinent de nombreux signaux, et les Core Web Vitals en sont un.

Deuxièmement, et c’est plus important : « Google Search always seeks to show the most relevant content, even if the page experience is sub-par ». La pertinence l’emporte. Une page lente qui répond à la question devancera une page rapide et vide. Ce n’est que lorsqu’il existe de nombreuses réponses pertinentes — et pour la plupart des requêtes commerciales, c’est le cas — que la bonne expérience commence à faire pencher la balance.

Troisièmement, sans détour : de bons résultats Core Web Vitals « doesn’t guarantee that your pages will rank at the top ».

Ce que cela signifie pour la décision de dépense :

• La performance ne remplacera pas le contenu. Si une page ne répond pas aux questions des clients, l’accélérer ne fera que la faire échouer plus vite.
• La performance départage les ex aequo. Dans une niche concurrentielle où une douzaine de pages disent la même chose, elle est l’un des facteurs de différenciation.
• La performance a un sens au-delà du classement. Une page qui reste trois secondes sur un écran blanc perd une partie de ses visiteurs avant même que Google ait pu évaluer quoi que ce soit. C’est un argument en soi, qui n’a pas besoin de l’algorithme.

L’ordre dans lequel dépenser

En rassemblant ce qui précède dans l’ordre où il vaut la peine d’agir :

1. Vérifiez si vous avez des données de terrain. Ouvrez PageSpeed Insights pour votre adresse. S’il y a une section de données réelles, vous travaillez sur des faits. Sinon, vous travaillez sur le laboratoire, et il vaut la peine d’activer votre propre mesure.
2. Commencez par le CLS. Le moins cher, le plus rapide, le plus perceptible pour l’utilisateur.
3. Puis les images en haut de page. Environ 40 % du budget LCP correspond au téléchargement du plus grand élément. La bonne taille et le bon format peuvent valoir davantage qu’un changement d’hébergement.
4. Puis le serveur. Si le TTFB absorbe nettement plus de 40 % du temps, c’est une discussion sur l’endroit où le site est hébergé — et là, changer d’hébergement apporte vraiment quelque chose. Le déménagement vers un nouveau serveur sans rien perdre dans les moteurs de recherche est détaillé dans l’article sur la migration de site web.
5. Enfin, comptez ce que vous ajoutez. INP se dégrade à cause des scripts. Chaque chat, pixel ou extension a son coût, payé à chaque clic de l’utilisateur.
6. Mesurez après le changement, pas avant. Les données de terrain ont besoin de plusieurs semaines pour montrer un effet. Une capture d’écran du jour du déploiement n’est pas une mesure.

Si vous vous demandez quelle part de tout cela doit être un poste fixe du budget et quelle part une dépense ponctuelle, c’est une autre discussion — sur les coûts de maintenance d’un site et sur ce qu’il faut surveiller au quotidien.

Comment lire une offre d’optimisation

Puisque le score en points n’est pas ce qu’évalue le moteur de recherche, une ligne comme « nous amènerons le site à 90+ dans PageSpeed » est une promesse portant sur une simulation, pas sur l’état du site chez vos clients. Cela ne rend pas l’offre malhonnête — cela signifie qu’elle mesure le succès dans une unité qui n’est pas celle du classement.

Voici les quatre formulations les plus fréquentes dans les offres, et ce qu’il faut demander pour chacune.

Une bonne offre de performance présente trois caractéristiques. Elle commence par une mesure de départ, et non par une liste de travaux — sans elle, impossible de démontrer l’effet ensuite. Elle nomme la métrique visée au lieu de parler d'« accélérer le site ». Et elle distingue ce qui changera immédiatement de ce que vous ne verrez que dans les données de terrain après plusieurs semaines.

Si votre site n’a pas de données de terrain, dites-le au prestataire dès le départ. La réaction honnête consiste à proposer d’activer votre propre mesure avant le début des travaux — pas à assurer que « ce sera plus rapide de toute façon ».