Core/Dash Dimensjon: Navigation Origin

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

Gratis prøveperiode

Trusted by market leaders · Client results

fotocasanina careperionmarktplaatswhowhatwearloopearplugsworkivaerasmusmcvpnadevintaharvardsnvcomparenestleebaykpnmonarchdpg mediamy work featured on web.devaleteiahappyhorizonsaturn

Hva Navigation Origin måler

Navigation Origin-dimensjonen deler felddataene dine 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 URL-en direkte.

Denne forskjellen er viktig fordi nettleserens utgangsbetingelser er helt forskjellige i hvert tilfelle. En same-origin-navigasjon kan gjenbruke en eksisterende tilkobling, bruke HTTP-hurtigbufferen for underressurser, og dra nytte av eventuell forhåndshenting 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, har nettleseren arbeid å gjøre før den i det hele tatt kan be om HTML-en din:

  1. DNS-oppslag — oversett domenet ditt til en IP-adresse.
  2. TCP-håndtrykk — åpne en tilkobling til serveren din.
  3. TLS-forhandling — fullfør HTTPS-håndtrykket.

Til sammen legger disse trinnene typisk til 200 til 500 ms på en mobiltilkobling før den første byten av siden din er blitt forespurt. Denne kostnaden vises direkte i Time to First Byte (TTFB), og hvis LCP-elementet ditt avhenger av en ressurs som lastes etter at HTML-en ankommer, forplanter det seg til en dårligere Largest Contentful Paint (LCP) også.

Hurtigbufrede underressurser er heller ikke tilgjengelige. En besøkende som klikket seg inn fra Google har ingen hurtigbufret kopi av skriftene, hovedbildet eller den kritiske CSS-en din. En besøkende som nettopp kom fra hjemmesiden din har sannsynligvis alt dette.

Same-origin-navigasjoner og back-forward-hurtigbufferen

Same-origin-navigasjoner åpner døren for to ytelsesfordeler som cross-origin-navigasjoner ikke kan bruke 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 fullstendig rendret i en bakgrunnsfane, noe som gjør navigasjonen øyeblikkelig. Dette gjelder kun for same-origin-destinasjoner.

For det andre gjenoppretter back-forward-hurtigbufferen (bfcache) en side 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 same-origin LCP-en din er betydelig bedre enn cross-origin LCP-en, bidrar sannsynligvis bfcache og forhåndshenting til dette gapet.

Hvordan lese denne dimensjonen i CoreDash

coredash metric table urls

I CoreDash kan du bruke Navigation Origin som et filter eller som en nedbrytningsdimensjon sammen med enhver metrikk. Den mest nyttige sammenligningen er LCP etter navigation origin. Et stort gap mellom same-origin og cross-origin LCP forteller deg én av tre ting:

  • Cross-origin-inngangssidene dine har en treg TTFB som blåser opp LCP.
  • Same-origin-navigasjoner drar nytte av forhåndshenting eller bfcache, og cross-origin-sidene dine gjør det ikke.
  • Hurtigbufrede underressurser hjelper tilbakevendende 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 eliminere 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 mot en TTFB under 200 ms for HTML-dokumentet.
  • Forhåndslast LCP-bildet. En <link rel="preload"> i <head> starter bildehentingen så tidlig som mulig, og kutter tiden mellom HTML-levering og LCP-elementets maling.
  • Innlem kritisk CSS. Ingen renderblokkerende stilark-forespørsel betyr at nettleseren kan male raskere selv på en kald tilkobling.
  • Legg til preconnect-hint for tredjepartsopprinnelser. Hvis LCP-bildet ditt eller en renderblokkerende ressurs ligger på et annet domene, starter et rel="preconnect"-hint TCP- og TLS-arbeidet tidlig.

For same-origin-navigasjoner er Speculation Rules API den mest virkningsfulle forbedringen som er tilgjengelig i dag. Forhåndsrendering av den mest sannsynlige neste siden kutter LCP til nær null for disse overgangene.

Navigation Origin i kontekst

Navigation Origin fungerer godt sammen med Navigation Type-dimensjonen (som skiller mellom navigate, reload, back-forward og prerender) og Effective Connection Type-dimensjonen. En cross-origin-navigasjon på en treg tilkobling er det vanskeligste scenarioet nettstedet ditt møter. Å filtrere til disse to betingelsene sammen vil vise deg den virkelige verste ytelsen og hvor de største forbedringene er tilgjengelige.