Core Web Vitals : pourquoi votre score vert vous ment

Votre score Lighthouse est une simulation. Mesurez vos Core Web Vitals sur vos vrais utilisateurs via l’API CrUX et corrigez votre INP.

Votre rapport Core Web Vitals affiche 95 sur 100 et vos utilisateurs partent quand même.

Ce n’est pas une contradiction, c’est un problème de mesure. Le score que vous regardez sort d’une simulation exécutée dans des conditions moyennes, sur une machine qui n’est pas la vôtre, depuis un réseau qui n’est pas celui de vos clients. Google, lui, ne classe pas votre site sur cette simulation. Il le classe sur ce que vivent vos visiteurs réels.

Nous avons déjà traité ce que coûte un site lent et comment l’auditer en dix minutes . Cet article attaque l’étage au-dessus : pourquoi un score vert et une clientèle qui fuit coexistent très bien, et comment mesurer vos vrais utilisateurs plutôt qu’un robot.

Lighthouse ne mesure pas votre site, il le simule

Il existe deux familles de données de performance, et confondre les deux fait perdre des trimestres entiers d’optimisation.

· Les données de laboratoire : Lighthouse, l’onglet PageSpeed Insights, votre CI. Une seule visite, sur une machine virtuelle, avec un bridage réseau standardisé. Reproductible, pratique pour comparer deux versions de code, et totalement muette sur votre audience.

· Les données de terrain : ce que Chrome remonte depuis les navigateurs de vos visiteurs réels, agrégé dans le Chrome UX Report. Bruité, en retard, et c’est la seule chose que Google utilise comme signal d’expérience de page.

La distinction n’est pas académique. Le laboratoire teste une page froide, sans cookie, sans extension, sans onglet ouvert, sur un profil réseau moyen. Vos clients arrivent avec un cache partiel, huit onglets, un antivirus, un téléphone de 2021 et une connexion mobile qui varie selon l’heure. Le laboratoire mesure votre code. Le terrain mesure votre code multiplié par la réalité de votre marché.

Trois chiffres à retenir, inchangés en 2026 : LCP sous 2,5 secondes, INP sous 200 millisecondes, CLS sous 0,1. La règle qui compte davantage que les seuils eux-mêmes : ils sont évalués au 75e centile de vos visiteurs. Autrement dit, un visiteur sur quatre peut vivre pire que le seuil sans que vous soyez pénalisé, mais si vous êtes à la limite, ce sont vos utilisateurs les plus mal équipés qui décident de votre classement.

INP, la métrique qui casse les sites en 2026

Depuis mars 2024, INP a remplacé FID dans les Core Web Vitals, et le changement est brutal. FID mesurait le délai de la première interaction seulement. INP observe toutes les interactions de la visite (clic, tapotement, clavier) et retient la pire. Un menu qui rame au dixième clic compte désormais.

Les seuils officiels : bon sous 200 ms, à améliorer entre 200 et 500 ms, mauvais au-delà de 500 ms. INP se décompose en trois phases, et savoir laquelle vous plombe change entièrement le correctif :

· Input delay : le temps avant que votre gestionnaire d’événement démarre. Le fil principal est occupé par autre chose, typiquement une longue tâche JavaScript, un script tiers d’analytics ou une bannière de consentement.

· Processing duration : l’exécution de vos gestionnaires. C’est votre code métier, et c’est souvent la phase la plus courte.

· Presentation delay : le temps entre la fin du traitement et l’affichage réel de la nouvelle image. DOM trop lourd, recalculs de style en cascade, rendu entièrement côté client.

Ce point mérite d’être verrouillé : INP est un problème de processeur, pas de tuyau . Acheter de la bande passante, activer un CDN ou compresser vos images ne bougera pas votre INP d’une milliseconde. Beaucoup d’équipes dépensent leur budget performance sur le réseau alors que la métrique qui les bloque se joue sur le fil d’exécution du navigateur, dans le téléphone du client.

La recommandation de Google est explicite : mesurer en terrain d’abord pour identifier quelle interaction est lente, avant d’optimiser quoi que ce soit. Optimiser au jugé, c’est refactoriser du code qui n’a jamais été le goulot.

Le multiplicateur ultramarin : 100 ms perdues avant la première requête

Voilà où l’écart entre laboratoire et terrain devient une décision business, et pas un débat d’ingénieur.

