Pourquoi vos Core Web Vitals mettent-ils 28 jours à se mettre à jour dans Search Console ?

D'où vient ce délai de 28 jours exactement ?

Google utilise le Chrome User Experience Report (CrUX) comme source de données pour les Core Web Vitals dans Search Console. Ce rapport agrège les données de navigation réelles collectées auprès de millions d'utilisateurs Chrome qui ont accepté le partage de leurs statistiques d'usage.

Le délai de 28 jours n'est pas un bug ou une lenteur technique de Search Console. C'est une fenêtre d'agrégation volontaire : Google compile les métriques sur une période glissante de 28 jours pour obtenir un échantillon statistiquement significatif et filtrer les variations ponctuelles (pic de trafic, incident technique temporaire, déploiement d'une mise à jour progressive).

Que signifie concrètement « agrégation sur 28 jours glissants » ?

Chaque jour, les données affichées dans Search Console représentent la moyenne des 28 derniers jours. Si vous consultez vos Core Web Vitals le 15 avril, vous voyez les données agrégées du 18 mars au 14 avril.

Cette fenêtre glissante se déplace quotidiennement : le lendemain (16 avril), la période sera du 19 mars au 15 avril. Les données les plus anciennes sortent progressivement, les plus récentes entrent au compte-gouttes. C'est pourquoi une amélioration drastique ne se traduit jamais par un changement brutal dans Search Console — elle se dilue progressivement sur 28 jours.

Pourquoi Google n'affiche-t-il pas les données en temps réel ?

Les métriques de performance Web sont hautement volatiles. Un utilisateur sur une connexion 4G lente obtient un LCP de 6 secondes, un autre sur fibre obtient 1,2 seconde pour la même page. Un pic de trafic soudain peut charger vos serveurs et dégrader temporairement vos métriques.

En agrégeant sur 28 jours, Google lisse ces variations et obtient une mesure représentative de l'expérience réelle de vos visiteurs. C'est cette moyenne qui est utilisée comme signal de classement, pas les performances instantanées d'une journée donnée.

• Les données Search Console sont toujours en retard de 28 jours par rapport à vos optimisations réelles.
• Une amélioration progressive mettra environ 4 semaines à se refléter pleinement dans l'interface.
• Les variations quotidiennes ne sont pas visibles — seules les tendances durables émergent.
• Le CrUX est basé sur des utilisateurs Chrome réels, pas sur des tests synthétiques (Lighthouse, PageSpeed Insights).
• Seules les URLs avec un trafic suffisant apparaissent dans le CrUX (seuil non documenté publiquement).

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

Oui, et c'est observable directement dans le BigQuery public CrUX. Les datasets CrUX sont publiés mensuellement avec un décalage d'environ 2 semaines, et chaque ligne agrège 28 jours de données. Quand vous déployez une optimisation majeure (lazy-loading, CDN, refonte du CSS critique), vous constatez effectivement un délai incompressible avant de voir l'impact dans Search Console.

Ce qui pose problème en pratique : les clients SEO s'attendent souvent à des résultats immédiats après un chantier de performance. Il faut intégrer ce délai de latence de 4 semaines dans vos plannings projet et vos reportings — sinon vous créez une frustration inutile.

Quelles nuances faut-il apporter à cette explication ?

Mueller dit que le délai est dû à la "méthode de collecte et d'agrégation", mais il omet un point critique : le seuil de trafic minimal. Une URL qui reçoit 10 visites par jour n'apparaîtra jamais dans le CrUX, peu importe ses performances. Google ne documente pas ce seuil précisément — [A vérifier] sur vos propres sites via l'API CrUX.

Autre nuance : les données CrUX sont collectées uniquement sur Chrome desktop et mobile, avec des utilisateurs ayant activé le partage de statistiques. Ce n'est pas un échantillon parfaitement représentatif de votre audience réelle si vous avez un trafic significatif sur Firefox, Safari ou Edge (bien que Chromium partage probablement les données).

Dans quels cas cette agrégation sur 28 jours pose-t-elle problème ?

Pour les sites saisonniers ou les lancements de produits, c'est un cauchemar. Imaginez un e-commerce qui lance une collection capsule le 1er avril : même si le site est parfaitement optimisé, Search Console affichera encore des données polluées par le trafic de mars jusqu'au 28 avril. Vous ne pouvez pas évaluer l'impact SEO réel de votre lancement avant un mois complet.

Pareil pour les sites d'actualité ou événementiels : un pic de trafic lié à une actualité chaude peut dégrader vos Core Web Vitals pendant 28 jours, même si vous corrigez le problème en 48h. L'agrégation joue contre vous quand la volatilité est intrinsèque à votre modèle.

Comment anticiper ce délai dans vos roadmaps SEO ?

Planifiez vos chantiers de performance au moins 6 semaines avant une échéance critique (lancement produit, pic saisonnier, campagne marketing). Comptez 2 semaines pour implémenter et tester, puis 4 semaines pour que les données CrUX se stabilisent dans Search Console.

Si vous travaillez en agile avec des sprints courts, intégrez un décalage de validation : ne validez pas un objectif CWV immédiatement après déploiement, mais au sprint suivant (2-3 semaines plus tard). Communiquez clairement ce délai aux stakeholders pour éviter les malentendus sur les délais de ROI.

Quels outils utiliser en complément de Search Console ?

Search Console est utile pour le suivi long terme, mais trop lent pour le pilotage opérationnel. Mettez en place un outil de Real User Monitoring (RUM) comme SpeedCurve, Cloudflare Web Analytics ou un script custom envoyant les métriques CWV vers votre propre base de données.

Ces outils vous donnent un feedback quotidien, voire horaire, sur vos performances réelles. Vous détectez une régression de LCP le jour même, pas 3 semaines plus tard. C'est essentiel pour itérer rapidement et corriger les bugs avant qu'ils ne polluent vos données CrUX pendant un mois entier.

Faut-il attendre 28 jours avant de valider une optimisation ?

Non, mais nuancez votre validation. Utilisez Lighthouse et PageSpeed Insights en mode lab pour une validation technique immédiate : si votre LCP passe de 4s à 1,5s en conditions contrôlées, l'optimisation fonctionne. Mais ne proclamez pas victoire tant que les données CrUX réelles ne confirment pas.

Documentez vos déploiements avec une date précise dans un tableau de bord. Quand vous consultez Search Console 4 semaines plus tard, vous pouvez corréler l'amélioration aux actions prises. Sans cette traçabilité, impossible de savoir si la hausse de score vient de votre refonte CSS ou d'une baisse de trafic coïncidente.

• Planifiez les chantiers CWV au moins 6 semaines avant les échéances critiques.
• Mettez en place un outil RUM pour un pilotage quotidien en complément de Search Console.
• Documentez chaque déploiement avec une date et une description dans un changelog SEO.
• Testez en lab (Lighthouse) pour validation technique, mais attendez 28 jours pour validation CrUX.
• Communiquez ce délai structurel aux clients et stakeholders dès le kickoff projet.
• Surveillez les pics de trafic anormaux qui peuvent polluer vos métriques pendant un mois.