Core/Dash Dimension: Repeat Visitor

Dimension: User Behavior: Repeat Visitor (fv)

Dimensionen Repeat Visitor opdeler dine ydeevnedata i to populationer: brugere, der har besøgt dit websted før, og brugere, der ikke har. Den tekniske forskel mellem disse grupper er browser 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 har betydning, fordi din aggregerede LCP-score er et vægtet gennemsnit af begge. Hvis 40 % af dine sessioner er nye besøgende, trækker deres cold-cache indlæsningstider din p75 op. Uden denne dimension kan du ikke se, om en LCP-regression er et reelt infrastrukturproblem eller en midlertidig stigning i tilgangen af nye brugere.

Hvorfor forskellen i ydeevne er større, end du forventer

Browser cachen eliminerer hele anmodningskæder for tilbagevendende besøgende. På et typisk indholdswebsted springer en tilbagevendende besøgende DNS-opslaget, TCP-handshake, TLS-forhandling og serversvar over 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-scores, der er 35 % til 60 % lavere end for nye besøgende på de samme sider. Kløften er størst på billedtunge sider, hvor hero-billedet er stort, og origin-serveren er geografisk langt fra brugeren. På sider med server-side rendering og et tekst-LCP-element indsnævres kløften, 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, når modul-bundles evalueres for første gang. Tilbagevendende besøgende drager fordel af V8's kode-cache, som gemmer kompileret bytecode og springer parse-and-compile-trinnet helt over. På JavaScript-tunge sider kan dette skære 50 ms til 150 ms af behandlingstiden.

Sådan læser du de tre værdier

0: Repeat Visitor

Browseren rapporterede, at dette ikke er brugerens første session på dit origin. 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 ydeevnedata er din warm-cache baseline: det bedst tænkelige scenarie for reelle brugere, der kender dit websted. Hvis din LCP er dårlig her, er problemet ikke cachen. Se på render-blocking ressourcer, serversvartid eller render delay i stedet.

1: New Visitor

Ingen cache. Browseren henter hver ressource fra netværket. Dette er dit worst-case scenario for cold-cache, 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-scores ligger 300 ms til 700 ms højere end for tilbagevendende besøgende på billedbaserede sider. Hvis din nye besøgendes LCP ikke overholder tærsklen på 2,5 s, men din tilbagevendende besøgendes LCP passerer, er dit optimeringsmål klart: Reducer størrelsen og forsinkelsen for selve LCP-ressourcen, da du ikke kan stole på cache for denne målgruppe.

2: Not Measured

CoreDash kunne ikke bestemme besøgstypen for denne session. Dette sker typisk, når browseren blokerer for 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 udgør denne gruppe under 5 % af sessionerne. Behandl det som baggrundsstøj i stedet for et segment, der skal optimeres for.

Debugging-workflow

1. Etabler din baseline-fordeling: Åbn dimensionen Repeat Visitor i CoreDash, og noter procentdelen af nye versus tilbagevendende sessioner. Hvis nye besøgende udgør over 50 % af trafikken, er cold-cache-ydeevne din dominerende user experience 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 metrik. Et spring på over 500 ms peger på aktivstørrelse eller netværkshentningstid som flaskehalsen. Et spring på under 200 ms tyder på render-side-problemer, der påvirker begge grupper ligeligt.
3. Gå direkte efter LCP-ressourcen: For nye besøgende med langsom LCP er løsningen at reducere ressourcens indlæsningstid. Komprimer LCP-billedet, server det fra en CDN-edge-node tæt på dine brugere, og anvend fetchpriority="high". Disse gevinster vedbliver uanset cache-tilstand. Stol ikke på caching for at kompensere for et overdimensioneret eller langsomt serveret LCP-aktiv.
4. Valider med Navigation Type-dimensionen: Krydsreferencer mod dimensionen Navigation Type. Genindlæsninger og frem/tilbage-navigationer skævvrider i retning af tilbagevendende besøgende. Hvis din LCP for tilbagevendende besøgende ser uventet langsom ud, kan en høj andel af genindlæsningsnavigationer (hvor cachede ressourcer revalideres i stedet for at blive serveret direkte) være årsagen.

Ingeniørens tommelfingerregel

• LCP-mål for nye besøgende: Under 2,5 s ved p75. Dette er sværere at opnå end LCP for tilbagevendende besøgende og kræver reelt infrastrukturarbejde: CDN, billedoptimering og korrekt fetch priority.
• Acceptabelt spring mellem LCP for nye og tilbagevendende besøgende: Op til 400 ms. Et større spring indikerer, at dit websted er afhængigt af browser cache for at bestå Core Web Vitals, hvilket betyder, at førstehåndsindtrykket fejler.
• Not Measured under 5 %: Hvis denne gruppe vokser til over 10 %, skal du undersøge, om en cookie consent-implementering eller ændring af lagertilladelse blokerer registreringen af besøgstype.

Dimensionen Repeat Visitor er et af de første filtre, jeg anvender, når et websted viser en LCP lige på grænsen til at bestå. Aggregerede feltdata skjuler den virkelige historie. En opdeling efter besøgstype viser med det samme, om optimeringsarbejdet er solidt, eller om webstedet flyder på cache-hits fra et loyalt tilbagevendende publikum, mens det fejler for hver ny bruger, der ankommer fra en søgning.