La SPLANG, opérateur public d’aménagement numérique de la Guyane, avance un chiffre officiel : la latence actuelle depuis le territoire est supérieure à 100 millisecondes , parce que les routes internationales passent aujourd’hui par les États-Unis. Le câble sous-marin Lum@link, raccordé à l’unité de branchement EllaLink entre Fortaleza et Sines, doit la ramener autour de 60 millisecondes à sa mise en service prévue fin 2026. Le câble Kanawa d’Orange, 1 746 km entre Kourou et Schoelcher, complète le maillage régional.

Traduisez en performance web. Cent millisecondes de latence, c’est le prix payé à chaque aller-retour réseau . La résolution DNS, la poignée de main TLS, la requête HTML, puis chaque police, chaque script tiers, chaque appel d’API. Un site qui enchaîne huit allers-retours bloquants avant le premier rendu utile part avec près d’une seconde de retard structurel sur son équivalent métropolitain. Votre score Lighthouse ne verra jamais cette seconde : il teste depuis une infrastructure qui n’a pas ce handicap.

Ce qui se construit sous cette contrainte devient supérieur ailleurs. Un site qui reste sous les seuils Core Web Vitals depuis Cayenne est confortablement rapide depuis Paris. L’inverse est faux, et c’est précisément l’erreur des solutions conçues pour l’Hexagone puis déployées telles quelles ici. Trois arbitrages concrets en découlent :

· Réduire le nombre d’allers-retours avant le premier rendu prime sur le poids total des fichiers. Polices en auto-hébergement, CSS critique en ligne, zéro redirection sur la page d’accueil.

· Choisir un point de présence pertinent . Un hébergement souverain reste un bon arbitrage juridique, à condition d’ajouter un cache en périphérie pour vos visiteurs éloignés. Le sujet croise directement celui de l’hébergement en France et de la souveraineté des données .

· Éliminer les scripts tiers bloquants . Chaque domaine externe ajoute une résolution DNS et une négociation TLS complètes, soit deux à trois fois la latence de base, avant même de télécharger un octet utile.

Mesurer vos vrais utilisateurs en 30 minutes

Voici le protocole. Il ne coûte rien et il remplace définitivement le pilotage au score Lighthouse.

Étape 1 : interroger le Chrome UX Report. L’API est gratuite, la clé se génère dans la console Google Cloud. Les données sont une moyenne glissante sur 28 jours, restituées au 75e centile avec la répartition bon / à améliorer / mauvais.

Lancez la même requête avec "formFactor":"DESKTOP" , puis comparez. L’écart entre les deux est votre premier verdict. Si l’origine n’a pas assez de trafic, l’API renvoie une erreur : votre site est sous le seuil de collecte, et vous devez passer directement à l’étape 2.

Étape 2 : instrumenter vos propres visiteurs. La bibliothèque officielle web-vitals de Google mesure exactement comme Chrome, pour environ 3 Ko compressés en build standard. Le build attribution utilisé ci-dessous ajoute environ 1,5 Ko et remonte en prime l’élément fautif, ce qui vous évite de deviner.

Étape 3 : arbitrer. Croisez les deux sources et décidez avec cette table plutôt qu’à l’instinct :

· Laboratoire vert, terrain rouge : votre code est sain, votre distribution ne l’est pas. Cherchez du côté de la latence, des scripts tiers et du parc d’appareils réel de vos clients.

· Laboratoire rouge, terrain vert : votre audience est mieux équipée que le profil de test. Priorité basse, ne dépensez pas votre budget ici.

· Les deux rouges sur INP : problème d’exécution JavaScript. Découpez les longues tâches, différez les scripts tiers, allégez le DOM.

· Les deux rouges sur LCP : problème de chemin critique. Attaquez les allers-retours et le poids de l’élément principal.

Cette mesure devient un indicateur de pilotage, au même titre que vos métriques de pilotage PME . Une valeur relevée chaque mois, une décision par trimestre.

Le mot de la fin

Un score de laboratoire vert prouve que votre code se comporte bien dans un monde qui n’existe pas. Vos clients, eux, vivent dans le vrai, à plus de 100 millisecondes de vos serveurs.

Mesurez le terrain. Le reste est du confort d’ingénieur.

♚ 1D-D1 - One Day or Day One. Parlons stratégie -