Core/Dash Dimension: Navigeringstyp

Dimension: Navigeringstyp (nt)

Varje sidvisning i din CrUX-data bär på en navigeringstyp. Den talar om hur webbläsaren laddade sidan, vilket avgör vilka av webbläsarens system 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 för varje navigeringskontext separat.

Datan kommer från PerformanceNavigationTiming API, specifikt egenskapen type. Du läser 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 egen anpassad instrumentering.

Varför navigeringstyp spelar roll

Att aggregera LCP eller INP över alla navigeringstyper ger ett värde som är tekniskt korrekt men praktiskt vilseledande. En träff i back/forward-cachen (bfcache) slutförs på millisekunder. En kall navigering (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 ett verkligt problem vid nya navigeringar svårare att upptäcka.

Det omvända gäller också. Om bfcache är trasigt på din webbplats kommer fram/bak-sessioner att prestera lika dåligt som nya navigeringar. Utan att segmentera efter navigeringstyp 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 slutfördes innan användaren ens klickade på länken. Om dina förrenderade sidor visar normala LCP-värden är konfigurationen för Speculation Rules felaktig, och förrenderingen triggas antingen inte eller så kasseras den innan den används.

Navigeringstyperna

navigate

En standardnavigering: användaren skrev in en URL, klickade på en länk från en annan webbplats eller följde en omdirigering (redirect). Detta är en fullständig sidladdning utan några genvägar för cachning. Webbläsaren går igenom hela begäran-pipelinen, inklusive DNS-uppslagning, anslutningsetablering och fullständig resursinladdning. I CoreDash-data står navigate för ungefär 65 % av sessionerna. Detta är din baslinje. Varje annan navigeringstyp 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 omladdningsknapp eller så anropade din kod location.reload(). Webbläsaren skickar omvalideringsbegäranden för cachade resurser, vilket innebär att TTFB ofta ser sämre ut än för navigate trots att användaren befinner sig på samma sida. Om din TTFB för reload är dramatiskt högre än TTFB för navigate, triggar dina cache-headers omvalidering vid varje omladdning i stället för att servera föråldrat 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 navigeringstypen. Webbläsaren återställer sidan från minnet helt utan några nätverksanrop. LCP för en bfcache-träff är i praktiken tiden för att måla upp sidan från minnet, vilket sker nästan omedelbart.

Om dina mätvärden för back_forward ser ut ungefär som för navigate, så fungerar inte bfcache. De vanligaste orsakerna är unload-händelsehanterare, svarshuvudet Cache-Control: no-store och öppna IndexedDB-anslutningar som inte stängdes innan navigeringen. CoreDash-data visar att back/forward står för cirka 20 % av sessionerna, vilket gör detta till en åtgärd med hög 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 sedan klickar aktiveras det förrenderade dokumentet direkt. LCP för en korrekt aktiverad prerender är nära noll eftersom allt renderingsarbete slutfördes innan navigeringshändelsen ägde rum.

Om din LCP för prerender ser normal ut har något av följande tre saker inträffat: förrenderingen kasserades före aktivering, spekulationsregeln riktade in sig på 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 så snart Speculation Rules är implementerade.

restore

Fliken återställdes efter att webbläsaren stängdes eller fliken kraschade. Webbläsaren laddar om sidan från grunden, men sessionen betraktas som en återställning (restore) snarare än en ny navigering (navigate). 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.

Felsökningsarbetsflöde

1. Jämför LCP för navigate mot ditt övergripande LCP-mål. Detta är din grundläggande sanning för prestanda vid helt nya inläsningar. Om navigate redan är godkänt ligger problemet någon annanstans.
2. Kontrollera back_forward gentemot navigate. Om de ligger nära varandra är bfcache trasigt. Öppna Chrome DevTools, gå till panelen Application och kör bfcache-testet. DevTools-utdatan listar exakt vilka funktioner eller headers som blockerar behörighet för bfcache.
3. Kontrollera LCP för prerender. 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.

Tumregler för ingenjörer

• navigate: Bör nå ditt LCP-gränsvärde genom normal optimering: snabb TTFB, fetchpriority="high" på LCP-bilden, inga renderingsblockerande resurser.
• back_forward: Bör vara 10 till 20 gånger snabbare än navigate. Om inte, är bfcache trasigt.
• 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 för navigate. Om den är det, korrigera dina headers för cache-omvalidering.

Navigeringstyp är dimensionen som skiljer på "hur presterar min sida?" och "hur presterar min sida under varje enskild inläsningsstrategi i webbläsaren?". Den distinktionen är skillnaden mellan att gissa och att felsöka.