Dimension Core/Dash : Visiteur récurrent (Repeat Visitor)

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

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

C'est important car votre score LCP agrégé est une moyenne pondérée des deux. Si 40 % de vos sessions proviennent de nouveaux visiteurs, leurs temps de chargement sans cache tirent votre p75 vers le haut. Sans cette dimension, vous ne pouvez pas savoir 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 mise en cache. La ressource LCP elle-même est souvent servie à partir du cache en mémoire en moins de 5 ms au lieu de prendre de 200 ms à 800 ms via 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 sur les sites surveillés, les visiteurs récurrents affichent généralement des scores LCP inférieurs de 35 % à 60 % à ceux des nouveaux visiteurs sur les mêmes pages. L'écart est le plus grand sur les pages riches en images où l'image hero est volumineuse et où le serveur d'origine est 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 au 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 saute complètement l'étape d'analyse et de compilation. Sur les pages 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 (Repeat Visitor)

Le navigateur a signalé que ce n'est pas la première session de l'utilisateur sur votre origine. Des ressources mises en cache sont disponibles. Sur la plupart des sites marketing et éditoriaux suivis dans CoreDash, les visiteurs récurrents représentent de 55 % à 70 % de toutes les sessions. Leurs données de performance constituent votre base de référence avec cache (warm-cache) : le meilleur scénario pour les utilisateurs réels qui connaissent votre site. Si votre LCP est mauvais ici, le problème ne vient pas du 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 (New Visitor)

Pas de cache. Le navigateur récupère chaque ressource depuis le réseau. C'est votre pire scénario de démarrage à froid (cold-cache), et il représente la première impression pour chaque utilisateur qui vous trouve via une recherche organique, une annonce payante ou un partage social. Les nouveaux visiteurs représentent généralement de 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 dépasse le seuil de 2,5 s mais que le LCP de vos visiteurs récurrents est correct, 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é (Not Measured)

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 nécessaire 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 Visiteur récurrent dans CoreDash et notez le pourcentage de sessions nouvelles par rapport aux sessions récurrentes. Si les nouveaux visiteurs représentent plus de 50 % du trafic, les performances sans cache sont votre expérience utilisateur dominante et doivent être l'objectif principal d'optimisation.
2. Comparez le LCP par type de visite : Filtrez pour n'afficher que les nouveaux visiteurs et enregistrez le LCP p75. Ensuite, filtrez pour 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 à partir d'un nœud périphérique 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 Type de navigation : Croisez les données avec la dimension Type de navigation (Navigation Type). Les navigations de type rechargement (reload) et retour/avance (back-forward) sont biaisées vers les visiteurs récurrents. Si le LCP de vos visiteurs récurrents semble étonnamment lent, une proportion élevée de navigations de type rechargement (où les ressources mises en cache sont revalidées plutôt que servies directement) peut en être la raison.

Règle empirique pour les développeurs

• Objectif 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 cela nécessite un véritable travail d'infrastructure : CDN, optimisation des images et priorité de récupération 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é inférieur à 5 % : Si ce segment dépasse 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 un LCP à la limite de l'acceptable. Les données de terrain agrégées cachent la véritable histoire. La répartition par type de visite montre immédiatement si le travail d'optimisation est solide ou si le site se repose sur les succès de cache d'une audience fidèle et récurrente, tout en échouant pour chaque nouvel utilisateur arrivant d'une recherche.