Pourquoi Google ignore-t-il vos scores Lighthouse pour classer votre site ?

Quelle est la différence entre field data et lab data ?

Les données de laboratoire (lab data) proviennent de simulations contrôlées — typiquement Lighthouse dans PageSpeed Insights, ou des outils comme WebPageTest. Ces tests se déroulent sur une machine donnée, un réseau calibré, dans des conditions parfaitement reproductibles. Pratique pour diagnostiquer, mais totalement déconnecté du terrain.

Les données terrain (field data), c'est le Chrome User Experience Report (CrUX). Google collecte les métriques réelles de vrais utilisateurs Chrome qui visitent votre site. Latence réseau variable, appareils hétéroclites, connexions 3G crachotantes — bref, la vraie vie. Et c'est cette source que Search Console affiche dans son rapport Core Web Vitals.

Pourquoi Google privilégie-t-il les données CrUX pour le classement ?

Simple : le classement vise à récompenser l'expérience utilisateur réelle, pas un score théorique obtenu sur un serveur AWS avec une fibre dédiée. Un site peut afficher 100/100 sur Lighthouse et planter en production sous charge avec des scripts tiers mal optimisés. Google veut mesurer ce que subissent les visiteurs, pas ce que vous montrez en démo.

Le CrUX agrège les données sur 28 jours glissants, ce qui lisse les variations ponctuelles et reflète une tendance stable. C'est cette moyenne que Google utilise pour déterminer si vos URLs passent le seuil "Good" sur LCP, FID (ou INP désormais) et CLS. Pas de simulation, que du concret.

Est-ce que les données de laboratoire ne servent vraiment à rien ?

Elles restent indispensables pour diagnostiquer. Lighthouse vous dit *pourquoi* votre LCP est pourri — image non optimisée, render-blocking CSS, serveur lent. Mais une fois le problème identifié et corrigé, c'est le CrUX qui validera (ou pas) que vos utilisateurs réels bénéficient de l'amélioration.

Beaucoup de praticiens tombent dans le piège : ils optimisent jusqu'à obtenir un score parfait en lab, puis s'étonnent que le classement ne bouge pas. Normal — le signal de ranking ne lit pas Lighthouse, il lit CrUX. Si votre traffic vient majoritairement de mobiles 4G instables, votre field data restera médiocre même avec un lab data impeccable.

• Field data (CrUX) : données réelles collectées auprès des utilisateurs Chrome, agrégées sur 28 jours, seule source prise en compte pour le classement Core Web Vitals.
• Lab data (Lighthouse) : simulations reproductibles, utiles pour le diagnostic et l'identification des optimisations techniques, mais ignorées par l'algorithme de ranking.
• Seuil de classement : une URL doit atteindre le seuil "Good" dans le CrUX (75e percentile) pour bénéficier du boost Core Web Vitals — le score lab n'a aucune incidence directe.
• Délai de propagation : toute amélioration technique met jusqu'à 28 jours pour se refléter pleinement dans le CrUX, donc dans le signal de ranking.
• Trafic minimum : pour qu'une URL dispose de field data, elle doit recevoir un volume suffisant de visites Chrome — sinon Google utilise les données au niveau origine (domaine entier).

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Totalement. Les audits que je mène depuis des années montrent une corrélation quasi nulle entre score Lighthouse et évolution du trafic organique. J'ai vu des sites passer de 40 à 95 en lab sans aucun impact ranking, et d'autres stagner à 60 mais exploser en visibilité après avoir corrigé leur field data. Le CrUX est l'arbitre final.

Le problème, c'est que beaucoup d'agences vendent encore des "optimisations Core Web Vitals" basées sur Lighthouse. Elles livrent un joli rapport vert, le client applaudit, et trois mois plus tard le trafic n'a pas bougé. Pourquoi ? Parce qu'elles ont optimisé pour un test synthétique, pas pour les utilisateurs réels — qui eux naviguent depuis un Xiaomi sous 3G dans le métro parisien.

Quelles nuances faut-il apporter à cette affirmation de Google ?

Google reste volontairement flou sur la granularité du signal. On sait que le CrUX agrège au niveau URL si le volume est suffisant, sinon bascule au niveau origine. Mais quel est ce seuil de trafic ? Mystère. [A verifier] : aucune donnée officielle sur le nombre minimum de visites Chrome nécessaires pour déclencher une évaluation URL-level.

Autre zone grise : le poids relatif du signal Core Web Vitals dans l'algo global. Google répète que c'est "un signal parmi d'autres", ce qui en pratique signifie que sur des requêtes ultra-compétitives, un contenu médiocre avec un CrUX parfait ne renversera jamais un concurrent solide avec un CrUX moyen. Le boost existe, mais il n'est pas magique — et Google ne publiera jamais son coefficient de pondération exact.

