Core/Dash Dimension: Navigation Type

Segmentér dine Core Web Vitals efter, hvordan brugere ankom til siden, for at debugge bfcache-, prerender- og reload-performance.

Prøv gratis

Trusted by market leaders · Client results

my work featured on web.devharvardaleteiasaturnmonarchsnvnestlefotocasamarktplaatsvpndpg mediaperionloopearplugsadevintanina careworkivaebayhappyhorizonerasmusmckpnwhowhatwearcompare

Dimension: Navigation Type (nt)

Hver sidevisning i dine CrUX-data har en navigationstype. Den fortæller dig, hvordan browseren indlæste siden, hvilket afgør, hvilke browsersystemer der var involveret: netværksstakken, back/forward cache, prerender-pipelinen eller en gendannelse af en session. 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 læ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 din egen brugerdefinerede instrumentering.

coredash metric table urls

Hvorfor Navigation Type betyder noget

At aggregere LCP eller INP på tværs af alle navigationstyper producerer et tal, der er teknisk korrekt, men i praksis misvisende. 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å nye navigationer sværere at se.

Det omvendte er også sandt. Hvis bfcache er i stykker på dit websted, vil back/forward-sessioner performe lige så dårligt som friske navigationer. 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 var færdig, før brugeren overhovedet klikkede på linket. Hvis dine prerenderede sider viser normale LCP-tal, er konfigurationen af Speculation Rules forkert, og prerenderen 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 websted eller fulgte en omdirigering. Dette er en fuld sideindlæsning uden nogen caching-genveje. Browseren gennemgår hele anmodningspipelinen, inklusive DNS-opslag, etablering af forbindelse og fuld indlæsning af ressourcer. I CoreDash-data tegner navigate sig for cirka 65 % af sessionerne. Det er din baseline. Enhver anden navigationstype bør bedømmes 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 befinder sig på den samme side. Hvis din reload TTFB er dramatisk højere end navigate TTFB, udløser dine cache-headere revalidering ved hver genindlæsning i stedet for at servere forældet indhold. Cirka 10 % af sessionerne er reloads i typisk CoreDash-trafik.

back_forward

Brugeren trykkede på browserens tilbage- eller frem-knap. Hvis back/forward cache (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 tiden til at male fra hukommelsen, hvilket er næsten øjeblikkeligt.

Hvis dine back_forward-metrikker ser ud som navigate, virker bfcache ikke. De mest almindelige årsager er unload-hændelseshåndteringer, Cache-Control: no-store-svarheadere 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 et rettelsesområde 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 så klikker, aktiveres det prerenderede dokument øjeblikkeligt. LCP for en korrekt aktiveret prerender er tæt på nul, fordi alt renderingsarbejde var færdigt før navigationshændelsen.

Hvis din prerender LCP ser normal ud, er der sket en af tre ting: prerenderen blev kasseret før aktivering, Speculation Rules-reglen målrettede de forkerte URL'er, eller siden bruger headere eller JavaScript, der forhindrer prerendering. Cirka 3 % af CoreDash-sessioner er prerender-aktiveringer, men denne andel stiger hurtigt, når Speculation Rules er implementeret.

restore

Fanen blev gendannet, efter at browseren blev lukket, eller fanen gik ned. Browseren genindlæser siden fra bunden, men sessionen betragtes som en gendannelse snarere end en frisk navigate. Performance ligner en kold navigate. Dette tegner sig for 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.

Debugging-workflow

  1. Sammenlign navigate LCP med dit overordnede LCP-mål. Dette er din grundsandhed for performance af friske indlæsninger. Hvis navigate allerede består, ligger dit problem et andet sted.
  2. Tjek back_forward mod navigate. Hvis de er tæt på hinanden, er bfcache i stykker. Åbn Chrome DevTools, gå til Application-panelet, og kør bfcache-testen. DevTools-outputtet vil vise præcis hvilke funktioner eller headere, der blokerer for berettigelse til bfcache.
  3. Tjek prerender LCP. Hvis den er over 200 ms, leverer prerender-pipelinen ikke. Bekræft, at din Speculation Rules JSON er gyldig, tjek, at målsiderne ikke returnerer nogen blokerende logik, og bekræft, at aktiveringer tælles i Chrome DevTools under Speculation Rules.

Tommelfingerregler for udviklere

  • navigate: Bør opfylde din LCP-tærskel gennem normal optimering: hurtig TTFB, fetchpriority="high" på LCP-billedet, ingen render-blokerende 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 under 200 ms. Hvis ikke, er dine Speculation Rules forkert konfigureret.
  • reload: TTFB bør ikke være dramatisk dårligere end navigate. Hvis den er det, skal du rette dine headere for cache-revalidering.

Navigation Type er dimensionen, der adskiller "hvordan performer min side?" fra "hvordan performer min side under hver enkelt browsers indlæsningsstrategi?" Den sondring er forskellen mellem at gætte og at debugge.