Core/Dash-dimensie: Repeat Visitor

Dimensie: User Behavior: Repeat Visitor (fv)

De Repeat Visitor-dimensie splitst je prestatiedata op in twee populaties: gebruikers die je site al eens hebben bezocht en gebruikers die dat niet hebben gedaan. Het technische verschil tussen deze groepen is de browsercache. Een terugkerende bezoeker laadt je fonts, scripts en afbeeldingen vanaf schijf. Een nieuwe bezoeker haalt elke byte op via het netwerk.

Dit is belangrijk omdat je geaggregeerde LCP-score een gewogen gemiddelde van beide is. Als 40% van je sessies nieuwe bezoekers zijn, trekken hun laadtijden met een koude cache je p75 omhoog. Zonder deze dimensie kun je niet zien of een LCP-regressie een echt infrastructuurprobleem is of een tijdelijke piek in de acquisitie van nieuwe gebruikers.

Waarom het prestatieverschil groter is dan je verwacht

De browsercache elimineert volledige verzoekketens voor terugkerende bezoekers. Op een typische contentsite slaat een terugkerende bezoeker de DNS-lookup, TCP-handshake, TLS-negotiation en serverrespons over voor elk gecacht bestand. De LCP-resource zelf wordt vaak in minder dan 5 ms vanuit de memory cache geserveerd, in plaats van dat het 200 ms tot 800 ms via het netwerk kost. Dat is geen marginale verbetering: het is een structureel verschil in hoe de pagina laadt.

In data van CoreDash over gemonitoorde sites tonen terugkerende bezoekers doorgaans LCP-scores die 35% tot 60% lager liggen dan die van nieuwe bezoekers op dezelfde pagina's. Het gat is het grootst op pagina's met veel afbeeldingen, waar de hero-afbeelding groot is en de origin-server geografisch ver van de gebruiker verwijderd is. Op pagina's met server-side rendering en een LCP-textelement wordt het gat kleiner, omdat de laadvertraging van tekst voor beide groepen bijna nul is.

INP-verschillen tussen de twee groepen zijn kleiner, maar nog steeds aanwezig. Nieuwe bezoekers triggeren vaak meer JavaScript-parsing bij de eerste keer laden, omdat modulebundels dan voor het eerst worden geëvalueerd. Terugkerende bezoekers profiteren van de code cache van V8, die gecompileerde bytecode opslaat en de parse-and-compile-stap volledig overslaat. Op pagina's met veel JavaScript kan dit 50 ms tot 150 ms van de verwerkingstijd afschaven.

De drie waarden interpreteren

0: Repeat Visitor

De browser rapporteert dat dit niet de eerste sessie van de gebruiker op je origin is. Gecachte resources zijn beschikbaar. Op de meeste marketing- en redactionele sites die in CoreDash worden gevolgd, maken terugkerende bezoekers 55% tot 70% van alle sessies uit. Hun prestatiedata is je warm-cache baseline: het best-case scenario voor echte gebruikers die je site kennen. Als je LCP hier slecht is, ligt het probleem niet aan de cache. Kijk in plaats daarvan naar render-blocking resources, serverresponstijd of rendervertraging.

1: New Visitor

Geen cache. De browser haalt elke resource op van het netwerk. Dit is je cold-cache worst-case scenario en vertegenwoordigt de eerste indruk van elke gebruiker die je vindt via organische zoekresultaten, een betaalde advertentie of social sharing. Nieuwe bezoekers vertegenwoordigen doorgaans 30% tot 45% van de sessies. Hun LCP-scores liggen op pagina's met veel afbeeldingen 300 ms tot 700 ms hoger dan die van terugkerende bezoekers. Als de LCP voor nieuwe bezoekers de drempelwaarde van 2,5 seconden niet haalt, maar die voor terugkerende bezoekers wel, is je optimalisatiedoel helder: verminder de grootte en vertraging van de LCP-resource zelf, want voor deze doelgroep kun je niet vertrouwen op caching.

2: Not Measured

CoreDash kon het bezoektype voor deze sessie niet bepalen. Dit gebeurt meestal wanneer de browser de toegang tot opslag blokkeert die nodig is om nieuwe van terugkerende bezoekers te onderscheiden, of wanneer een privacygerichte browserconfiguratie de controle verhindert. Op de meeste sites maakt deze bucket minder dan 5% van de sessies uit. Beschouw dit eerder als een ruisvloer dan als een segment om voor te optimaliseren.

Debugging-workflow

1. Bepaal je baselinesplitsing: Open de Repeat Visitor-dimensie in CoreDash en noteer het percentage nieuwe versus terugkerende sessies. Als nieuwe bezoekers meer dan 50% van het verkeer uitmaken, is de prestatie met een koude cache je dominante gebruikerservaring en moet dit het primaire optimalisatiedoel zijn.
2. Vergelijk LCP per bezoektype: Filter op alleen nieuwe bezoekers en noteer de p75 LCP. Filter vervolgens op terugkerende bezoekers en noteer dezelfde metriek. Een gat van meer dan 500 ms wijst op de grootte van de assets of de ophaaltijd van het netwerk als bottleneck. Een gat van minder dan 200 ms duidt op problemen aan de renderkant die beide groepen evenzeer treffen.
3. Richt je direct op de LCP-resource: Voor nieuwe bezoekers met een trage LCP is de oplossing het verkorten van de laadtijd van de resource. Comprimeer de LCP-afbeelding, serveer deze vanaf een CDN-edge-node dicht bij je gebruikers en pas fetchpriority="high" toe. Deze winst blijft behouden, ongeacht de cachestatus. Vertrouw niet op caching om een te grote of traag geserveerde LCP-asset te compenseren.
4. Valideer met de Navigation Type-dimensie: Kruisverwijs met de Navigation Type-dimensie. Reload- en back-forward-navigaties komen vaker voor bij terugkerende bezoekers. Als de LCP voor terugkerende bezoekers onverwacht traag lijkt, kan een hoog aandeel reload-navigaties (waarbij gecachte resources worden gerevalideerd in plaats van direct geserveerd) de reden zijn.

Technische vuistregels

• LCP-doel voor nieuwe bezoekers: Onder de 2,5 seconden op p75. Dit is moeilijker te behalen dan de LCP voor terugkerende bezoekers en vereist echt infrastructuurwerk: CDN, afbeeldingsoptimalisatie en de juiste fetch-prioriteit.
• Acceptabel gat tussen LCP van nieuwe en terugkerende bezoekers: Maximaal 400 ms. Een groter gat geeft aan dat je site afhankelijk is van de browsercache om de Core Web Vitals te halen, wat betekent dat eerste indrukken mislukken.
• Not Measured onder de 5%: Als deze bucket boven de 10% stijgt, onderzoek dan of een cookie-consent-implementatie of een wijziging in opslagrechten de detectie van het bezoektype blokkeert.

De Repeat Visitor-dimensie is een van de eerste filters die ik toepas wanneer een site de LCP-drempel maar net haalt. Geaggregeerde field data verbergt het echte verhaal. Splitsen per bezoektype laat direct zien of het optimalisatiewerk solide is, of dat de site leunt op cache-hits van een loyaal, terugkerend publiek terwijl elke nieuwe gebruiker die via de zoekmachine binnenkomt, faalt.