Faut-il vraiment attendre 30 jours pour voir l'impact de vos optimisations Core Web Vitals dans PageSpeed Insights ?

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

Les données de laboratoire (lab data) sont générées instantanément par Lighthouse lors d'un test synthétique dans des conditions contrôlées. Elles reflètent la performance théorique de votre page à l'instant T, avec une connexion 4G simulée et un appareil mobile émulé.

Les données terrain (field data), elles, proviennent du Chrome User Experience Report (CrUX). Elles agrègent les expériences réelles de milliers d'utilisateurs Chrome sur une période de 28 jours glissants. C'est cette deuxième métrique qui compte pour le ranking, mais c'est aussi celle qui traîne un délai incompressible.

Pourquoi ce délai de 30 jours existe-t-il ?

Le CrUX collecte des données anonymisées des navigateurs Chrome pendant 28 jours consécutifs, puis agrège et publie ces statistiques avec un décalage de quelques jours supplémentaires. Si vous déployez une optimisation aujourd'hui, les premiers visiteurs réels qui en bénéficient entrent dans la fenêtre de collecte, mais les anciens visiteurs qui ont subi l'ancienne version continuent de peser dans la moyenne.

Ce n'est qu'au bout de 30 jours complets que 100 % de la fenêtre glissante reflète la nouvelle version de votre site. Entre-temps, les field data mélangent ancien et nouveau, ce qui peut brouiller votre lecture si vous cherchez un signal immédiat.

Quelles métriques sont concernées par ce délai ?

Toutes les métriques Core Web Vitals remontées dans PageSpeed Insights via le CrUX subissent ce délai : Largest Contentful Paint (LCP), First Input Delay (FID) ou Interaction to Next Paint (INP) selon la version, et Cumulative Layout Shift (CLS).

Les données de laboratoire, elles, incluent des métriques supplémentaires comme le Time to Interactive ou le Speed Index, mais elles ne reflètent pas l'expérience réelle des utilisateurs. Elles servent d'indicateur avancé, pas de vérité terrain.

• Field data (CrUX) : délai de 30 jours, données réelles agrégées, impact sur le ranking
• Lab data (Lighthouse) : instantané, conditions synthétiques, utile pour le debug rapide
• Fenêtre glissante : 28 jours de collecte + quelques jours de traitement
• Métriques concernées : LCP, FID/INP, CLS uniquement pour les field data
• Visibilité dans PSI : onglet séparé "Discover what your real users are experiencing" pour le CrUX

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est un rappel bienvenu. On voit régulièrement des clients ou des confrères paniquer 48 heures après un déploiement parce que les field data de PageSpeed Insights n'ont pas bougé d'un iota. Le délai de 30 jours est documenté depuis longtemps dans la FAQ du CrUX, mais il reste méconnu ou sous-estimé.

Ce qui coince, c'est que PageSpeed Insights affiche ces deux jeux de données côte à côte sans toujours clarifier que l'un est un instantané théorique et l'autre une moyenne glissante sur quatre semaines. Le praticien non averti va naturellement comparer les deux, voir une divergence énorme, et se demander si son optimisation fonctionne. Réponse : peut-être, mais il faudra attendre.

Dans quels cas ce délai pose-t-il un problème stratégique ?

Si vous travaillez sur un site à faible trafic, les field data peuvent ne jamais apparaître dans PageSpeed Insights, même après 30 jours. Le CrUX exige un volume minimal de visiteurs Chrome pour publier des statistiques — Google ne communique pas de seuil précis, mais on estime qu'il faut plusieurs milliers de pages vues par mois. [A vérifier] : aucun chiffre officiel n'a été donné par Google sur ce minimum.

Autre cas problématique : les sites fortement saisonniers. Si vous déployez une optimisation en janvier et que votre pic de trafic tombe en décembre, vous risquez de manquer de données représentatives pendant des mois. Les field data de janvier ne refléteront pas la charge réelle que subira le site en haute saison.

Quelles nuances faut-il apporter à cette recommandation ?

Mueller suggère d'utiliser les lab data pour vérifier rapidement, puis d'attendre 30 jours. C'est pragmatique, mais incomplet. Les lab data testent une page isolée, dans des conditions idéales, sans tenir compte des scripts tiers, des variations réseau réelles, ou du comportement utilisateur (scroll, clics). Un bon score Lighthouse ne garantit pas un bon CrUX.

Il manque un maillon : les tests RUM (Real User Monitoring) maison, via des outils comme SpeedCurve, Datadog RUM, ou même l'API web-vitals en JavaScript. Vous pouvez ainsi suivre vos Core Web Vitals en quasi-temps réel sur votre propre analytics, sans attendre que Google agrège. C'est ce qui permet de détecter une régression en quelques heures, pas en 30 jours.

Que faut-il faire concrètement avant et après un déploiement d'optimisation ?

Avant tout déploiement, prenez un snapshot de vos métriques actuelles : field data CrUX dans PageSpeed Insights, mais aussi dans la Search Console (rapport Core Web Vitals) et, si possible, dans un outil RUM propriétaire. Notez la date précise du déploiement.

Immédiatement après, lancez plusieurs tests Lighthouse sur des pages représentatives. Si les lab data ne s'améliorent pas, c'est que votre optimisation n'a pas fonctionné comme prévu — inutile d'attendre 30 jours pour le savoir. Si les lab data progressent, vous avez un signal positif rapide, mais non définitif.

Comment interpréter les écarts entre lab et field pendant la période de transition ?

Entre J+1 et J+30, les field data vont évoluer progressivement, mais pas linéairement. Vous pouvez voir un léger mieux à J+15, puis une stagnation, puis un nouveau bond à J+28. C'est normal : la fenêtre glissante incorpore peu à peu la nouvelle version.

Si à J+30 complet les field data ne rejoignent toujours pas les lab data, plusieurs hypothèses : trafic mobile vs desktop (CrUX agrège tous devices, Lighthouse teste mobile par défaut), scripts tiers non présents en lab, cache CDN qui tarde à se purger, ou pire, une régression invisible en lab mais réelle sur certains segments d'utilisateurs (anciens navigateurs, connexions 3G résiduelles). Creusez avec un RUM.

Quelles erreurs éviter pendant cette période d'attente ?

Ne déployez pas cinq optimisations successives à trois jours d'intervalle. Vous ne pourrez jamais démêler ce qui a fonctionné. Espacez vos itérations de 30 jours minimum si vous voulez isoler les effets dans les field data, ou alors acceptez de ne mesurer que l'impact cumulé.

Autre piège : se fier uniquement aux field data agrégées au niveau origine (tout le site). PageSpeed Insights et CrUX permettent de filtrer par URL ou groupe d'URL si le volume le permet. Une homepage peut afficher un LCP excellent pendant que les fiches produit restent catastrophiques. Segmentez vos analyses par typologie de page.

• Prendre un snapshot complet des métriques CrUX avant déploiement (PageSpeed Insights + Search Console)
• Tester immédiatement en lab après déploiement pour vérifier que l'optimisation fonctionne théoriquement
• Mettre en place un monitoring RUM maison si possible, pour un suivi en quasi-temps réel
• Espacer les déploiements d'optimisations de 30 jours si vous voulez mesurer l'impact isolé de chacune
• Comparer les field data par groupe de pages (homepage, fiches produit, blog) et non seulement au niveau site
• Attendre 30 jours complets avant de tirer des conclusions définitives sur l'impact réel