Pourquoi vos scores Lighthouse ne reflètent-ils pas la vraie performance de votre site ?

Quelle est la différence fondamentale entre Lab data et Field data ?

Les données Lab proviennent d'outils comme Lighthouse qui testent votre site dans des conditions contrôlées. Machine puissante, CPU récent, connexion fibre, cache vidé, pas de bloqueur de pub, pas d'extensions browser. Bref, un environnement idéal que 99% de vos visiteurs réels ne connaîtront jamais.

Les données Field (CrUX) collectent les métriques de performance auprès de vrais utilisateurs Chrome qui ont accepté le partage de statistiques. Téléphones Android moyen de gamme à 200€, connexions 3G saturées dans le métro, latence réseau variable, processeur qui chauffe parce que 12 onglets sont ouverts — voilà la réalité.

Pourquoi ces deux mesures peuvent-elles diverger autant ?

Un site peut scorer 95 sur Lighthouse et se retrouver dans le rouge en CrUX. L'écart vient de trois facteurs principaux : la puissance matérielle (un iPhone 13 vs un Android d'entrée de gamme de 2019), la qualité réseau (fibre 1Gb/s vs 3G avec 2 barres de signal), et la géolocalisation (CDN optimisé pour Paris mais serveur unique en Virginie pour le reste du monde).

Le piège classique ? Optimiser son site sur son MacBook Pro connecté en ethernet, valider avec un Lighthouse à 98, et découvrir trois mois plus tard que 60% du trafic mobile en Afrique subsaharienne ou en Asie du Sud-Est subit un LCP de 8 secondes. Les données Field révèlent ces angles morts.

Quelles métriques Google privilégie-t-il pour le ranking ?

Martin Splitt est explicite : les Field data sont un meilleur indicateur de l'expérience utilisateur réelle. Pour les Core Web Vitals utilisés comme facteur de ranking, Google se base sur le CrUX — pas sur Lighthouse. Si votre CrUX est inexistant (site trop récent ou trafic insuffisant), Google peut utiliser d'autres signaux, mais l'objectif reste de capter l'expérience terrain.

Concrètement ? Un score Lighthouse parfait ne garantit rien côté SEO si vos utilisateurs réels subissent des performances médiocres. À l'inverse, un site avec un Lighthouse moyen mais d'excellentes données Field garde un avantage compétitif. C'est la performance perçue qui compte, pas la performance de laboratoire.

• Lab data (Lighthouse) : environnement synthétique contrôlé, utile pour détecter des problèmes techniques et suivre des tendances
• Field data (CrUX) : expérience réelle des utilisateurs, seule métrique prise en compte pour le ranking via Core Web Vitals
• Divergences fréquentes : un bon score Lab n'implique pas de bonnes performances Field (et inversement)
• Facteurs d'écart : matériel (CPU/GPU), réseau (latence, débit), géolocalisation (distance au serveur/CDN)
• Action prioritaire : consulter CrUX en priorité (Search Console, PageSpeed Insights, BigQuery), utiliser Lighthouse comme outil diagnostic complémentaire

Cette distinction est-elle réellement appliquée par Google ?

Oui, et c'est observable. Les sites qui ont basculé des métriques Lab aux métriques Field en priorité constatent que les classements Core Web Vitals dans Search Console ne correspondent jamais parfaitement aux scores Lighthouse. On voit régulièrement des pages marquées « Bonnes » en CrUX avec un Lighthouse à 70, et des pages « À améliorer » malgré un Lighthouse à 90.

Le problème, c'est que beaucoup d'outils SEO grand public affichent encore les scores Lighthouse comme référence principale, créant une fausse impression de performance. Les clients regardent un beau 95 vert et ne comprennent pas pourquoi Search Console affiche du orange. Il faut expliquer cette distinction systématiquement.

Quelles sont les limites des données CrUX ?

CrUX n'est pas exempt de biais. Il collecte uniquement les données des utilisateurs Chrome (desktop et mobile) ayant activé la sync et le partage de statistiques — soit environ 60-70% du trafic Chrome total, qui lui-même représente ~65% du marché. Les utilisateurs Safari, Firefox, Edge (hors Chromium ancien) ne remontent pas dans CrUX.

Autre limite : le seuil de trafic minimum. Si une page reçoit moins de quelques centaines de visites sur 28 jours, elle n'apparaît pas dans CrUX. Pour les sites de niche ou les nouvelles pages, tu te retrouves sans données Field pendant des semaines, voire des mois. [À vérifier] : Google n'a jamais communiqué publiquement le seuil exact, mais les tests empiriques suggèrent ~500-1000 visites/mois minimum.

Faut-il ignorer complètement Lighthouse ?

