Pourquoi le délai de 28 jours des Core Web Vitals est un mythe

Démystifier le mythe du délai de 28 jours des Core Web Vitals

Je l'entends tout le temps : « Nous avons déployé le correctif, maintenant nous devons attendre 28 jours pour voir si ça a marché. » C'est faux. Les données ne datent pas de 28 jours. Elles datent d'environ deux jours. La confusion vient de la façon dont Google calcule les chiffres. Une fois que vous comprenez cela, la panique des 28 jours disparaît.

Dernière révision par Arjen Karel en mars 2026

Les données CrUX datent de deux jours, pas de 28

Le Chrome User Experience Report (CrUX) se met à jour quotidiennement vers 04:00 UTC. Quand vous interrogez l'API CrUX, la réponse inclut un champ collectionPeriod qui indique la plage de dates exacte. La date de fin est généralement hier ou avant-hier. Depuis décembre 2024, PageSpeed Insights affiche aussi ces dates. Vous pouvez le voir par vous-même.

Alors d'où viennent ces 28 jours ?

Ce que vous voyez dans PageSpeed Insights est le 75e centile calculé sur les 28 derniers jours de données d'utilisateurs réels. Google utilise une fenêtre glissante de 28 jours. Ce n'est pas pour retarder vos données, mais pour lisser le bruit. Un seul mauvais jour ne fait pas plonger votre score. Un seul bon jour ne le sauve pas. La fenêtre donne une image stable et représentative de l'expérience des utilisateurs réels sur votre site.

Chaque jour, les données du jour le plus ancien disparaissent et celles du jour le plus récent sont ajoutées. Il n'y a aucun délai. La fenêtre avance simplement, un jour à la fois.

Beaucoup se trompent sur ce point : c'est un 75e centile, pas une moyenne. Plusieurs guides populaires (dont celui de Vercel) l'appellent à tort une moyenne. La distinction compte. Un p75 signifie que 75 % des expériences utilisateur sont à cette valeur ou en dessous. C'est plus résistant au changement qu'une moyenne. Les valeurs extrêmes du côté rapide ne le tirent pas vers le bas aussi vite.

Pourquoi les améliorations semblent lentes

Quand vous déployez un correctif de performance, vos nouvelles données se mélangent avec jusqu'à 27 jours de données anciennes. Le 75e centile se décale progressivement, pas du jour au lendemain.

Voyez les choses ainsi : Vous avez une boîte de 28 billes rouges. Chaque jour, vous retirez une ancienne bille rouge et la remplacez par une nouvelle bille verte. Il faudra 28 jours complets pour rafraîchir toute la boîte. Mais il n'y a jamais eu de délai !

La vitesse à laquelle la boîte devient majoritairement verte (le déplacement du 75e centile) dépend du nombre de billes rouges déjà présentes. Si votre site était constamment lent, il y a beaucoup de billes rouges à remplacer. S'il était limite, la boîte devient verte beaucoup plus vite.

À quoi s'attendre après le déploiement d'un correctif

Voici une chronologie réaliste de ce qui se passe après le déploiement d'une amélioration des performances :

• Jour 0 : Vous déployez le correctif. Rien ne change encore dans CrUX.
• Jours 2-3 : Les premiers points de données améliorés entrent dans la fenêtre de 28 jours. Si vous surveillez de près, de minuscules décalages peuvent apparaître.
• Jour 7 : Environ un quart de la fenêtre contient des données d'après correctif. Des tendances commencent à devenir visibles dans l'historique CrUX.
• Jour 14 : La moitié de la fenêtre contient de nouvelles données. Si votre correctif était important (par exemple, le LCP passant de 4 s à 2 s), le p75 aura bougé de façon visible.
• Jour 28 : La fenêtre est entièrement rafraîchie. CrUX reflète maintenant vos performances actuelles.

L'ampleur du changement dépend de trois choses : la taille de l'amélioration, le trafic de votre site (plus de trafic signifie plus de nouveaux points de données par jour), et la constance du correctif sur tous les chargements de page.

Trois endroits, trois vitesses de mise à jour

Toutes les données CrUX ne se mettent pas à jour au même rythme. C'est une autre source de confusion :

• L'API CrUX et PageSpeed Insights : mis à jour quotidiennement (décalage d'environ 2 jours). C'est ce que la plupart des gens utilisent.
• L'API CrUX History : mise à jour chaque semaine le lundi, avec les données jusqu'au samedi précédent. Alimente l'outil CrUX History et les graphiques de tendances.
• CrUX BigQuery : mis à jour mensuellement, le deuxième mardi après la fin de la période de collecte. Si vous ne vérifiez que BigQuery, cela peut vraiment ressembler à un délai d'un mois.

Si vous attendez avec impatience que vos chiffres bougent, vérifiez PageSpeed Insights (quotidien), pas BigQuery (mensuel).

N'attendez pas 28 jours. Utilisez le RUM.

CrUX, ce sont les données de Google. Cela vous montre comment Google voit votre site. Mais vous n'avez pas à rester assis à attendre. Avec le Real User Monitoring, vous pouvez suivre les Core Web Vitals jour par jour, ou même chargement de page par chargement de page. Vous saurez en quelques heures si votre correctif fonctionne, pas en quelques jours.

CrUX suit actuellement 18,56 millions d'origines avec un taux de réussite aux Core Web Vitals de 55,8 %. Si votre site fait partie des 44 % qui ne passent toujours pas, ne laissez pas le mythe du « délai de 28 jours » vous empêcher de faire des changements. Les données sont presque en temps réel. La fenêtre ne fait que les lisser.