Varför prestandagapet är större än du förväntar dig
Webbläsarens cache eliminerar hela kedjor av anrop för återkommande besökare. På en typisk innehållssajt hoppar en återkommande besökare över DNS-uppslagning, TCP-handskakning, TLS-förhandling och svar från servern för varje cachad resurs. Själva LCP-resursen serveras ofta från minnescachen på under 5 ms istä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. Gapet är störst på bildtunga sidor där hjältebilden (hero image) är stor och ursprungsservern ligger geografiskt långt från användaren. På sidor med rendering på serversidan (SSR) och ett textbaserat LCP-element minskar gapet eftersom fördröjningen för textladdning är nära noll för båda grupperna.
Skillnader i INP mellan de zwei grupperna är mindre men fortfarande närvarande. Nya besökare utlöser ofta mer JavaScript-parsning vid första laddningen när modulpaket utvärderas för första gången. Återkommande besökare drar nytta av V8:s kodcache, som lagrar kompilerad bytekod och hoppar över parsning-och-kompileringssteget helt. På JavaScript-tunga sidor kan detta kapa 50 ms till 150 ms från bearbetningstiden.
Att läsa de tre värdena 0: Repeat Visitor
Webbläsaren rapporterade att detta inte är användarens första session på ditt ursprung (origin). 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 verkliga 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 (Render Delay).
1: New Visitor
Ingen cache. Webbläsaren hämtar varje resurs från nätverket. Detta är ditt värsta scenario med tom cache, och det representerar det första intrycket för varje användare som hittar dig genom organisk sökning, en betald annons eller en delning i 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 LCP för nya besökare inte klarar tröskelvärdet på 2,5 s men din LCP för återkommande besökare gör det, är ditt optimeringsmål tydligt: minska storleken på och fördröjningen för själva LCP-resursen, eftersom du inte kan lita på cachen för denna målgrupp.
2: Not Measured
CoreDash kunde inte fastställa besökstyp för denna session. Detta sker vanligtvis när webbläsaren blockerar den lagringsåtkomst 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 kategori under 5 % av sessionerna. Behandla det som bakgrundsbrus snarare än ett segment att optimera för.
Felsökningsarbetsflöde - Fastställ din baslinjefördelning: Öppna dimensionen Repeat Visitor i CoreDash och notera procentsatsen för nya respektive återkommande sessioner. Om nya besökare utgör mer än 50 % av trafiken är prestanda med tom cache din dominerande användarupplevelse och måste vara det primära optimeringsmålet.
- Jämför LCP per besökstyp: Filtrera på enbart nya besökare och notera p75 LCP. Filtrera sedan på återkommande besökare och notera samma mätvärde. Ett gap över 500 ms pekar på resursstorlek eller nätverkshämtningstid som flaskhalsen. Ett gap under 200 ms tyder på problem på renderingssidan som påverkar båda grupperna lika mycket.
- Rikta in dig på LCP-resursen direkt: För nya besökare med långsam LCP är lösningen att minska resursens laddningstid. Komprimera LCP-bilden, servera den från en CDN-edge-nod nära dina användare och använd
fetchpriority="high". Dessa vinster kvarstår oavsett cachestatus. Lita inte på cachelagring för att kompensera för en överdimensionerad eller långsamt serverad LCP-resurs.
- Validera med dimensionen Navigation Type: Korsreferera mot dimensionen [url=\/metrics-dimensions\/navigation-type]Navigation Type[\/url]. Omladdningar (reload) och bakåt-framåt-navigeringar lutar 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 istället för att serveras direkt) vara orsaken.
Tumregel för ingenjörer
- LCP-mål för nya besökare: Under 2,5 s vid p75. Detta är svårare att nå än LCP för återkommande besökare och kräver faktiskt infrastrukturarbete: CDN, bildoptimering och korrekt fetch-prioritet.
- Acceptabelt gap mellan LCP för nya och återkommande besökare: Upp till 400 ms. Ett större gap 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.
- Not Measured under 5 %: Om denna kategori växer över 10 %, undersök om en implementering av samtycke för kakor (cookie consent) eller en ändring av lagringsbehörigheter blockerar detektering av besökstyp.
Dimensionen Repeat Visitor är ett av de första filtren jag använder när en webbplats visar ett resultat precis på gränsen för godkänt på LCP. Aggregerad fältdata döljer den verkliga historien. Att dela upp efter besökstyp visar omedelbart om optimeringsarbetet är solitt eller om webbplatsen glider fram på cache-träffar från en lojal återkommande publik medan den sviker varje ny användare som anländer från sökresultaten.
[include]sidebarcoredash.html[\/include]