Core/Dash Dimension: Navigationsursprung

Se om dina besökare anländer från samma domän eller från externa källor, och hur den uppdelningen formar dina Core Web Vitals.

Gratis testperiod

Trusted by market leaders · Client results

erasmusmcloopearplugsnestlefotocasadpg mediamy work featured on web.devworkivaadevintamonarchaleteiasnvnina careharvardwhowhatwearperionvpnhappyhorizonmarktplaatsebaysaturnkpncompare

Vad Navigationsursprung (Navigation Origin) mäter

Dimensionen Navigationsursprung delar upp din fältdata i två grupper:

  • Samma ursprung (Same Origin) (1) — den föregående sidan var på samma domän.
  • Korsande ursprung (Cross Origin) (2) — användaren anlände från en annan domän, en sökmotor, en social plattform eller skrev in URL:en direkt.

Denna distinktion spelar roll eftersom webbläsarens startvillkor är helt olika i varje fall. En same-origin-navigering kan återanvända en befintlig anslutning, hämta från HTTP-cachen för underresurser (subresources) och dra nytta av eventuell prefetching som din webbplats har konfigurerat. En cross-origin-navigering börjar från noll.

Varför cross-origin-navigeringar är långsammare

När en användare klickar på en länk från en extern webbplats har webbläsaren arbete att göra innan den ens kan begära din HTML:

  1. DNS-uppslagning (DNS lookup) — lös din domän till en IP-adress.
  2. TCP-handskakning (TCP handshake) — öppna en anslutning till din server.
  3. TLS-förhandling (TLS negotiation) — slutför HTTPS-handskakningen.

Tillsammans lägger dessa steg vanligtvis till 200 till 500 ms på en mobilanslutning innan den första byten av din sida har begärts. Den kostnaden visas direkt i Time to First Byte (TTFB), och om ditt LCP-element är beroende av en resurs som laddas efter att HTML:en anländer, kaskaderar det till en sämre Largest Contentful Paint (LCP) också.

Cachade underresurser är också otillgängliga. En besökare som klickade sig vidare från Google har ingen cachad kopia av dina typsnitt, hero-bild eller kritiska CSS. En besökare som precis kom från din startsida har troligen allt detta.

Same-origin-navigeringar och back-forward-cachen

Same-origin-navigeringar öppnar dörren till två prestandafördelar som cross-origin-navigeringar inte kan använda lika tillförlitligt.

För det första låter Speculation Rules API dig förhämta (prefetch) eller förrendera (prerender) interna sidor innan användaren klickar. Webbläsaren kan ha nästa sida fullt renderad i en bakgrundsflik, vilket gör navigeringen omedelbar. Detta gäller endast same-origin-destinationer.

För det andra återställer back-forward-cachen (bfcache) en sida från minnet när användaren trycker på bakåtknappen. Bfcache-träffar är extremt snabba och får bra poäng över alla Core Web Vitals. De visas i din data som same-origin-navigeringar. Om din same-origin LCP är betydligt bättre än din cross-origin LCP, bidrar troligen bfcache och prefetch till det gapet.

Hur man läser denna dimension i CoreDash

coredash metric table urls

I CoreDash använder du Navigationsursprung som ett filter eller som en uppdelningsdimension (breakdown dimension) bredvid valfri metrik. Den mest användbara jämförelsen är LCP efter navigationsursprung. Ett stort gap mellan same-origin och cross-origin LCP berättar en av tre saker för dig:

  • Dina cross-origin-ingångssidor har en långsam TTFB som blåser upp LCP.
  • Same-origin-navigeringar drar nytta av prefetch eller bfcache och det gör inte dina cross-origin-sidor.
  • Dina cachade underresurser hjälper återkommande besökare men inte förstagångsbesökare från externa källor.

Cross-origin-data är vanligtvis den viktigare siffran för SEO. Googles Chrome UX Report (CrUX) inkluderar alla navigeringstyper, men organisk söktrafik är nästan uteslutande cross-origin. Om din cross-origin LCP blir godkänd medan din same-origin LCP underkänns är det ovanligt och värt att undersöka. Det omvända är mycket vanligare.

Att minska cross-origin-straffet

Du kan inte eliminera kallstartsstraffet (cold-start penalty) helt, men du kan minska det:

  • Använd ett CDN med snabb TTFB. Anslutningsoverhead krymper när din server är geografiskt nära användaren och svarar snabbt. Sikta på en TTFB under 200 ms för HTML-dokumentet.
  • Förladda LCP-bilden (preload). En <link rel="preload"> i <head> startar bildhämtningen så tidigt som möjligt, vilket kortar tiden mellan HTML-leverans och rendering av LCP-elementet.
  • Inlina kritisk CSS. Ingen renderingsblockerande stilmallsbegäran innebär att webbläsaren kan rendera (paint) snabbare även på en kall anslutning.
  • Lägg till preconnect-tips för tredjepartsursprung. Om din LCP-bild eller en renderingsblockerande resurs hostas på en annan domän startar ett rel="preconnect"-tips TCP- och TLS-arbetet tidigt.

För same-origin-navigeringar är Speculation Rules API den förbättring med störst genomslag som finns tillgänglig idag. Att förrendera den mest troliga nästa sidan kapar LCP till nära noll för dessa övergångar.

Navigationsursprung i sitt sammanhang

Navigationsursprung fungerar bra tillsammans med dimensionen Navigeringstyp (Navigation Type) (som skiljer på navigate, reload, back-forward och prerender) och dimensionen Effektiv anslutningstyp (Effective Connection Type). En cross-origin-navigering på en långsam anslutning är det svåraste scenariot din webbplats möter. Att filtrera på dessa två villkor tillsammans kommer att visa dig din sanna sämsta-scenarioprestanda (worst-case performance) och var de största förbättringarna finns tillgängliga.