CoreDash Dimension: Gendannet besøgende

Dimension: User Behavior: Repeat Visitor (fv)

Dimensionen Repeat Visitor opdeler dine performancedata i to populationer: brugere, der har besøgt dit websted før, og brugere, der ikke har. Den ingeniørmæssige forskel mellem disse grupper er browserens cache. En tilbagevendende besøgende indlæser dine skrifttyper, scripts og billeder fra disken. En ny besøgende henter hver eneste byte fra netværket.

Dette er vigtigt, fordi din samlede LCP-score er et vægtet gennemsnit af begge. Hvis 40 % af dine sessioner er nye besøgende, vil deres cold-cache-indlæsningstider trække din p75 op. Uden denne dimension kan du ikke se, om en LCP-regression er et reelt infrastrukturproblem eller en midlertidig stigning i anskaffelsen af nye brugere.

Hvorfor performance-forskellen er større, end du forventer

Browserens cache eliminerer hele anmodningskæder for tilbagevendende besøgende. På et typisk indholdswebsted springer en tilbagevendende besøgende over DNS-opslag, TCP-håndtryk, TLS-forhandling og serversvar for hvert cachet aktiv. Selve LCP-ressourcen serveres ofte fra hukommelses-cachen på under 5 ms i stedet for at tage 200 ms til 800 ms over netværket. Det er ikke en marginal forbedring: det er en strukturel forskel i, hvordan siden indlæses.

I CoreDash-data på tværs af overvågede websteder viser tilbagevendende besøgende typisk LCP-scorer, der er 35 % til 60 % lavere end nye besøgende på de samme sider. Forskellen er størst på billedtunge sider, hvor hero-billedet er stort, og oprindelsesserveren er geografisk langt fra brugeren. På sider med server-side rendering og et tekst-LCP-element mindskes forskellen, fordi tekstindlæsningsforsinkelsen er tæt på nul for begge grupper.

INP-forskelle mellem de to grupper er mindre, men stadig til stede. Nye besøgende udløser ofte mere JavaScript-parsing ved første indlæsning, da modulpakker evalueres for første gang. Tilbagevendende besøgende drager fordel af V8's kodecache, som gemmer kompileret bytecode og springer parse-og-kompilerings-trinnet helt over. På JavaScript-tunge sider kan dette skære 50 ms til 150 ms af processing time.

Læsning af de tre værdier

0: Repeat Visitor

Browseren rapporterede, at dette ikke er brugerens første session på dit domæne. Cachede ressourcer er tilgængelige. På de fleste marketing- og redaktionelle websteder, der spores i CoreDash, udgør tilbagevendende besøgende 55 % til 70 % af alle sessioner. Deres performancedata er din warm-cache-baseline: det bedste scenarie for rigtige brugere, der kender dit websted. Hvis din LCP er dårlig her, er problemet ikke cachen. Se i stedet på render-blocking ressourcer, serversvartid eller render delay.

1: New Visitor

Ingen cache. Browseren henter hver ressource fra netværket. Dette er dit cold-cache-værste tilfælde, og det repræsenterer det første indtryk for enhver bruger, der finder dig via organisk søgning, en betalt annonce eller en social deling. Nye besøgende repræsenterer typisk 30 % til 45 % af sessionerne. Deres LCP-scorer kører 300 ms til 700 ms højere end tilbagevendende besøgende på billedbaserede sider. Hvis din nye besøgende-LCP fejler 2,5 s-tærsklen, men din tilbagevendende besøgende-LCP består, er dit optimeringsmål klart: Reducer størrelsen og forsinkelsen af selve LCP-ressourcen, fordi du ikke kan stole på cachen for denne målgruppe.

2: Not Measured

CoreDash kunne ikke bestemme besøgstypen for denne session. Dette sker typisk, når browseren blokerer den lageradgang, der kræves for at skelne nye fra tilbagevendende besøgende, eller når en privatlivsfokuseret browserkonfiguration forhindrer kontrollen. På de fleste websteder er denne kategori under 5 % af sessionerne. Behandl det som en støjbund frem for et segment, der skal optimeres til.

Debugging Workflow

1. Etabler din baseline-opdeling: Åbn dimensionen Repeat Visitor i CoreDash og bemærk procentdelen af nye versus tilbagevendende sessioner. Hvis nye besøgende udgør over 50 % af trafikken, er cold-cache-performance din dominerende brugeroplevelse og skal være det primære optimeringsmål.
2. Sammenlign LCP efter besøgstype: Filtrer kun til nye besøgende og noter p75 LCP. Filtrer derefter til tilbagevendende besøgende og noter den samme metriik. En forskel på over 500 ms peger på aktivstørrelse eller netværkshentningstid som flaskehalsen. En forskel på under 200 ms tyder på problemer på render-siden, der påvirker begge grupper ligeligt.
3. Målret LCP-ressourcen direkte: For nye besøgende med langsom LCP er løsningen at reducere ressourceindlæsningstiden. Komprimer LCP-billedet, server det fra en CDN-edge-node tæt på dine brugere, og anvend fetchpriority="high". Disse gevinster fortsætter uanset cache-tilstand. Stol ikke på caching for at kompensere for et for stort eller langsomt serveret LCP-aktiv.
4. Valider med dimensionen Navigation Type: Krydsreferencer mod dimensionen Navigation Type. Reload og back-forward-navigationer hælder mod tilbagevendende besøgende. Hvis din tilbagevendende besøgende-LCP ser uventet langsom ud, kan en høj andel af reload-navigationer (hvor cachede ressourcer revalideres i stedet for at blive serveret direkte) være årsagen.

Ingeniørmæssig tommelfingerregel

• LCP-mål for nye besøgende: Under 2,5 s ved p75. Dette er sværere at nå end tilbagevendende besøgende-LCP og kræver reelt infrastrukturarbejde: CDN, billedoptimering og korrekt fetch priority.
• Acceptabel forskel mellem ny og tilbagevendende besøgende-LCP: Op til 400 ms. En større forskel indikerer, at dit websted afhænger af browserens cache for at bestå Core Web Vitals, hvilket betyder, at de første indtryk fejler.
• Not Measured under 5 %: Hvis denne kategori vokser til over 10 %, skal du undersøge, om en cookie-samtykkeimplementering eller ændring af lagertilladelser blokerer detektion af besøgstype.

Dimensionen Repeat Visitor er et af de første filtre, jeg anvender, når et websted viser en grænsetilfælde-beståelse på LCP. Samlede feltdata skjuler den virkelige historie. Opdeling efter besøgstype viser med det samme, om optimeringsarbejdet er solidt, eller om webstedet rider på bølgen af cache-hits fra et loyalt tilbagevendende publikum, mens det fejler for hver eneste nye bruger, der ankommer fra en søgning.