CoreDash Dimension: Navigationstyp

Dimension: Navigationstyp (nt)

Varje sidvisning i din CrUX-data bär på en navigationstyp. Den talar om för dig hur webbläsaren laddade sidan, vilket avgör vilka webbläsarsystem som var involverade: nätverksstacken, back/forward cache, prerender-pipelinen eller en sessionsåterställning. CoreDash exponerar detta som dimensionen nt så att du kan filtrera och jämföra Core Web Vitals över varje navigationskontext separat.

Datan kommer från PerformanceNavigationTiming API, specifikt egenskapen type. Du läser av den med performance.getEntriesByType("navigation")[0].type. Chrome rapporterar detta värde tillsammans med varje web vitals-mätning som skickas till CrUX, och CoreDash lagrar och indexerar det så att du kan segmentera utan att behöva skriva någon anpassad instrumentering.

Varför navigationstyp spelar roll

Att aggregera LCP eller INP över alla navigationstyper ger en siffra som är tekniskt korrekt men praktiskt vilseledande. En träff i back/forward cache slutförs på några millisekunder. En "kall" navigering (cold navigate) väntar på DNS, TCP, TLS och TTFB. Om 20 % av dina sessioner är bfcache-träffar drar de ner din p75 LCP och gör det svårare att se verkliga problem vid nya navigeringar.

Motsatsen är också sann. Om bfcache är trasig på din webbplats kommer back/forward-sessioner att prestera lika dåligt som nya navigeringar. Utan att segmentera på navigationstyp kommer du aldrig att märka det, eftersom det aggregerade värdet förblir stabilt.

Prerender är det mest dramatiska fallet. En korrekt förrenderad sida bör visa en LCP nära noll, eftersom renderingen avslutades innan användaren ens klickade på länken. Om dina förrenderade sidor visar normala LCP-siffror är konfigurationen av Speculation Rules felaktig och förrenderingen antingen triggas inte eller kastas bort före användning.

Navigationstyperna

navigate

En standardnavigering: användaren skrev in en URL, klickade på en länk från en annan webbplats eller följde en redirect. Detta är en fullständig sidladdning utan några caching-genvägar. Webbläsaren går igenom hela anropspipelinen inklusive DNS-uppslagning, upprättande av anslutning och fullständig resursladdning. I CoreDash-data står navigate för ungefär 65 % av sessionerna. Det är din baseline. Varje annan navigationstyp bör bedömas utifrån hur den står sig i jämförelse med navigate.

reload

Användaren tryckte på F5, klickade på webbläsarens uppdateringsknapp eller så anropade din kod location.reload(). Webbläsaren skickar omvalideringsförfrågningar för cachade resurser, vilket innebär att TTFB ofta ser sämre ut än vid en navigate trots att användaren är kvar på samma sida. Om din reload TTFB är dramatiskt högre än navigate TTFB, triggar dina cache-headers omvalidering vid varje omladdning istället för att servera gammalt innehåll. Ungefär 10 % av sessionerna är omladdningar i typisk CoreDash-trafik.

back_forward

Användaren tryckte på webbläsarens bakåt- eller framåtknapp. Om back/forward cache (bfcache) fungerar är detta den snabbaste möjliga navigationstypen. Webbläsaren återställer sidan från minnet utan några nätverksanrop alls. LCP för en bfcache-träff är i princip tiden det tar att måla upp från minnet, vilket sker nästan omedelbart.

Om dina back_forward-mätvärden ser ut ungefär som navigate fungerar inte bfcache. De vanligaste orsakerna är unload-händelsehanterare, Cache-Control: no-store-responshuvuden och öppna IndexedDB-anslutningar som inte stängdes före navigeringen. CoreDash-data visar att back_forward står för cirka 20 % av sessionerna, vilket gör detta till en fix med stor hävstångseffekt.

prerender

Sidan laddades i bakgrunden med hjälp av Speculation Rules API innan användaren klickade på länken. När användaren väl klickar aktiveras det förrenderade dokumentet omedelbart. LCP för en korrekt aktiverad prerender är nära noll eftersom allt renderingsarbete avslutades före navigationshändelsen.

Om din prerender LCP ser normal ut har en av tre saker hänt: förrenderingen kastades bort före aktivering, din speculation rule riktades mot fel URL:er, eller så använder sidan headers eller JavaScript som förhindrar förrendering. Ungefär 3 % av CoreDash-sessionerna är prerender-aktiveringar, men den andelen stiger snabbt när Speculation Rules väl har implementerats.

restore

Fliken återställdes efter att webbläsaren stängts eller efter att fliken kraschat. Webbläsaren laddar om sidan från grunden, men sessionen betraktas som en återställning snarare än en ny navigering. Prestandan liknar en kall navigering. Detta står för ungefär 2 % av sessionerna och är sällan i fokus för optimeringsarbete, men det är värt att övervaka om du har användare med instabila webbläsarsessioner.

Arbetsflöde för felsökning

1. Jämför navigate LCP mot ditt övergripande LCP-mål. Detta är din sanning för prestanda vid ny laddning. Om navigate redan passerar ligger ditt problem någon annanstans.
2. Kontrollera back_forward mot navigate. Om de ligger nära varandra är bfcache trasig. Öppna Chrome DevTools, gå till fliken Application och kör bfcache-testet. DevTools-utdatan kommer att lista exakt vilka funktioner eller headers som blockerar bfcache-behörighet.
3. Kontrollera prerender LCP. Om den är över 200 ms levererar inte prerender-pipelinen som den ska. Verifiera att din Speculation Rules JSON är giltig, kontrollera att målsidorna inte returnerar någon blockerande logik och bekräfta att aktiveringar räknas i Chrome DevTools under Speculation Rules.

Ingenjörsmässig tumregel

• navigate: Bör uppfylla ditt LCP-tröskelvärde genom normal optimering: snabb TTFB, fetchpriority="high" på LCP-bilden, inga render-blocking resurser.
• back_forward: Bör vara 10 till 20 gånger snabbare än navigate. Om inte är bfcache trasig.
• prerender: Bör visa LCP under 200 ms. Om inte är dina Speculation Rules felkonfigurerade.
• reload: TTFB bör inte vara dramatiskt sämre än navigate. Om den är det, fixa dina cache-omvaliderings-headers.

Navigationstyp är dimensionen som skiljer på "hur presterar min sida?" och "hur presterar min sida under varje laddningsstrategi i webbläsaren?". Den distinktionen är skillnaden mellan gissningar och felsökning.