Core/Dash-dimensjon: Navigation Origin

Se om de besøkende kommer fra samme domene eller fra eksterne kilder, og hvordan denne fordelingen påvirker Core Web Vitals.

Gratis prøveperiode

Trusted by market leaders · Client results

saturnaleteiamy work featured on web.devebayadevintasnverasmusmcwhowhatwearharvardnina carenestlecomparemarktplaatsdpg mediavpnfotocasaworkivaperionkpnloopearplugsmonarchhappyhorizon

Hva Navigation Origin måler

Dimensjonen Navigation Origin deler field data inn i to grupper:

  • Same Origin (1) — den forrige siden var på samme domene.
  • Cross Origin (2) — brukeren kom fra et annet domene, en søkemotor, en sosial plattform, eller skrev inn nettadressen direkte.

Dette skillet er viktig fordi nettleserens startbetingelser er helt forskjellige i de to tilfellene. En same-origin-navigasjon kan gjenbruke en eksisterende tilkobling, hente underressurser fra HTTP-cachen og dra nytte av prefetching som nettstedet ditt har satt opp. En cross-origin-navigasjon starter fra bunnen av.

Hvorfor cross-origin-navigasjoner er tregere

Når en bruker klikker på en lenke fra et eksternt nettsted, må nettleseren gjøre en del arbeid før den i det hele tatt kan be om HTML-en din:

  1. DNS-oppslag — finne IP-adressen til domenet ditt.
  2. TCP-håndtrykk — opprette en tilkobling til serveren din.
  3. TLS-forhandling — fullføre HTTPS-håndtrykket.

Samlet legger disse stegene vanligvis til 200 til 500 ms på en mobilforbindelse før første byte av siden din blir forespurt. Den kostnaden vises direkte i Time to First Byte (TTFB), og hvis LCP-elementet ditt avhenger av en ressurs som lastes etter at HTML-en har kommet, forplanter det seg til en dårligere Largest Contentful Paint (LCP) også.

Mellomlagrede underressurser er heller ikke tilgjengelige. En besøkende som klikket seg inn fra Google har ingen mellomlagret kopi av fonter, heltebilde eller kritisk CSS. En besøkende som nettopp kom fra forsiden din har sannsynligvis alt dette.

Same-origin-navigasjoner og back-forward cache

Same-origin-navigasjoner åpner døren for to ytelsesfordeler som cross-origin-navigasjoner ikke kan utnytte like pålitelig.

For det første lar Speculation Rules API deg forhåndshente eller forhåndsrendere interne sider før brukeren klikker. Nettleseren kan ha neste side fullt ut rendret i en bakgrunnsfane, noe som gjør navigasjonen øyeblikkelig. Dette gjelder kun for same-origin-destinasjoner.

For det andre gjenoppretter back-forward cache (bfcache) siden fra minnet når brukeren trykker på tilbake-knappen. Bfcache-treff er ekstremt raske og scorer godt på alle Core Web Vitals. De vises i dataene dine som same-origin-navigasjoner. Hvis LCP-en din for same-origin er betydelig bedre enn LCP-en for cross-origin, er det sannsynlig at bfcache og prefetch bidrar til den forskjellen.

Slik leser du denne dimensjonen i CoreDash

I CoreDash bruker du Navigation Origin som et filter eller som en breakdown-dimensjon sammen med en hvilken som helst metrikk. Den mest nyttige sammenligningen er LCP etter navigation origin. En stor forskjell mellom LCP for same-origin og cross-origin forteller deg én av tre ting:

  • Cross-origin-inngangssidene dine har en treg TTFB som blåser opp LCP-en.
  • Same-origin-navigasjoner drar nytte av prefetch eller bfcache, mens cross-origin-sidene dine ikke gjør det.
  • Dine mellomlagrede underressurser hjelper returnerende besøkende, men ikke førstegangsbesøkende fra eksterne kilder.

Cross-origin-data er vanligvis det viktigste tallet for SEO. Googles Chrome UX Report (CrUX) inkluderer alle navigasjonstyper, men organisk søketrafikk er nesten utelukkende cross-origin. Hvis cross-origin-LCP-en din består mens same-origin-LCP-en feiler, er det uvanlig og verdt å undersøke. Det motsatte er langt mer vanlig.

Redusere cross-origin-straffen

Du kan ikke fjerne kaldstart-straffen helt, men du kan redusere den:

  • Bruk et CDN med rask TTFB. Tilkoblingsoverhead krymper når serveren din er geografisk nær brukeren og svarer raskt. Sikt på en TTFB under 200 ms for HTML-dokumentet.
  • Forhåndslast (preload) LCP-bildet. En <link rel="preload"> i <head> starter hentingen av bildet så tidlig som mulig, noe som kutter tiden mellom HTML-levering og at LCP-elementet tegnes.
  • Legg kritisk CSS inline. Ingen render-blocking stilarkforespørsel betyr at nettleseren kan tegne siden tidligere, selv på en kald tilkobling.
  • Legg til preconnect-hint for tredjepartsdomener. Hvis LCP-bildet ditt eller en render-blocking ressurs ligger på et annet domene, vil et rel="preconnect"-hint starte TCP- og TLS-arbeidet tidlig.

For same-origin-navigasjoner er Speculation Rules API det mest effektive tiltaket i dag. Å forhåndsrendere den mest sannsynlige neste siden kutter LCP-en til nær null for disse overgangene.

Navigation Origin i kontekst

Navigation Origin fungerer godt sammen med dimensjonen Navigation Type (som skiller mellom navigate, reload, back-forward og prerender) og dimensjonen Effective Connection Type. En cross-origin-navigasjon på en treg tilkobling er det tøffeste scenariet nettstedet ditt møter. Å filtrere på disse to betingelsene sammen vil vise deg din reelle worst-case-ytelse, og hvor du kan hente de største forbedringene.