Core/Dash-dimensjon: Navigasjonstype

Segmenter dine Core Web Vitals basert på hvordan brukerne ankom siden for å feilsøke ytelsen til bfcache, prerender og reload.

Prøv gratis

Trusted by market leaders · Client results

monarchhappyhorizonerasmusmcmy work featured on web.devnina caremarktplaatscomparesaturnsnvperionvpndpg mediaebayaleteiaworkivawhowhatwearfotocasaadevintanestleharvardkpnloopearplugs

Dimensjon: Navigasjonstype (nt)

Hver sidevisning i dine CrUX-data bærer med seg en navigasjonstype. Den forteller deg hvordan nettleseren lastet inn siden, noe som avgjør hvilke nettlesersystemer som var involvert: nettverksstakken, back/forward cache (bfcache), 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, nærmere bestemt type-egenskapen. Du leser den av 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 egendefinert instrumentering.

coredash metric table urls

Hvorfor navigasjonstype er viktig

Å aggregere LCP eller INP på tvers av alle navigasjonstyper gir et tall som er teknisk korrekt, men i praksis villedende. Et treff i back/forward cache 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 prestere like dårlig som ferske navigeringer. Uten å segmentere på 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 rendringen 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 forhåndslastingen blir enten ikke utløst, eller så blir den 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 sidelasting uten noen snarveier via hurtigbufferen (cache). Nettleseren går gjennom hele forespørselspipelinen, inkludert DNS-oppslag, etablering av tilkobling og full ressurslasting. I CoreDash-data står navigate for omtrent 65 % av øktene. Det er din grunnlinje. Hver annen navigasjonstype bør vurderes opp mot hvordan den presterer sammenlignet 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 til tross for at brukeren er på samme side. Hvis din reload TTFB er dramatisk høyere enn din navigate TTFB, utløser cache-headerne dine revalidering ved hver oppdatering i stedet for å servere utdatert (stale) innhold. Omtrent 10 % av øktene er reloads i typisk CoreDash-trafikk.

back_forward

Brukeren trykket på nettleserens tilbake- eller fremoverknapp. Hvis back/forward cache (bfcache) fungerer, er dette den raskest 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 nesten momentant.

Hvis dine back_forward-metrikker ser omtrent 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 anslår back/forward til rundt 20 % av øktene, noe som gjør dette til en svært verdifull optimalisering.

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 rendringsarbeid ble fullført før navigasjonshendelsen.

Hvis din prerender LCP ser normal ut, har en av tre ting skjedd: forhåndslastingen ble forkastet før aktivering, spekulasjonsregelen rettet seg mot feil URL-er, eller siden bruker headere eller JavaScript som forhindrer forhåndslasting. Omtrent 3 % av CoreDash-øktene er prerender-aktiveringer, men den andelen stiger raskt når Speculation Rules blir rullet ut.

restore

Fanen ble gjenopprettet etter at nettleseren ble lukket eller fanen krasjet. Nettleseren laster siden på nytt fra bunnen av, men økten regnes som en gjenoppretting (restore) fremfor en fersk navigering. Ytelsen er lik en kald navigering. Dette står for 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 ferske innlastinger. Hvis navigate allerede presterer godt nok, ligger problemet et annet sted.
  2. Sjekk back_forward opp mot navigate. Hvis de er nesten like, er bfcache ødelagt. Åpne Chrome DevTools, gå til Application-panelet, og kjør bfcache-testen. Utdataene fra DevTools vil liste opp nøyaktig hvilke funksjoner eller headere som blokkerer bfcache-kvalifisering.
  3. Sjekk prerender LCP. Hvis den er over 200ms, leverer ikke prerender-pipelinen som den skal. Verifiser at din Speculation Rules JSON er gyldig, sjekk at målsidene ikke returnerer blokkerende logikk, og bekreft at aktiveringer blir talt opp 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, 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 en LCP på under 200ms. Hvis ikke, er dine Speculation Rules feilkonfigurert.
  • reload: TTFB bør ikke være dramatisk verre enn ved navigate. Hvis den er det, fiks cache-revalideringsheaderne dine.

Navigasjonstype er dimensjonen som skiller "hvordan presterer siden min?" fra "hvordan presterer siden min under hver enkelt innlastingsstrategi i nettleseren?" Den forskjellen utgjør skillet mellom gjetting og systematisk feilsøking.