Core/Dash-dimensjon: Tilbakevendende besøkende

Dimensjon: Brukeratferd: Tilbakevendende besøkende (fv)

Dimensjonen Tilbakevendende besøkende deler ytelsesdataene dine inn i to populasjoner: brukere som har besøkt nettstedet ditt før, og brukere som ikke har det. Den tekniske forskjellen mellom disse gruppene er nettleserens cache. En tilbakevendende besøkende laster inn skrifttyper, skript og bilder fra disk. En ny besøkende henter hver eneste byte fra nettverket.

Dette er viktig fordi din aggregerte LCP-score er et vektet gjennomsnitt av begge. Hvis 40 % av øktene dine er nye besøkende, vil deres lastetider med kald cache trekke p75-verdien din opp. Uten denne dimensjonen kan du ikke vite om en LCP-regresjon er et reelt infrastrukturproblem eller en midlertidig økning i tilveksten av nye brukere.

Hvorfor ytelsesgapet er større enn du forventer

Nettleserens cache eliminerer hele forespørselskjeder for tilbakevendende besøkende. På et typisk innholdsnettsted hopper en tilbakevendende besøkende over DNS-oppslag, TCP-handshake, TLS-forhandling og serverrespons for hver cachet ressurs. Selve LCP-ressursen serveres ofte fra minne-cachen på under 5 ms i stedet for å ta 200 ms til 800 ms over nettverket. Det er ikke en marginal forbedring: det er en strukturell forskjell i hvordan siden lastes inn.

I CoreDash-data på tvers av overvåkede nettsteder viser tilbakevendende besøkende typisk LCP-scorer som er 35 % til 60 % lavere enn nye besøkende på de samme sidene. Gapet er størst på bildatunge sider der hovedbildet er stort og opprinnelsesserveren er geografisk langt unna brukeren. På sider med server-side rendering og et LCP-tekstelement, innsnevres gapet fordi forsinkelsen for innlasting av tekst er nær null for begge grupper.

INP-forskjellene mellom de to gruppene er mindre, men fortsatt til stede. Nye besøkende utløser ofte mer JavaScript-parsing ved første innlasting ettersom modulbunter evalueres for første gang. Tilbakevendende besøkende drar nytte av V8 sin kode-cache, som lagrer kompilert bytekode og hopper over hele parse-og-kompiler-trinnet. På sider med mye JavaScript kan dette kutte 50 ms til 150 ms av prosesseringstiden.

Hvordan lese de tre verdiene

0: Tilbakevendende besøkende

Nettleseren rapporterte at dette ikke er brukerens første økt på din opprinnelse. Cachede ressurser er tilgjengelige. På de fleste markedsførings- og redaksjonelle nettsteder som spores i CoreDash, utgjør tilbakevendende besøkende 55 % til 70 % av alle økter. Ytelsesdataene deres er din warm-cache grunnlinje: det beste scenarioet for virkelige brukere som kjenner nettstedet ditt. Hvis din LCP er dårlig her, er ikke problemet cachen. Se heller på render-blokkerende ressurser, serverens responstid eller render delay.

1: Ny besøkende

Ingen cache. Nettleseren henter hver eneste ressurs fra nettverket. Dette er ditt cold-cache verste scenario, og det representerer førsteinntrykket for hver bruker som finner deg via organisk søk, en betalt annonse eller en deling i sosiale medier. Nye besøkende representerer typisk 30 % til 45 % av øktene. Deres LCP-scorer ligger 300 ms til 700 ms høyere enn tilbakevendende besøkende på bildebaserte sider. Hvis LCP for nye besøkende feiler grensen på 2,5 s, men LCP for tilbakevendende besøkende består, er optimaliseringsmålet ditt klart: reduser størrelsen og forsinkelsen på selve LCP-ressursen, fordi du ikke kan stole på cache for dette publikummet.

2: Ikke målt

CoreDash kunne ikke fastslå besøkstypen for denne økten. Dette skjer typisk når nettleseren blokkerer lagringstilgangen som kreves for å skille nye fra tilbakevendende besøkende, eller når en personvernsfokusert nettleserkonfigurasjon forhindrer sjekken. På de fleste nettsteder utgjør denne gruppen under 5 % av øktene. Behandle den som et støygulv i stedet for et segment du skal optimalisere for.

Arbeidsflyt for feilsøking

1. Etabler din grunnlinjefordeling: Åpne dimensjonen for tilbakevendende besøkende i CoreDash og noter prosentandelen av nye versus tilbakevendende økter. Hvis nye besøkende utgjør mer enn 50 % av trafikken, er ytelse med kald cache din dominerende user experience og må være det primære optimaliseringsmålet.
2. Sammenlign LCP etter besøkstype: Filtrer kun for nye besøkende og noter p75 LCP. Filtrer deretter for tilbakevendende besøkende og noter den samme metrikken. Et gap på over 500 ms peker mot ressursstørrelse eller nettverkets hentetid som flaskehalsen. Et gap på under 200 ms antyder problemer på render-siden som påvirker begge gruppene likt.
3. Målrett LCP-ressursen direkte: For nye besøkende med treg LCP, er løsningen å redusere ressursens lastetid. Komprimer LCP-bildet, server det fra en CDN edge-node nær brukerne dine, og bruk fetchpriority="high". Disse gevinstene vedvarer uavhengig av cache-status. Ikke stol på at caching skal kompensere for en overdimensjonert eller tregt servert LCP-ressurs.
4. Valider med dimensjonen Navigation Type: Kryssreferer mot dimensjonen Navigation Type. Reload og back-forward navigasjoner skjevfordeles mot tilbakevendende besøkende. Hvis LCP for tilbakevendende besøkende ser uventet treg ut, kan en høy andel reload-navigasjoner (hvor cachede ressurser revalideres i stedet for å serveres direkte) være årsaken.

Tekniske tommelfingerregler

• LCP-mål for nye besøkende: Under 2,5 s ved p75. Dette er vanskeligere å treffe enn LCP for tilbakevendende besøkende og krever faktisk infrastrukturarbeid: CDN, bildeoptimalisering og riktig fetch priority.
• Akseptabelt gap mellom LCP for nye og tilbakevendende besøkende: Opptil 400 ms. Et større gap indikerer at nettstedet ditt er avhengig av nettleserens cache for å bestå Core Web Vitals, noe som betyr at førsteinntrykket feiler.
• Ikke målt under 5 %: Hvis denne gruppen vokser til over 10 %, bør du undersøke om en implementering av cookie-samtykke eller en endring i lagringstillatelser blokkerer gjenkjenningen av besøkstype.

Dimensjonen for tilbakevendende besøkende er et av de første filtrene jeg bruker når et nettsted viser en hårfin bestått på LCP. Aggregerte feltdata skjuler den virkelige historien. Å dele opp etter besøkstype viser umiddelbart om optimaliseringsarbeidet er solid, eller om nettstedet lener seg på cache-treff fra et lojalt, tilbakevendende publikum mens det feiler for hver nye bruker som ankommer fra søk.