Core/Dash-dimensjon: Navigasjonstype

Dimensjon: Navigasjonstype (nt)

Hver sidevisning i dine CrUX-data bærer en navigasjonstype. Den forteller deg hvordan nettleseren lastet inn siden, noe som avgjør hvilke nettlesersystemer som var involvert: nettverksstakken, back/forward-cachen, prerender-pipelinen eller en gjenoppretting av økten. CoreDash eksponerer dette som nt-dimensjonen, slik at du kan filtrere og sammenligne Core Web Vitals på tvers av hver navigasjonskontekst separat.

Dataene kommer fra PerformanceNavigationTiming API, spesifikt type-egenskapen. Du leser den med performance.getEntriesByType("navigation")[0].type. Chrome rapporterer denne verdien sammen med hver Web Vitals-måling som sendes til CrUX, og CoreDash lagrer og indekserer den slik at du kan segmentere uten å skrive noe tilpasset instrumentering.

Hvorfor navigasjonstype er viktig

Aggregering av LCP eller INP på tvers av alle navigasjonstyper produserer et tall som er teknisk korrekt, men praktisk talt villedende. En treff i back/forward-cachen fullføres på millisekunder. En kald navigering venter på DNS, TCP, TLS og TTFB. Hvis 20 % av øktene dine er bfcache-treff, trekker de ned din p75 LCP og gjør et reelt problem på ferske navigeringer vanskeligere å oppdage.

Det motsatte er også sant. Hvis bfcache er ødelagt på nettstedet ditt, vil back/forward-økter yte like dårlig som ferske navigeringer. Uten å segmentere etter navigasjonstype vil du aldri legge merke til det, fordi aggregatet holder seg stabilt.

Prerender er det mest dramatiske tilfellet. En korrekt forhåndslastet (prerendered) side bør vise en LCP nær null, fordi gjengivelsen ble fullført før brukeren i det hele tatt klikket på lenken. Hvis dine forhåndslastede sider viser normale LCP-tall, er konfigurasjonen for Speculation Rules feil, og prerender blir enten ikke utløst, eller den blir forkastet før bruk.

Navigasjonstypene

navigate

En standard navigering: brukeren skrev inn en URL, klikket på en lenke fra et annet nettsted, eller fulgte en omdirigering. Dette er en fullstendig sideinnlasting uten snarveier via hurtigbuffer. Nettleseren går gjennom hele forespørselspipelinen inkludert DNS-oppslag, opprettelse av tilkobling og full innlasting av ressurser. I CoreDash-data utgjør navigate omtrent 65 % av øktene. Dette er din grunnlinje. Enhver annen navigasjonstype bør vurderes opp mot hvordan den sammenlignes med navigate.

reload

Brukeren trykket på F5, klikket på nettleserens oppdateringsknapp, eller koden din kalte location.reload(). Nettleseren sender revalideringsforespørsler for bufrede ressurser, noe som betyr at TTFB ofte ser verre ut enn ved en vanlig navigering på tross av at brukeren er på samme side. Hvis din reload TTFB er dramatisk høyere enn navigate TTFB, utløser cache-headerne dine revalidering ved hver oppdatering i stedet for å servere eldre innhold. Omtrent 10 % av øktene er reloads i typisk CoreDash-trafikk.

back_forward

Brukeren trykket på nettleserens tilbake- eller fremoverknapp. Hvis back/forward-cachen (bfcache) fungerer, er dette den raskeste mulige navigasjonstypen. Nettleseren gjenoppretter siden fra minnet helt uten nettverksforespørsler. LCP for et bfcache-treff er i praksis tiden det tar å tegne opp fra minnet, noe som skjer nærmest umiddelbart.

Hvis dine back_forward-metrikker ser tilsvarende ut som navigate, fungerer ikke bfcache. De vanligste årsakene er unload-hendelseshåndterere, Cache-Control: no-store-responsheadere, og åpne IndexedDB-tilkoblinger som ikke ble lukket før navigeringen. CoreDash-data plasserer back/forward på rundt 20 % av øktene, noe som gjør dette til en svært verdifull rettelse.

prerender

Siden ble lastet inn i bakgrunnen ved hjelp av Speculation Rules API før brukeren klikket på lenken. Når brukeren faktisk klikker, aktiveres det forhåndslastede (prerendered) dokumentet umiddelbart. LCP for en korrekt aktivert prerender er nær null, fordi alt gjengivelsesarbeid ble ferdigstilt før navigasjonshendelsen inntraff.

Hvis din prerender LCP ser normal ut, skjedde én av tre ting: prerenderen ble forkastet før aktivering, Speculation Rules rettet seg mot feil URL-er, eller siden bruker headere eller JavaScript som forhindrer prerendering. Omtrent 3 % av CoreDash-øktene er prerender-aktiveringer, men denne andelen stiger raskt når Speculation Rules først er implementert.

restore

Fanen ble gjenopprettet etter at nettleseren ble lukket eller fanen krasjet. Nettleseren laster siden inn på nytt fra bunnen av, men økten regnes som en gjenoppretting i stedet for en fersk navigering. Ytelsen er tilsvarende en kald navigering. Dette utgjør omtrent 2 % av øktene og er sjelden fokus for optimaliseringsarbeid, men det er verdt å overvåke hvis du har brukere på ustabile nettleserøkter.

Arbeidsflyt for feilsøking

1. Sammenlign navigate LCP med ditt overordnede LCP-mål. Dette er fasiten din for fersk innlastingsytelse. Hvis navigate allerede er godkjent, ligger problemet ditt et annet sted.
2. Sjekk back_forward opp mot navigate. Hvis de er tett på hverandre, er bfcache ødelagt. Åpne Chrome DevTools, gå til Application-panelet og kjør bfcache-testen. DevTools-utdataene vil liste opp nøyaktig hvilke funksjoner eller headere som blokkerer bfcache-kvalifisering.
3. Sjekk prerender LCP. Hvis den er over 200 ms, leverer ikke prerender-pipelinen. Bekreft at din Speculation Rules JSON er gyldig, sjekk at målsidene ikke returnerer blokkerende logikk, og bekreft at aktiveringer telles i Chrome DevTools under Speculation Rules.

Tekniske tommelfingerregler

• navigate: Bør oppfylle LCP-terskelen din gjennom normal optimalisering: rask TTFB, fetchpriority="high" på LCP-bildet, og ingen render-blokkerende ressurser.
• back_forward: Bør være 10 til 20 ganger raskere enn navigate. Hvis ikke, er bfcache ødelagt.
• prerender: Bør vise LCP under 200 ms. Hvis ikke, er dine Speculation Rules feilkonfigurert.
• reload: TTFB bør ikke være dramatisk verre enn navigate. Hvis den er det, må du fikse revalideringsheaderne for cachen din.

Navigasjonstype er dimensjonen som skiller mellom «hvordan yter siden min?» og «hvordan yter siden min under hver nettlesers innlastingsstrategi?». Den distinksjonen er forskjellen mellom å gjette og å feilsøke.