Core/Dash Dimension: Återkommande besökare

Dimension: Användarbeteende: Återkommande besökare (fv)

Dimensionen Återkommande besökare delar upp din prestandadata i två populationer: användare som har besökt din webbplats tidigare och användare som inte har det. Den tekniska skillnaden mellan dessa grupper är webbläsarens cache. En återkommande besökare laddar dina teckensnitt, skript och bilder från disken. En ny besökare hämtar varje byte från nätverket.

Detta spelar roll eftersom din aggregerade LCP-poäng är ett vägt genomsnitt av båda. Om 40% av dina sessioner är nya besökare, drar deras laddningstider med kall cache upp ditt p75-värde. Utan den här dimensionen kan du inte veta om en försämring i LCP är ett verkligt infrastrukturproblem eller en tillfällig topp i anskaffningen av nya användare.

Varför prestandaklyftan är större än du förväntar dig

Webbläsarens cache eliminerar hela kedjor av förfrågningar för återkommande besökare. På en typisk innehållswebbplats hoppar en återkommande besökare över DNS-uppslagning, TCP-handskakning, TLS-förhandling och serversvar för varje cachad resurs. Själva LCP-resursen serveras ofta från minnescachen på under 5 ms i stället för att ta 200 ms till 800 ms över nätverket. Det är inte en marginell förbättring: det är en strukturell skillnad i hur sidan laddas.

I CoreDash-data över övervakade webbplatser visar återkommande besökare vanligtvis LCP-poäng som är 35% till 60% lägre än nya besökare på samma sidor. Klyftan är störst på bildtunga sidor där hjältemotivet (hero image) är stort och ursprungsservern är geografiskt avlägsen från användaren. På sidor med rendering på serversidan och ett LCP-element med text minskar klyftan eftersom laddningsfördröjningen för text är nära noll för båda grupperna.

INP-skillnaderna mellan de två grupperna är mindre men ändå närvarande. Nya besökare triggar ofta mer JavaScript-parsning vid första laddningen eftersom modul-bundlar utvärderas för första gången. Återkommande besökare drar nytta av V8:s kodcache, som lagrar kompilerad bytekod och hoppar över kompilera-och-parsa-steget helt. På JavaScript-tunga sidor kan detta raka av 50 ms till 150 ms från bearbetningstiden.

Att läsa de tre värdena

0: Återkommande besökare

Webbläsaren rapporterade att detta inte är användarens första session på ditt ursprung. Cachade resurser är tillgängliga. På de flesta marknadsförings- och redaktionella webbplatser som spåras i CoreDash utgör återkommande besökare 55% till 70% av alla sessioner. Deras prestandadata är din baslinje för varm cache: det bästa scenariot för riktiga användare som känner till din webbplats. Om din LCP är dålig här är problemet inte cachen. Titta istället på renderingsblockerande resurser, serverns svarstid eller renderingsfördröjning.

1: Ny besökare

Ingen cache. Webbläsaren hämtar varje resurs från nätverket. Detta är ditt värsta scenario för kall cache, och det representerar det första intrycket för varje användare som hittar dig via organisk sökning, en betald annons eller en delning på sociala medier. Nya besökare representerar vanligtvis 30% till 45% av sessionerna. Deras LCP-poäng ligger 300 ms till 700 ms högre än återkommande besökare på bildbaserade sidor. Om din nya besökares LCP inte klarar gränsvärdet på 2,5s men din återkommande besökares LCP klarar sig, är ditt optimeringsmål tydligt: minska storleken och fördröjningen på själva LCP-resursen, eftersom du inte kan lita på cache för denna målgrupp.

2: Ej mätt

CoreDash kunde inte fastställa besökstyp för den här sessionen. Detta inträffar vanligtvis när webbläsaren blockerar åtkomsten till lagringen som krävs för att skilja nya från återkommande besökare, eller när en integritetsfokuserad webbläsarkonfiguration förhindrar kontrollen. På de flesta webbplatser är denna andel under 5% av sessionerna. Behandla det som ett brusgolv snarare än ett segment att optimera för.

Felsökningsarbetsflöde

1. Fastställ din baslinjefördelning: Öppna dimensionen Återkommande besökare i CoreDash och notera procentandelen nya jämfört med återkommande sessioner. Om nya besökare utgör över 50% av trafiken är prestandan med kall cache din dominerande user experience och måste vara det primära optimeringsmålet.
2. Jämför LCP efter besökstyp: Filtrera endast på nya besökare och registrera p75 LCP. Filtrera sedan på återkommande besökare och registrera samma mätvärde. En klyfta över 500 ms pekar på resursstorlek eller nätverkets hämtningstid som flaskhalsen. En klyfta under 200 ms tyder på renderingsrelaterade problem som påverkar båda grupperna lika mycket.
3. Rikta in dig på LCP-resursen direkt: För nya besökare med långsam LCP är åtgärden att minska resursens laddningstid. Komprimera LCP-bilden, servera den från en CDN-kantnod nära dina användare och applicera fetchpriority="high". Dessa vinster kvarstår oavsett cachestatus. Lita inte på cachning för att kompensera för en överdimensionerad eller långsamt serverad LCP-resurs.
4. Validera med dimensionen Navigeringstyp: Korsreferera mot dimensionen Navigeringstyp. Omladdningar och navigeringar framåt/bakåt lutar oftast mot återkommande besökare. Om din LCP för återkommande besökare ser oväntat långsam ut, kan en hög andel omladdningar (där cachade resurser omvalideras snarare än serveras direkt) vara orsaken.

Teknisk tumregel

• LCP-mål för nya besökare: Under 2,5s vid p75. Detta är svårare att uppnå än LCP för återkommande besökare och kräver faktiskt infrastrukturarbete: CDN, bildoptimering och korrekt fetch priority.
• Acceptabel klyfta mellan nya och återkommande besökares LCP: Upp till 400 ms. En större klyfta indikerar att din webbplats är beroende av webbläsarens cache för att klara Core Web Vitals, vilket innebär att första intrycket misslyckas.
• Ej mätt under 5%: Om den här andelen växer över 10%, undersök om en implementering av samtycke för cookies eller ändrade lagringsbehörigheter blockerar detektering av besökstyp.

Dimensionen Återkommande besökare är ett av de första filtren jag applicerar när en webbplats visar ett gränsfall för godkänt på LCP. Aggregerad fältdata döljer den sanna berättelsen. Genom att dela upp efter besökstyp ser du omedelbart om optimeringsarbetet är gediget eller om webbplatsen flyter med på cacheträffar från en lojal och återkommande publik, samtidigt som den misslyckas för varje ny användare som anländer via sökningar.