Core/Dash Dimension: Navigation Origin

Se, om dine besøgende ankommer fra det samme domæne eller fra eksterne kilder, og hvordan den opdeling former dine Core Web Vitals.

Gratis prøveperiode

Trusted by market leaders · Client results

ebayharvardaleteiaerasmusmcadevintakpnnina carewhowhatwearsnvcomparefotocasadpg medianestleloopearplugsmarktplaatsmonarchworkivasaturnvpnperionmy work featured on web.devhappyhorizon

Hvad Navigation Origin måler

Navigation Origin-dimensionen opdeler dine field data i to grupper:

  • Same Origin (1) — den forrige side var på det samme domæne.
  • Cross Origin (2) — brugeren ankom fra et andet domæne, en søgemaskine, en social platform eller indtastede URL'en direkte.

Denne skelnen betyder noget, fordi browserens startbetingelser er helt forskellige i hvert tilfælde. En same-origin navigation kan genbruge en eksisterende forbindelse, trække på HTTP-cachen for underressourcer og drage fordel af enhver prefetching, dit websted har opsat. En cross-origin navigation starter forfra.

Hvorfor cross-origin navigationer er langsommere

Når en bruger klikker på et link fra et eksternt websted, har browseren arbejde at gøre, før den overhovedet kan anmode om din HTML:

  1. DNS-opslag — oversæt dit domæne til en IP-adresse.
  2. TCP-handshake — åbn en forbindelse til din server.
  3. TLS-forhandling — fuldfør HTTPS-handshaket.

Tilsammen tilføjer disse trin typisk 200 til 500 ms på en mobilforbindelse, før den første byte af din side er blevet anmodet om. Den omkostning viser sig direkte i Time to First Byte (TTFB), og hvis dit LCP-element afhænger af en ressource, der indlæses, efter HTML'en ankommer, kaskaderer det også over i en dårligere Largest Contentful Paint (LCP).

Cachelagrede underressourcer er også utilgængelige. En besøgende, der klikkede sig igennem fra Google, har ingen cachelagret kopi af dine skrifttyper, hero-billede eller kritisk CSS. En besøgende, der lige kom fra din forside, har sandsynligvis alle disse.

Same-origin navigationer og back-forward cachen

Same-origin navigationer åbner døren til to ydeevnefordele, som cross-origin navigationer ikke kan bruge lige så pålideligt.

For det første lader Speculation Rules API dig prefetch eller prerender interne sider, før brugeren klikker. Browseren kan have den næste side fuldt renderet i en baggrundsfane, hvilket gør navigationen øjeblikkelig. Dette gælder kun for same-origin destinationer.

For det andet gendanner back-forward cache (bfcache) en side fra hukommelsen, når brugeren trykker på tilbage-knappen. Bfcache-hits er ekstremt hurtige og scorer godt på tværs af alle Core Web Vitals. De vises i dine data som same-origin navigationer. Hvis din same-origin LCP er væsentligt bedre end din cross-origin LCP, bidrager bfcache og prefetch sandsynligvis til den kløft.

Hvordan man læser denne dimension i CoreDash

coredash metric table urls

I CoreDash kan du bruge Navigation Origin som et filter eller som en nedbrydningsdimension sammen med enhver metrik. Den mest nyttige sammenligning er LCP efter navigationsoprindelse. En stor kløft mellem same-origin og cross-origin LCP fortæller dig en af tre ting:

  • Dine cross-origin indgangssider har en langsom TTFB, der puster LCP op.
  • Same-origin navigationer drager fordel af prefetch eller bfcache, og det gør dine cross-origin sider ikke.
  • Dine cachelagrede underressourcer hjælper tilbagevendende besøgende, men ikke førstegangsankomster fra eksterne kilder.

Cross-origin data er typisk det vigtigste tal for SEO. Googles Chrome UX Report (CrUX) inkluderer alle navigationstyper, men organisk søgetrafik er næsten udelukkende cross-origin. Hvis din cross-origin LCP består, mens din same-origin LCP fejler, er det usædvanligt og værd at undersøge. Det omvendte er langt mere almindeligt.

Reducering af cross-origin straffen

Du kan ikke fjerne koldstart-straffen fuldstændigt, men du kan reducere den:

  • Brug et CDN med en hurtig TTFB. Forbindelses-overhead skrumper, når din server er geografisk tæt på brugeren og reagerer hurtigt. Sigt efter en TTFB under 200 ms for HTML-dokumentet.
  • Preload LCP-billedet. Et <link rel="preload"> i <head> starter billedhentningen så tidligt som muligt og skærer tiden ned mellem HTML-levering og maling af LCP-elementet.
  • Indlejr kritisk CSS. Ingen render-blokerende stylesheet-anmodning betyder, at browseren kan male tidligere selv på en kold forbindelse.
  • Tilføj preconnect-hints til tredjeparts-origins. Hvis dit LCP-billede eller en render-blokerende ressource hostes på et andet domæne, starter et rel="preconnect"-hint TCP- og TLS-arbejdet tidligt.

For same-origin navigationer er Speculation Rules API den forbedring, der har størst indvirkning i dag. Prerendering af den mest sandsynlige næste side skærer LCP ned til næsten nul for de overgange.

Navigation Origin i kontekst

Navigation Origin fungerer godt sammen med Navigation Type-dimensionen (som adskiller navigate, reload, back-forward og prerender) og Effective Connection Type-dimensionen. En cross-origin navigation på en langsom forbindelse er det sværeste scenarie, dit websted står over for. Filtrering efter disse to betingelser sammen vil vise dig din sande worst-case ydeevne, og hvor de største forbedringer er tilgængelige.