CoreDash Dimensie: Terugkerende Bezoeker

Dimensie: Gebruikersgedrag: Terugkerende Bezoeker (fv)

De Terugkerende Bezoeker dimensie splitst uw prestatiegegevens in twee populaties: gebruikers die uw site eerder hebben bezocht en gebruikers die dat niet hebben gedaan. Het technische verschil tussen deze groepen is de browser cache. Een terugkerende bezoeker laadt uw lettertypen, scripts en afbeeldingen van de schijf. Een nieuwe bezoeker haalt elke byte van het netwerk.

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

Waarom de prestatiekloof groter is dan u verwacht

De browser cache elimineert volledige verzoeks-ketens voor terugkerende bezoekers. Op een typische contentsite slaat een terugkerende bezoeker de DNS-lookup, TCP-handshake, TLS-negotiatie en serverrespons over voor elk gecacht asset. De LCP-resource zelf wordt vaak in minder dan 5ms uit de geheugencache geserveerd, in plaats van 200ms tot 800ms over het netwerk in beslag te nemen. Dat is geen marginale verbetering: het is een structureel verschil in hoe de pagina laadt.

In CoreDash-data over gemonitorde sites vertonen terugkerende bezoekers doorgaans LCP-scores die 35% tot 60% lager zijn dan die van nieuwe bezoekers op dezelfde pagina's. De kloof is het grootst op pagina's met veel afbeeldingen waar de hero image groot is en de origin-server geografisch ver verwijderd is van de gebruiker. Op pagina's met server-side rendering en een tekstueel LCP-element wordt de kloof kleiner omdat de laadvertraging van tekst voor beide groepen bijna nul is.

De 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 module-bundels voor de eerste keer worden geëvalueerd. Terugkerende bezoekers profiteren van de code-cache van V8, die gecompileerde bytecode opslaat en de parse-en-compileer stap volledig overslaat. Op JavaScript-intensieve pagina's kan dit 50ms tot 150ms van de verwerkingstijd afschaven.

De drie waarden interpreteren

0: Terugkerende Bezoeker

De browser rapporteerde dat dit niet de eerste sessie van de gebruiker op uw origin is. Gecachte bronnen 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 prestatiegegevens zijn uw baseline met een warme cache: het scenario in het gunstigste geval voor echte gebruikers die uw site kennen. Als uw LCP hier slecht is, ligt het probleem niet bij de cache. Kijk in plaats daarvan naar render-blocking resources, server-responstijd of rendervertraging.

1: Nieuwe Bezoeker

Geen cache. De browser haalt elke bron op van het netwerk. Dit is uw slechtste scenario met een koude cache, en het vertegenwoordigt de eerste indruk voor elke gebruiker die u vindt via organisch zoeken, een betaalde advertentie of een social share. Nieuwe bezoekers vertegenwoordigen doorgaans 30% tot 45% van de sessies. Hun LCP-scores liggen 300ms tot 700ms hoger dan die van terugkerende bezoekers op pagina's met afbeeldingen. Als de LCP van uw nieuwe bezoekers de drempel van 2,5s overschrijdt, maar de LCP van uw terugkerende bezoekers wel slaagt, is uw optimalisatiedoel duidelijk: verminder de grootte en vertraging van de LCP-resource zelf, omdat u voor dit publiek niet op de cache kunt rekenen.

2: Niet Gemeten

CoreDash kon het type bezoek voor deze sessie niet bepalen. Dit gebeurt meestal wanneer de browser de opslagtoegang blokkeert die nodig is om nieuwe van terugkerende bezoekers te onderscheiden, of wanneer een op privacy gerichte browserconfiguratie de controle verhindert. Op de meeste sites beslaat deze categorie minder dan 5% van de sessies. Behandel het als een ruisvloer in plaats van een segment om voor te optimaliseren.

Hulp bij het Debuggen

1. Stel uw baseline-verdeling vast: Open de Terugkerende Bezoeker 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 uw dominante user experience en moet dit het primaire optimalisatiedoel zijn.
2. Vergelijk LCP per type bezoek: Filter op alleen nieuwe bezoekers en noteer de p75 LCP. Filter vervolgens op terugkerende bezoekers en noteer dezelfde metriek. Een kloof van meer dan 500ms wijst op asset-grootte of netwerk-fetchtijd als bottleneck. Een kloof van minder dan 200ms suggereert problemen aan de render-zijde die beide groepen in gelijke mate treffen.
3. Richt u direct op de LCP-resource: Voor nieuwe bezoekers met een trage LCP is de oplossing het verminderen van de laadtijd van de resource. Comprimeer de LCP-afbeelding, serveer deze vanaf een CDN edge-node dicht bij uw gebruikers en pas fetchpriority="high" toe. Deze verbeteringen blijven bestaan ongeacht de cache-status. Vertrouw niet op caching om een te groot of traag geserveerd LCP-asset te compenseren.
4. Valideer met de Navigatietype dimensie: Kruisverwijzing met de Navigatietype dimensie. Reload- en back-forward-navigaties neigen naar terugkerende bezoekers. Als de LCP van uw terugkerende bezoekers onverwacht traag lijkt, kan een hoog aandeel reload-navigaties (waarbij gecachte bronnen opnieuw worden gevalideerd in plaats van direct geserveerd) de reden zijn.

Insinöörimäinen peukalosääntö

• LCP-doel voor nieuwe bezoekers: Onder 2,5s op p75. Dit is moeilijker te halen dan de LCP voor terugkerende bezoekers en vereist echt infrastructuurwerk: CDN, beeldoptimalisatie en de juiste fetch priority.
• Acceptabele kloof tussen LCP voor nieuwe en terugkerende bezoekers: Tot 400ms. Een grotere kloof geeft aan dat uw site afhankelijk is van de browser cache om te slagen voor Core Web Vitals, wat betekent dat de eerste indrukken falen.
• Niet Gemeten onder 5%: Als deze categorie boven de 10% groeit, onderzoek dan of een cookie-toestemmingsimplementatie of een wijziging in opslagrechten de detectie van het type bezoek blokkeert.

De Terugkerende Bezoeker dimensie is een van de eerste filters die ik toepas wanneer een site een twijfelachtige voldoende scoort op LCP. Geaggregeerde veldgegevens verbergen het echte verhaal. Het splitsen per type bezoek laat onmiddellijk zien of het optimalisatiewerk solide is, of dat de site meelift op cache-hits van een loyaal terugkerend publiek terwijl elke nieuwe gebruiker die via zoekopdrachten binnenkomt, in de steek wordt gelaten.