Dimension Core/Dash : Visiteur récurrent

Dimension : Comportement utilisateur : Visiteur récurrent (fv)

La dimension Visiteur récurrent (Repeat Visitor) divise vos données de performance en deux populations : les utilisateurs qui ont déjà visité votre site et ceux qui ne l'ont pas fait. La différence technique entre ces groupes est le cache du navigateur. Un visiteur régulier charge vos polices, scripts et images depuis le disque. Un nouveau visiteur récupère chaque octet depuis le réseau.

Cela importe car votre score LCP agrégé est une moyenne pondérée des deux. Si 40 % de vos sessions sont de nouveaux visiteurs, leurs temps de chargement à cache froid tirent votre p75 vers le haut. Sans cette dimension, vous ne pouvez pas dire si une régression du LCP est un véritable problème d'infrastructure ou un pic temporaire d'acquisition de nouveaux utilisateurs.

Pourquoi l'écart de performance est plus grand que vous ne le pensez

Le cache du navigateur élimine des chaînes de requêtes entières pour les visiteurs récurrents. Sur un site de contenu typique, un visiteur récurrent saute la recherche DNS, le handshake TCP, la négociation TLS et la réponse du serveur pour chaque ressource en cache. La ressource LCP elle-même est souvent servie depuis le cache mémoire en moins de 5 ms, au lieu de prendre 200 ms à 800 ms sur le réseau. Ce n'est pas une amélioration marginale : c'est une différence structurelle dans la façon dont la page se charge.

Dans les données CoreDash à travers les sites surveillés, les visiteurs récurrents affichent généralement des scores LCP 35 % à 60 % inférieurs à ceux des nouveaux visiteurs sur les mêmes pages. L'écart est le plus grand sur les pages chargées en images où l'image héros est volumineuse et le serveur d'origine géographiquement éloigné de l'utilisateur. Sur les pages avec un rendu côté serveur et un élément LCP textuel, l'écart se réduit car le délai de chargement du texte est proche de zéro pour les deux groupes.

Les différences d'INP entre les deux groupes sont plus faibles mais toujours présentes. Les nouveaux visiteurs déclenchent souvent plus d'analyse JavaScript lors du premier chargement, car les bundles de modules sont évalués pour la première fois. Les visiteurs récurrents bénéficient du cache de code de V8, qui stocke le bytecode compilé et ignore complètement l'étape d'analyse et de compilation. Sur les pages fortement chargées en JavaScript, cela peut réduire le temps de traitement de 50 ms à 150 ms.

Lecture des trois valeurs

0 : Visiteur récurrent

Le navigateur a signalé qu'il ne s'agit pas de la première session de l'utilisateur sur votre origine. Les ressources en cache sont disponibles. Sur la plupart des sites marketing et éditoriaux suivis dans CoreDash, les visiteurs récurrents représentent 55 % à 70 % de toutes les sessions. Leurs données de performance constituent votre base de référence à cache chaud : le meilleur scénario pour les utilisateurs réels qui connaissent votre site. Si votre LCP est mauvais ici, le problème n'est pas le cache. Examinez plutôt les ressources bloquant le rendu, le temps de réponse du serveur ou le délai de rendu (render delay).

1 : Nouveau visiteur

Aucun cache. Le navigateur récupère chaque ressource depuis le réseau. C'est votre pire scénario à cache froid, et cela représente la première impression pour tout utilisateur qui vous trouve via une recherche organique, une publicité payante ou un partage social. Les nouveaux visiteurs représentent généralement 30 % à 45 % des sessions. Leurs scores LCP sont de 300 ms à 700 ms plus élevés que ceux des visiteurs récurrents sur les pages basées sur des images. Si le LCP de vos nouveaux visiteurs échoue au seuil de 2,5 s mais que le LCP de vos visiteurs récurrents le franchit, votre objectif d'optimisation est clair : réduisez la taille et le délai de la ressource LCP elle-même, car vous ne pouvez pas compter sur le cache pour cette audience.

2 : Non mesuré

CoreDash n'a pas pu déterminer le type de visite pour cette session. Cela se produit généralement lorsque le navigateur bloque l'accès au stockage requis pour distinguer les nouveaux visiteurs des visiteurs récurrents, ou lorsqu'une configuration de navigateur axée sur la confidentialité empêche la vérification. Sur la plupart des sites, ce segment représente moins de 5 % des sessions. Traitez-le comme un bruit de fond plutôt que comme un segment à optimiser.

Flux de travail de débogage

1. Établissez votre répartition de base : Ouvrez la dimension Repeat Visitor dans CoreDash et notez le pourcentage de nouvelles sessions par rapport aux sessions récurrentes. Si les nouveaux visiteurs représentent plus de 50 % du trafic, les performances à cache froid constituent votre user experience dominante et doivent être la cible d'optimisation principale.
2. Comparez le LCP par type de visite : Filtrez uniquement sur les nouveaux visiteurs et enregistrez le LCP au p75. Ensuite, filtrez sur les visiteurs récurrents et enregistrez la même métrique. Un écart supérieur à 500 ms indique que la taille des ressources ou le temps de récupération réseau est le goulot d'étranglement. Un écart inférieur à 200 ms suggère des problèmes côté rendu qui affectent les deux groupes de manière égale.
3. Ciblez directement la ressource LCP : Pour les nouveaux visiteurs avec un LCP lent, la solution consiste à réduire le temps de chargement de la ressource. Compressez l'image LCP, servez-la depuis un nœud périphérique de CDN proche de vos utilisateurs, et appliquez fetchpriority="high". Ces gains persistent quel que soit l'état du cache. Ne comptez pas sur la mise en cache pour compenser une ressource LCP surdimensionnée ou servie lentement.
4. Validez avec la dimension Navigation Type : Croisez les données avec la dimension Navigation Type. Les navigations de type rechargement (reload) et retour/suivant (back-forward) sont orientées vers les visiteurs récurrents. Si le LCP de vos visiteurs récurrents semble étonnamment lent, une proportion élevée de navigations de rechargement (où les ressources en cache sont revalidées plutôt que servies directement) peut en être la cause.

Règle d'ingénierie empirique

• Cible LCP pour les nouveaux visiteurs : Moins de 2,5 s au p75. C'est plus difficile à atteindre que le LCP des visiteurs récurrents et nécessite un véritable travail d'infrastructure : CDN, optimisation des images et priorité de récupération (fetch priority) correcte.
• Écart acceptable entre le LCP des nouveaux visiteurs et celui des visiteurs récurrents : Jusqu'à 400 ms. Un écart plus important indique que votre site dépend du cache du navigateur pour réussir les Core Web Vitals, ce qui signifie que les premières impressions sont mauvaises.
• Non mesuré en dessous de 5 % : Si ce segment dépasse les 10 %, vérifiez si une implémentation de consentement aux cookies ou un changement d'autorisation de stockage bloque la détection du type de visite.

La dimension Visiteur récurrent est l'un des premiers filtres que j'applique lorsqu'un site affiche une réussite limite sur le LCP. Les données de terrain agrégées masquent la véritable histoire. La séparation par type de visite montre immédiatement si le travail d'optimisation est solide ou si le site se repose sur les succès du cache d'une audience fidèle et récurrente tout en échouant pour chaque nouvel utilisateur arrivant depuis la recherche.