Non, et ce serait une erreur. Lighthouse reste l'outil diagnostic le plus complet pour identifier des problèmes techniques : JavaScript bloquant le rendu, images non optimisées, absence de cache HTTP, CSS inutilisé. C'est un scanner médical — il détecte les pathologies, mais ne mesure pas la qualité de vie quotidienne.

La bonne approche ? Utilise Lighthouse pour auditer et corriger, puis valide l'impact réel sur CrUX 4-6 semaines plus tard (délai de collecte des données Field). Si ton Lighthouse progresse mais que CrUX stagne, creuse les segments CrUX par type de connexion (4G, 3G, slow-2G) et par device (mobile vs desktop) — tu découvriras souvent qu'une population spécifique tire la moyenne vers le bas.

Comment accéder aux données Field de mon site ?

Trois canaux principaux. D'abord, Google Search Console (section Core Web Vitals) : c'est la vue la plus claire pour un SEO, avec regroupement par statut (Bonnes, À améliorer, Médiocres) et par type de page. Limite : données agrégées par groupes d'URLs similaires, pas de granularité URL par URL sauf exceptions.

Ensuite, PageSpeed Insights : entre une URL, et si elle dispose de données Field, tu verras les métriques CrUX (LCP, FID/INP, CLS) sur les 28 derniers jours. Avantage : tu peux tester n'importe quelle URL publique. Inconvénient : si l'URL manque de trafic, tu n'auras que les données Lab (Lighthouse).

Enfin, CrUX via BigQuery (gratuit) : dataset public mis à jour mensuellement. Tu peux requêter les données par origin (domaine complet) ou par URL spécifique si elle a suffisamment de trafic. C'est la méthode la plus puissante pour analyser les segments (connexion, device, géo), mais ça demande des compétences SQL.

Que faire si mes données Lab et Field divergent fortement ?

Segmente les données CrUX par dimension : connexion (4G, 3G, 2G/slow), device (mobile, desktop, tablet), et si possible géolocalisation. Tu découvriras souvent qu'un segment spécifique plombe la moyenne — par exemple, les utilisateurs 3G en Inde ou en Afrique subsaharienne si ton CDN n'a pas de PoP locaux.

Côté technique, vérifie les ressources tierces (analytics, pixels publicitaires, chat en ligne, widgets sociaux). Lighthouse les ignore souvent en mode simulé, mais en conditions réelles, un script tiers mal optimisé peut ajouter 2-3 secondes au LCP ou déclencher des layout shifts massifs. Utilise WebPageTest avec un profil mobile 3G pour reproduire les conditions Field.

Si tu constantes que les mobiles sont catastrophiques mais desktop acceptable, concentre-toi sur le poids des images et l'exécution JavaScript. Les CPU mobiles sont 5 à 10 fois plus lents qu'un desktop moderne — un bundle JS de 500Ko qui parse en 200ms sur ton Mac prendra 2 secondes sur un Android moyen de gamme.

Quelles erreurs éviter lors de l'optimisation pour les Field data ?

Ne te base pas uniquement sur ton environnement de développement. Tester sur un MacBook Pro avec fibre ne te dira rien. Utilise des vrais devices milieu de gamme (Android ~200-300€, 2-3 ans d'âge) et simule des connexions dégradées (3G, latence 200ms+). Chrome DevTools permet de throttle CPU et réseau — abuse-en.

Autre piège : optimiser pour Lighthouse au détriment de l'expérience réelle. Exemple classique — lazy-load agressif qui diffère toutes les images, même above-the-fold. Lighthouse adore (moins de requêtes initiales), mais en Field, le LCP explose parce que l'image hero charge trop tard. Ou encore, inline tout le CSS critique pour éliminer les render-blocking — ton Lighthouse grimpe, mais le HTML pèse maintenant 150Ko et le Time to First Byte augmente.

Enfin, ne néglige pas la stabilité visuelle (CLS). Les données Field capturent les layout shifts durant toute la session de navigation, y compris ceux causés par des comportements utilisateur (scroll rapide, tap pendant le chargement). Un carousel qui shift au chargement, des encarts publicitaires sans dimensions réservées, des polices web qui provoquent du FOIT/FOUT — tout ça détruit le CLS en conditions réelles même si Lighthouse ne le détecte pas toujours.

• Consulter Search Console > Core Web Vitals au moins hebdomadairement pour suivre les tendances Field
• Utiliser PageSpeed Insights en priorité pour évaluer les URLs individuelles (données Field + suggestions Lab)
• Segmenter les données CrUX par connexion et device pour identifier les populations problématiques
• Tester sur de vrais devices mobiles milieu de gamme avec connexions 3G simulées
• Valider que les optimisations Lighthouse n'impactent pas négativement l'expérience réelle (attention au lazy-load agressif, au CSS inline excessif)
• Monitorer les ressources tierces (analytics, ads, chat) qui pèsent souvent plus lourd en Field qu'en Lab