Pourquoi vos optimisations Core Web Vitals mettent-elles 28 jours à apparaître dans Search Console ?

D'où viennent réellement les données Core Web Vitals affichées dans Search Console ?

Les métriques Core Web Vitals que vous consultez dans Search Console ne proviennent pas d'un crawl actif de Googlebot. Elles sont extraites du Chrome User Experience Report (CrUX), un dataset public qui agrège les performances réelles mesurées par des millions d'utilisateurs Chrome.

Ce dataset collecte les expériences vécues sur une fenêtre glissante de 28 jours. Concrètement : les chiffres que vous voyez aujourd'hui dans Search Console reflètent les performances mesurées entre J-28 et J. Pas celles d'hier, pas celles de la semaine dernière — celles du dernier mois complet.

Pourquoi Lighthouse affiche-t-il des résultats différents de Search Console ?

Lighthouse effectue un test synthétique en laboratoire, dans des conditions contrôlées. Il simule un chargement sur un appareil standardisé, avec une connexion calibrée. C'est utile pour détecter un problème, mais ça ne reflète pas l'expérience réelle de vos visiteurs.

Search Console, lui, affiche des données terrain (field data) issues du CrUX. Ces données agrègent les performances mesurées chez de vrais utilisateurs, avec leurs connexions variables, leurs appareils divers, leurs extensions Chrome actives. Un écart entre les deux outils est donc parfaitement normal — et c'est le CrUX qui fait foi pour le classement.

Que signifie concrètement ce délai de 28 jours pour un praticien ?

Si vous déployez une optimisation aujourd'hui — disons, la suppression d'un script bloquant ou la mise en cache d'une police — vous ne pourrez valider son impact réel qu'environ un mois plus tard. Entre-temps, les anciennes performances continuent de polluer les moyennes affichées dans Search Console.

Ce décalage impose une discipline : impossible de faire du test-and-learn rapide sur les Core Web Vitals comme on le ferait sur un test A/B de contenu. Chaque modification nécessite un suivi long terme, et les corrections urgentes ne produisent aucun effet visible immédiat dans les rapports Google.

• CrUX agrège les données terrain sur 28 jours glissants, pas en temps réel
• Lighthouse teste en laboratoire, CrUX mesure l'expérience réelle des utilisateurs
• Un déploiement technique aujourd'hui apparaîtra dans Search Console environ 4 semaines plus tard
• Les corrections urgentes ne permettent pas de validation immédiate dans les rapports officiels Google
• La planification des optimisations doit intégrer cette latence incompressible

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

Oui, et c'est même une des rares communications de Google qui ne souffre d'aucune ambiguïté. Le délai de 28 jours correspond exactement à la fenêtre d'échantillonnage documentée du CrUX. Sur le terrain, les praticiens qui suivent leurs métriques avec PageSpeed Insights API ou directement via BigQuery constatent systématiquement ce décalage.

Ce qui est moins souvent précisé : cette latence varie légèrement selon le volume de trafic Chrome de votre site. Un site avec un trafic faible peut mettre plus de 28 jours à voir ses données se stabiliser — voire ne jamais apparaître dans CrUX si le seuil minimal de visiteurs Chrome n'est pas atteint. [À vérifier] : Google ne publie pas officiellement ce seuil, mais les observations convergent vers quelques milliers de visites Chrome mensuelles.

Quelles nuances faut-il apporter à cette règle des 28 jours ?

Le délai de 28 jours est une moyenne de collecte, pas une garantie. Une optimisation déployée aujourd'hui commencera à influencer les données dès demain — mais elle ne représentera qu'1/28e du jeu de données agrégé. Il faut attendre que l'intégralité de la fenêtre glissante soit renouvelée pour voir l'impact complet.

Autre nuance : si vous corrigez un problème sur une URL spécifique mais que votre site en compte des milliers, l'impact global dans Search Console restera dilué. Les rapports CWV agrègent souvent par groupes d'URLs similaires, pas URL par URL. Un correctif localisé ne fera pas basculer tout un groupe dans le vert immédiatement.

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

Si votre site ne reçoit pas assez de trafic Chrome pour figurer dans le CrUX, cette règle devient caduque : vous n'aurez jamais de données terrain dans Search Console, quel que soit le délai. Dans ce cas, Google se rabat sur des données d'origine (origin-level) ou sur rien du tout — et les Core Web Vitals ne joueront aucun rôle dans votre classement, faute de mesure.

Autre exception : les sites qui subissent une migration technique brutale (changement de CDN, refonte complète) peuvent voir leurs données CrUX se réinitialiser partiellement. Le délai de 28 jours reste valable, mais les anciennes données polluent moins vite qu'on ne le croit. [À vérifier] : aucune documentation officielle ne précise comment Google gère les discontinuités techniques dans CrUX.

Comment planifier vos optimisations en tenant compte de ce délai ?

Travaillez par sprints de 6 semaines minimum : 2 semaines de déploiement, 4 semaines d'observation. Documentez chaque modification technique avec sa date exacte pour pouvoir corréler les variations de métriques un mois plus tard. Sans cette rigueur, vous ne saurez jamais quel changement a produit quel effet.

Utilisez des outils tiers comme Cloudflare RUM, SpeedCurve ou Sentry Performance pour obtenir des données terrain en temps réel. Ces outils ne remplaceront jamais CrUX pour le ranking, mais ils vous permettent de valider qu'une optimisation fonctionne avant d'attendre un mois. C'est la seule façon de détecter rapidement une régression accidentelle.

Quelles erreurs éviter lors du suivi des Core Web Vitals ?

Ne paniquez pas si vos scores Lighthouse restent au vert alors que Search Console affiche du rouge. Tant que les données CrUX ne se sont pas rafraîchies, l'ancien état pollue les rapports. Inversement, ne vous reposez pas sur vos lauriers si Lighthouse affiche 100/100 : seules les performances réelles comptent.

Évitez de multiplier les corrections en rafale. Si vous déployez trois optimisations en une semaine, vous ne pourrez pas isoler laquelle a fonctionné quand les données CrUX se mettront à jour. Procédez par itérations séquentielles, espacées d'au moins 28 jours, pour garder un lien de causalité clair.

Comment vérifier que vos optimisations produisent l'effet attendu ?

Interrogez directement l'API PageSpeed Insights ou l'API CrUX pour obtenir les données terrain de vos URLs critiques. Ces APIs fournissent les mêmes métriques que Search Console, mais avec un niveau de granularité supérieur. Vous pourrez ainsi suivre l'évolution semaine par semaine, même si Search Console n'affiche qu'une vue agrégée.

Mettez en place un monitoring synthétique continu (Lighthouse CI, WebPageTest automation) pour détecter les régressions au moment du déploiement. Même si ces tests ne reflètent pas l'expérience réelle, ils vous alertent immédiatement si un commit casse les performances — sans attendre 28 jours pour le découvrir dans Search Console.

• Planifiez vos optimisations par sprints de 6 semaines minimum pour isoler les effets
• Documentez chaque modification avec sa date de déploiement exacte
• Utilisez des outils RUM tiers pour valider les correctifs en temps réel
• Interrogez régulièrement les APIs CrUX et PageSpeed Insights pour un suivi granulaire
• Ne multipliez pas les changements en rafale : procédez par itérations séquentielles
• Automatisez un monitoring synthétique pour détecter les régressions au commit