Dans quels cas cette règle ne s'applique-t-elle pas vraiment ?

Si votre site n'a pas assez de trafic Chrome pour générer du field data, Google n'a rien à évaluer. Dans ce cas, soit il utilise les données au niveau origine (ce qui dilue la performance de vos meilleures pages), soit il ne tient simplement pas compte du signal. Les petits sites et les pages très fraîches sont dans ce flou.

Deuxième cas limite : les bots et crawlers. Googlebot ne contribue pas au CrUX — il ne mesure pas l'expérience utilisateur au sens strict. Donc si votre site est techniquement rapide mais que vos scripts tiers (analytics, chat, pubs) sabotent l'expérience réelle, Googlebot ne verra rien au crawl, mais le CrUX vous enfoncera. Et c'est le CrUX qui gagne.

Que faut-il faire concrètement pour optimiser le signal de classement ?

Arrêtez de courir après les scores Lighthouse et concentrez-vous sur le rapport Core Web Vitals de la Search Console. C'est là que vous voyez ce que Google voit : les données CrUX agrégées par groupe d'URLs. Si une URL est classée "Mauvaise" dans ce rapport, elle ne bénéficie d'aucun boost — peu importe son score lab.

Identifiez les goulots d'étranglement réels : LCP pourri ? Regardez les images, le TTFB serveur, les fonts bloquantes. CLS instable ? Traquez les publicités qui décalent le contenu, les embeds sans dimensions. INP élevé ? Vos scripts third-party sont probablement en cause. Lighthouse vous donne des pistes, mais validez toujours l'amélioration dans le CrUX avant de crier victoire.

Quelles erreurs éviter absolument ?

Première erreur classique : optimiser uniquement pour desktop alors que 70 % de votre trafic vient du mobile. Le CrUX sépare les données par type d'appareil, et Google utilise la version mobile pour le ranking (mobile-first indexing oblige). Un site qui cartonne en desktop mais rame sur mobile perd le signal.

Deuxième piège : ignorer les scripts tiers. Vous avez beau optimiser vos images et votre CSS, si Google Tag Manager charge 15 trackers en synchrone, ou si votre chat live bloque le main thread pendant 800 ms, votre INP explose. Et ça, Lighthouse en lab ne le verra pas toujours — mais le CrUX, si. Auditez vos third-parties avec un regard critique, et différez tout ce qui n'est pas critique au-dessus de la ligne de flottaison.

Comment vérifier que mon site est conforme et que les optimisations portent leurs fruits ?

Surveillez le rapport Core Web Vitals de la Search Console toutes les semaines. Google met à jour ces données quotidiennement, avec un rolling window de 28 jours. Si vous déployez une optimisation aujourd'hui, attendez-vous à voir un impact progressif sur 3-4 semaines — le temps que les nouvelles données remplacent les anciennes dans l'agrégat.

Complétez avec PageSpeed Insights sur vos URLs stratégiques : regardez la section "Découvrir ce que vos utilisateurs réels rencontrent" (field data). Si elle affiche "Aucune donnée disponible", c'est que l'URL n'a pas assez de trafic Chrome — Google utilisera alors les données au niveau origine. Dans ce cas, améliorer une page isolée ne sert à rien, il faut traiter le site dans son ensemble.

• Installer un monitoring RUM (Real User Monitoring) pour suivre les Core Web Vitals en temps réel, indépendamment du CrUX — des outils comme Cloudflare Web Analytics, SpeedCurve ou Sentry permettent de détecter les régressions avant qu'elles ne polluent vos données Google.
• Segmenter vos données CrUX par type d'appareil (mobile / desktop / tablette) et par connexion (4G / 3G / slow-2G) pour identifier les populations d'utilisateurs qui tirent votre score vers le bas.
• Mettre en place des budgets de performance pour les scripts tiers : pas plus de X ko de JS externe, pas plus de Y ms de blocking time — et faire respecter ces limites par votre équipe produit et marketing.
• Tester vos pages sur de vrais devices (pas juste le mode DevTools) avec des connexions throttled — un Moto G4 sous 3G révèle des problèmes que Lighthouse en lab ne verra jamais.
• Automatiser les audits post-déploiement : chaque mise en production doit déclencher un test Lighthouse + un contrôle des field data sur un échantillon d'URLs — pour détecter les régressions avant qu'elles n'impactent le CrUX.
• Documenter les corrélations entre améliorations CrUX et évolution du trafic organique : cela vous permettra de quantifier le ROI réel des optimisations Core Web Vitals et d'ajuster vos priorités en conséquence.