Lighthouse vs field data : vérifiez que votre fix a fonctionné

Lighthouse dit que c'est corrigé. Pourquoi Search Console reste dans le rouge ?

Lighthouse charge la page une seule fois, sur un téléphone simulé, et donne le LCP et le CLS pour ce chargement. Vos Core Web Vitals sont des field data : le 75e percentile de 28 jours de visites réelles sur Chrome, sur des téléphones et des réseaux rapides ou lents, avec des caches vides ou pleins, en incluant chaque clic. Un fix peut donc passer dans Lighthouse aujourd'hui et mettre quatre semaines à apparaître dans Search Console. Comparez trois runs Lighthouse, puis surveillez vos field data.

Comment lancer Lighthouse pour comparer l'avant et l'après ?

Lancez Lighthouse de la même façon avant et après la modification :

1. Videz les caches. Videz le cache du plugin de cache et du CDN après la modification, sinon Lighthouse teste l'ancienne page.
2. Choisissez un outil et gardez-le. Sans code : PageSpeed Insights, sur l'onglet Mobile. Côté développeur : le panneau Lighthouse dans Chrome DevTools avec Device réglé sur Mobile, dans une fenêtre de navigation privée, car les extensions de navigateur ajoutent leurs propres scripts à la page.
3. Testez l'URL qui affichait l'avertissement. Si la modification a eu lieu dans le template produit, testez une page produit.
4. Lancez-le trois fois et prenez le résultat médian.
5. Regardez d'abord l'avertissement et sa métrique. L'avertissement passe dans Passed audits, et la métrique concernée (LCP, CLS, Total Blocking Time) baisse. Le score vient en dernier.

Pourquoi le score change alors que rien n'a changé ?

Chaque run correspond à un chargement, et deux chargements ne sont jamais identiques : le serveur répond plus ou moins vite, le réseau varie, et les publicités, bannières de consentement et tests A/B peuvent différer d'un run à l'autre. Sur l'une de mes pages de test, le premier texte ou la première image (FCP) est apparu 1,5 s plus tôt lors d'un run par rapport à un autre, et sur une seconde page, le score est sorti à 96 ou 80 sans que rien n'ait changé. Gagner quelques points après un fix ne veut pas dire grand-chose tant que vous ne comparez pas la médiane de trois runs.

Six runs d'affilée sur la même URL, www.bbc.com, ont donné 38, 44, 41, 73, 60 et 53 en l'espace de deux minutes. Lighthouse 13.5.0, mobile, throttling simulé comme dans PageSpeed Insights.

Enregistrer une trace dans DevTools

