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 s'il a fonctionné." 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, et une fois que vous avez compris 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, et non de 28

Le Chrome User Experience Report (CrUX) se met à jour quotidiennement vers 04:00 UTC. Lorsque vous interrogez l'CrUX API, la réponse inclut un champ collectionPeriod qui indique la plage de dates exacte. La date de fin correspond généralement à hier ou avant-hier. Depuis décembre 2024, PageSpeed Insights affiche également ces dates, vous pouvez donc le constater 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, non pas pour retarder vos données, mais pour lisser le bruit. Une seule mauvaise journée ne fait pas chuter votre score. Une seule bonne journée ne le sauve pas. La fenêtre vous donne une image stable et représentative de la façon dont les vrais utilisateurs expérimentent votre site.

Chaque jour, les données de la journée la plus ancienne disparaissent et celles de la journée la plus récente sont ajoutées. Il n'y a pas de délai. La fenêtre avance simplement, un jour à la fois.

Une chose que beaucoup de gens comprennent mal : il s'agit d'un 75e centile, et non d'une moyenne. Plusieurs guides populaires (y compris celui de Vercel) l'appellent à tort une moyenne. La distinction est importante. Un p75 signifie que 75 % des expériences utilisateur se situent à cette valeur ou en dessous. Il est plus résistant au changement qu'une moyenne car les valeurs aberrantes du côté rapide ne le tirent pas vers le bas aussi rapidement.

Pourquoi les améliorations semblent lentes

Lorsque vous déployez un correctif de performance, vos nouvelles données se mélangent avec jusqu'à 27 jours d'anciennes données. Le 75e centile se déplace 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 entièrement 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 qui s'y trouvaient déjà. Si votre site était constamment lent, il y a beaucoup de billes rouges à remplacer. S'il était à la limite, la boîte devient verte beaucoup plus rapidement.

À 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.
• Jour 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 changements peuvent apparaître.
• Jour 7 : Environ un quart de la fenêtre contient des données post-correctif. Les tendances commencent à devenir visibles dans le CrUX History.
• Jour 14 : La moitié de la fenêtre est constituée de nouvelles données. Si votre correctif était significatif (disons, un LCP passant de 4s à 2s), le p75 se sera déplacé de manière notable.
• Jour 28 : La fenêtre est entièrement rafraîchie. CrUX reflète désormais vos performances actuelles.

L'ampleur du changement dépend de trois éléments : l'importance de l'amélioration, le volume de 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 :

• CrUX API et PageSpeed Insights : mis à jour quotidiennement (~2 jours de décalage). C'est ce que la plupart des gens utilisent.
• CrUX History API : mis à jour de manière hebdomadaire le lundi, avec des données allant 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 suivant 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 impatiemment que vos chiffres bougent, vérifiez PageSpeed Insights (quotidien), et non BigQuery (mensuel).

N'attendez pas 28 jours. Utilisez le RUM.

CrUX correspond aux données de Google. Cela vous indique comment Google perçoit votre site. Mais vous n'avez pas besoin de rester assis à attendre. Avec le Real User Monitoring vous pouvez suivre les Core Web Vitals par jour ou même par chargement de page. Vous saurez en quelques heures si votre correctif fonctionne, et non 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 les réussissent toujours pas, ne laissez pas le mythe du "délai de 28 jours" vous empêcher d'apporter des modifications. Les données sont presque en temps réel. La fenêtre ne fait que les lisser.