Core/Dash Dimension: Navigationstype
Segmentér dine Core Web Vitals efter, hvordan brugerne ankom til siden, for at fejlsøge ydeevnen for bfcache, prerender og reload.
Dimension: Navigationstype (nt)
Hver sidevisning i dine CrUX-data bærer en navigationstype. Den fortæller dig, hvordan browseren indlæste siden, hvilket afgør, hvilke browsersystemer der var involveret: netværksstakken, back/forward-cachen, prerender-pipelinen eller en sessionsgendannelse. CoreDash eksponerer dette som nt-dimensionen, så du kan filtrere og sammenligne Core Web Vitals på tværs af hver navigationskontekst separat.
Dataene kommer fra PerformanceNavigationTiming API'et, specifikt type-egenskaben. Du aflæser den med performance.getEntriesByType("navigation")[0].type. Chrome rapporterer denne værdi sammen med hver web vitals-måling, der sendes til CrUX, og CoreDash gemmer og indekserer den, så du kan segmentere uden at skrive nogen tilpasset instrumentering.

Hvorfor Navigationstype er vigtig
Aggregering af LCP eller INP på tværs af alle navigationstyper producerer et tal, der er teknisk korrekt, men i praksis vildledende. Et back/forward-cache hit fuldføres på millisekunder. En kold navigate venter på DNS, TCP, TLS og TTFB. Hvis 20 % af dine sessioner er bfcache-hits, trækker de din p75 LCP ned og gør et reelt problem på friske navigationer sværere at se.
Det omvendte gør sig også gældende. Hvis bfcache er i stykker på dit website, vil back/forward-sessioner yde lige så dårligt som friske navigates. Uden at segmentere efter navigationstype vil du aldrig opdage det, fordi aggregatet forbliver stabilt.
Prerender er det mest dramatiske tilfælde. En korrekt prerenderet side bør vise en LCP tæt på nul, fordi renderingen blev afsluttet, før brugeren overhovedet klikkede på linket. Hvis dine prerenderede sider viser normale LCP-tal, er konfigurationen af Speculation Rules forkert, og din prerender bliver enten ikke udløst eller kasseret før brug.
Navigationstyperne
navigate
En standardnavigation: brugeren indtastede en URL, klikkede på et link fra et andet website eller fulgte en omdirigering. Dette er en fuld sideindlæsning uden caching-genveje. Browseren gennemgår hele anmodningspipelinen inklusive DNS-opslag, oprettelse af forbindelse og fuld ressourceindlæsning. I CoreDash-data udgør navigate cirka 65 % af sessionerne. Det er din baseline. Enhver anden navigationstype bør vurderes ud fra, hvordan den klarer sig i forhold til navigate.
reload
Brugeren trykkede på F5, klikkede på browserens genindlæsningsknap, eller din kode kaldte location.reload(). Browseren sender revalideringsanmodninger for cachelagrede ressourcer, hvilket betyder, at TTFB ofte ser værre ud end en navigate, på trods af at brugeren er på den samme side. Hvis din reload TTFB er dramatisk højere end navigate TTFB, udløser dine cache-headers revalidering ved hver genindlæsning i stedet for at servere forældet (stale) indhold. Cirka 10 % af sessionerne er reloads i typisk CoreDash-trafik.
back_forward
Brugeren trykkede på browserens tilbage- eller frem-knap. Hvis back/forward-cachen (bfcache) fungerer, er dette den hurtigst mulige navigationstype. Browseren gendanner siden fra hukommelsen helt uden netværksanmodninger. LCP for et bfcache-hit er i praksis den tid, det tager at tegne (paint) fra hukommelsen, hvilket sker næsten øjeblikkeligt.
Hvis dine back_forward-metrikker ligner navigate, fungerer bfcache ikke. De mest almindelige årsager er unload-hændelseshåndteringer, Cache-Control: no-store svar-headers og åbne IndexedDB-forbindelser, der ikke blev lukket før navigationen. CoreDash-data placerer back/forward på omkring 20 % af sessionerne, hvilket gør dette til en fejlrettelse med høj effekt.
prerender
Siden blev indlæst i baggrunden ved hjælp af Speculation Rules API'et, før brugeren klikkede på linket. Når brugeren rent faktisk klikker, aktiveres det prerenderede dokument øjeblikkeligt. LCP for en korrekt aktiveret prerender er tæt på nul, fordi alt renderingsarbejde var afsluttet før navigationshændelsen.
Hvis din prerender LCP ser normal ud, er der sket én af tre ting: din prerender blev kasseret før aktivering, speculation rule målrettede de forkerte URL'er, eller siden bruger headers eller JavaScript, der forhindrer prerendering. Cirka 3 % af CoreDash-sessionerne er prerender-aktiveringer, men den andel stiger hurtigt, når Speculation Rules er udrullet.
restore
Fanen blev gendannet, efter at browseren blev lukket, eller fanen gik ned. Browseren genindlæser siden fra bunden, men sessionen betragtes som en restore frem for en frisk navigate. Ydeevnen svarer til en kold navigate. Dette udgør cirka 2 % af sessionerne og er sjældent i fokus for optimeringsarbejde, men det er værd at overvåge, hvis du har brugere på ustabile browsersessioner.
Workflow til fejlsøgning
- Sammenlign navigate LCP med dit overordnede LCP-mål. Dette er din baseline for ydeevnen ved friske indlæsninger. Hvis navigate allerede er godkendt, ligger dit problem et andet sted.
- Tjek back_forward i forhold til navigate. Hvis de er tæt på hinanden, er bfcache i stykker. Åbn Chrome DevTools, gå til Application-panelet, og kør bfcache-testen. Outputtet fra DevTools vil præcist opliste, hvilke funktioner eller headers der blokerer for, at bfcache kan anvendes.
- Tjek prerender LCP. Hvis den er over 200 ms, leverer prerender-pipelinen ikke de forventede resultater. Bekræft, at din Speculation Rules JSON er gyldig, tjek at målsiderne ikke returnerer nogen blokerende logik, og bekræft, at aktiveringer bliver talt i Chrome DevTools under Speculation Rules.
Tommelfingerregler for udviklere
- navigate: Bør opfylde din LCP-grænseværdi gennem normal optimering: hurtig TTFB, fetchpriority="high" på LCP-billedet, ingen render-blocking ressourcer.
- back_forward: Bør være 10 til 20 gange hurtigere end navigate. Hvis ikke, er bfcache i stykker.
- prerender: Bør vise en LCP på under 200 ms. Hvis ikke, er dine Speculation Rules fejlkonfigureret.
- reload: TTFB bør ikke være dramatisk værre end navigate. Hvis den er det, skal du rette dine headers til cache-revalidering.
Navigationstype er den dimension, der adskiller "hvordan yder min side?" fra "hvordan yder min side under hver enkelt browsers indlæsningsstrategi?". Den skelnen er forskellen på at gætte og at fejlsøge.