Ouvrez la page dans Chrome, ouvrez DevTools et allez dans le panneau Performance. Dans Capture settings (l'icône d'engrenage), réglez Network sur Slow 4G et CPU sur 4x slowdown, ce qui est proche de la simulation de Lighthouse sur mobile, puis cliquez sur Record and reload. L'onglet Insights dans la barre latérale liste les mêmes insights que Lighthouse, chacun avec les requêtes et les éléments associés. Avant même d'enregistrer, le panneau affiche votre propre LCP, CLS et INP en direct (l'INP dès que vous cliquez dans la page). Cliquez sur Set up sous Field metrics pour afficher à côté les chiffres CrUX de vos visiteurs réels pour cette même URL.

Pourquoi Lighthouse dit une chose et Search Console une autre ?

Lighthouse fournit des lab data : un chargement unique de la page sur un téléphone milieu de gamme simulé avec une connexion 4G lente, cache vide. Il s'arrête peu après le chargement ; il ne scrolle jamais, ne touche pas l'écran et n'ouvre pas de seconde page. Vous obtenez le LCP et le CLS pour ce seul chargement, et aucun INP, car l'INP nécessite un visiteur qui clique.

Les field data représentent ce que Chrome a mesuré pour vos visiteurs réels : téléphones rapides ou lents, bons et mauvais réseaux, première visite cache vide ou dixième avec tous les fichiers en cache, scroll, clics et navigation d'une page à l'autre. Google les collecte dans le Chrome UX Report (CrUX), auprès des utilisateurs de Chrome sur Android et desktop qui partagent leurs statistiques d'utilisation. Vos Core Web Vitals correspondent à ces visites sur les 28 derniers jours, pour chaque métrique au 75e percentile (p75) : trois visites sur quatre étaient au moins aussi bonnes.

Google se base sur les field data pour son classement. Lighthouse sert à comprendre pourquoi une page est lente et si une modification améliore les choses. Quand les deux ne sont pas d'accord, c'est qu'ils ont mesuré des chargements différents. Un score Lighthouse au vert avec de mauvaises field data signale souvent des téléphones plus lents que la simulation, des réponses lentes aux clics (INP) ou du contenu qui bouge pendant le scroll. Un score dans le rouge avec de bonnes field data signifie souvent que vos visiteurs ont des téléphones et des réseaux plus rapides que la 4G lente de Lighthouse, et qu'ils reviennent avec vos fichiers déjà en cache.

Un rapport PageSpeed Insights pour www.bbc.com sur mobile, le 26 octobre 2026. Les visites réelles valident les trois Core Web Vitals avec un LCP de 1,2 s ; le run Lighthouse dans ce même rapport affiche un score de 37 avec un LCP de 9,5 s.

PageSpeed Insights affiche les field data de l'URL testée quand elle enregistre assez de visites, et pour l'ensemble du site sous Origin quand ce n'est pas le cas. Search Console regroupe les URL similaires et évalue chaque groupe en fonction de sa pire métrique.

Où voir ce que vos visiteurs obtiennent ?

Quatre outils gratuits affichent CrUX, les field data utilisées par Google :

• PageSpeed Insights : la section du haut, « Découvrez ce que vos utilisateurs réels constatent », avec le LCP, l'INP et le CLS au p75 sur les 28 derniers jours, pour l'URL ou pour l'origine.
• Search Console : le rapport Core Web Vitals, sur mobile et desktop, montre quels groupes d'URL similaires sont médiocres sur l'ensemble du site.
• CrUX History report : une barre par semaine pour votre site ou une URL, afin de voir la tendance.
• DevTools : le panneau Performance affiche ces mêmes chiffres à côté de votre propre chargement (à configurer une seule fois).

Un site qui enregistre trop peu de visites Chrome n'a pas de données CrUX : PageSpeed Insights affiche « No Data » dans la section du haut. CoreDash mesure ces visites malgré tout.

CoreDash : quelle page, quel élément

CrUX, les field data de Google, ne donne qu'un seul p75 par URL ou par site. CoreDash, l'outil de RUM que j'ai développé, est un script installé sur vos pages qui mesure chaque visite et identifie l'élément derrière chaque LCP, INP et CLS. Vous filtrez par page, par appareil et par élément, et chaque modification apparaît dans la série temporelle dès les visites suivantes. Ajoutez le script avant de modifier quoi que ce soit, afin de pouvoir comparer l'avant et l'après.

CoreDash, acme-pagespeed.com, mobile, p75 par page : une page a un CLS de 0,92 là où les autres sont à 0.

Combien de temps avant que Search Console n'affiche votre fix ?

PageSpeed Insights et Search Console affichent les 28 derniers jours, et cette fenêtre glisse chaque jour. Dans PageSpeed Insights, les données ont environ deux jours de décalage ; dans Search Console, quelques jours de plus. Deux semaines après le fix, la moitié des visites de cette fenêtre datent encore d'avant la correction. Au bout de quatre semaines, elle ne contient plus que des visites postérieures au fix. La fenêtre de 28 jours, au jour le jour détaille la chronologie complète.

Search Console, rapport Core Web Vitals, mobile, au 26 octobre 2026 : dernière mise à jour le 21 octobre.

Le rapport CrUX History montre cette même fenêtre par semaine : chaque barre couvre les 28 jours précédents, il faut donc environ quatre barres pour qu'un fix se reflète pleinement.

Rapport CrUX History pour ado-goldkante.de, mobiles, LCP : part des chargements bons, à améliorer et médiocres par semaine. Après une modification à la mi-août, la part de chargements bons passe en quatre barres de 59 % à 76 %, 83 %, 90 % et 93 %, et le LCP au p75 passe de 3,6 s à 1,5 s.

Une fois le fix en ligne, ouvrez le problème dans le rapport Core Web Vitals de Search Console et cliquez sur Start Tracking (aussi appelé Validate fix). Cela lance la vérification sur 28 jours propre à Search Console pour chaque URL concernée, sur ces mêmes field data. Pendant le processus, le statut affiche Started, puis Looking good dès lors que toutes les URL vérifiées jusque-là sont conformes. Il se termine sur Passed si aucune URL n'a rencontré le problème pendant 28 jours, ou sur Failed si l'une d'elles le présente encore ; corrigez alors l'anomalie et cliquez sur Start new validation.

Comment savoir si un fix a fonctionné pour les visiteurs réels ?

Vérifiez dans cet ordre, le plus rapide d'abord :

1. La modification est en ligne. Affichez le code source de la page, ou repérez le fichier ou le header dans le panneau Network de DevTools. Si vous voyez encore l'ancienne version, un plugin de cache ou le CDN sert toujours l'ancienne page.
2. Lighthouse passe. Sur mobile, trois runs, prenez le résultat médian (comme expliqué plus haut) : l'avertissement bascule dans Passed audits.
3. Vos visiteurs en bénéficient. Dans CoreDash, dès les visites suivantes : filtrez sur la page ou le template modifié, réglez l'appareil sur mobile, et suivez la métrique au jour le jour ainsi que l'élément associé.
4. CrUX suit. Les field data dans PageSpeed Insights et les barres du rapport CrUX History évoluent petit à petit. L'effet complet se voit au bout de quatre semaines (pourquoi cela prend autant de temps).
5. Search Console confirme. Dans le rapport Core Web Vitals, cliquez sur Start Tracking au niveau du problème et attendez le statut Passed.

Lighthouse passe, quatre semaines se sont écoulées et vos field data ne bougent toujours pas ? C'est que les visites lentes correspondent à des cas que Lighthouse ne teste jamais : un téléphone d'entrée de gamme, un clic lent, un décalage de contenu au milieu de la page. Lors d'une Core Web Vitals power hour, j'analyse vos field data avec vous, groupe de pages par groupe de pages, jusqu'à savoir quelle page et quel élément freinent votre p75.