Core/Dash-ulottuvuus: Navigaation alkuperä

Katso, saapuvatko vierailijasi samalta verkkotunnukselta vai ulkoisista lähteistä, ja kuinka tämä jako muokkaa Core Web Vitals -arvojasi.

Ilmainen kokeilu

Trusted by market leaders · Client results

comparealeteianestlesaturnwhowhatwearebaymarktplaatsperionmy work featured on web.devloopearplugsmonarchkpnerasmusmcadevintaworkivasnvvpnhappyhorizonnina caredpg mediafotocasaharvard

Mitä Navigaation alkuperä mittaa

Navigaation alkuperä -ulottuvuus jakaa kenttädatasi kahteen ryhmään:

  • Sama alkuperä (Same Origin) (1) — edellinen sivu oli samalla verkkotunnuksella.
  • Eri alkuperä (Cross Origin) (2) — käyttäjä saapui eri verkkotunnukselta, hakukoneesta, sosiaalisesta mediasta tai kirjoitti URL-osoitteen suoraan selaimeen.

Tämä ero on tärkeä, koska selaimen lähtökohdat ovat kummassakin tapauksessa täysin erilaiset. Saman alkuperän navigaatio voi käyttää uudelleen olemassa olevaa yhteyttä, hyödyntää HTTP-välimuistia aliresursseille ja hyötyä sivustollesi asetetuista esilatauksista (prefetching). Eri alkuperän navigaatio alkaa täysin nollasta.

Miksi eri alkuperän navigaatiot ovat hitaampia

Kun käyttäjä napsauttaa linkkiä ulkoisella sivustolla, selaimella on työtä tehtävänä ennen kuin se voi edes pyytää HTML-tiedostoasi:

  1. DNS-haku (DNS lookup) — selvittää verkkotunnuksesi IP-osoitteen.
  2. TCP-kättely (TCP handshake) — avaa yhteyden palvelimeesi.
  3. TLS-neuvottelu (TLS negotiation) — suorittaa HTTPS-kättelyn loppuun.

Yhdessä nämä vaiheet lisäävät tyypillisesti 200–500 ms mobiiliyhteydellä ennen kuin sivusi ensimmäistä tavua on pyydetty. Tämä viive näkyy suoraan Time to First Byte (TTFB) -arvossa, ja jos LCP-elementtisi on riippuvainen HTML:n saapumisen jälkeen ladattavasta resurssista, se heikentää myös Largest Contentful Paint (LCP) -arvoa.

Välimuistissa olevia aliresursseja ei myöskään ole saatavilla. Googlesta saapuvalla vierailijalla ei ole välimuistissa olevaa kopiota fonteistasi, hero-kuvastasi tai kriittisestä CSS:stä. Vierailijalla, joka saapui juuri etusivultasi, todennäköisesti on nämä kaikki.

Saman alkuperän navigaatiot ja back-forward cache

Saman alkuperän navigaatiot avaavat oven kahdelle suorituskykyedulle, joita eri alkuperän navigaatiot eivät voi hyödyntää yhtä luotettavasti.

Ensimmäiseksi Speculation Rules API sallii sinun esiladata (prefetch) tai esiesittää (prerender) sisäisiä sivuja ennen kuin käyttäjä napsauttaa niitä. Selain voi renderöidä seuraavan sivun täysin valmiiksi taustavälilehdellä, mikä tekee navigaatiosta välittömän. Tämä koskee vain saman alkuperän kohteita.

Toiseksi back-forward cache (bfcache) palauttaa sivun muistista, kun käyttäjä painaa takaisin-painiketta. Bfcache-osumat ovat erittäin nopeita ja saavat hyvät pisteet kaikissa Core Web Vitals -mittareissa. Ne näkyvät datassasi saman alkuperän navigaatioina. Jos saman alkuperän LCP on huomattavasti parempi kuin eri alkuperän LCP, bfcache ja prefetch todennäköisesti vaikuttavat tähän eroon.

Kuinka tulkita tätä ulottuvuutta CoreDashissa

coredash metric table urls

CoreDashissa voit käyttää Navigaation alkuperä -ulottuvuutta suodattimena tai erittelevänä ulottuvuutena minkä tahansa mittarin rinnalla. Hyödyllisin vertailu on LCP navigaation alkuperän mukaan. Suuri ero saman alkuperän ja eri alkuperän LCP:n välillä kertoo yhden kolmesta asiasta:

  • Eri alkuperän aloitussivuillasi on hidas TTFB, joka kasvattaa LCP:tä.
  • Saman alkuperän navigaatiot hyötyvät prefetchistä tai bfcachesta, mutta eri alkuperän sivusi eivät.
  • Välimuistissa olevat aliresurssit auttavat palaavia vierailijoita, mutta eivät ulkoisista lähteistä ensimmäistä kertaa saapuvia.

Eri alkuperän data on tyypillisesti tärkeämpi luku SEO:n kannalta. Googlen Chrome UX Report (CrUX) sisältää kaikki navigaatiotyypit, mutta orgaaninen hakuliikenne on lähes kokonaan eri alkuperästä. Jos eri alkuperän LCP läpäisee mittaukset, mutta saman alkuperän LCP epäonnistuu, se on epätavallista ja tutkimisen arvoista. Päinvastainen tilanne on paljon yleisempi.

Eri alkuperän haittojen vähentäminen

Et voi poistaa kylmäkäynnistyksen viivettä kokonaan, mutta voit vähentää sitä:

  • Käytä CDN:ää, jolla on nopea TTFB. Yhteysviiveet pienenevät, kun palvelimesi on maantieteellisesti lähellä käyttäjää ja vastaa nopeasti. Pyri alle 200 ms TTFB-arvoon HTML-dokumentille.
  • Esilataa LCP-kuva. <link rel="preload"> <head>-osiossa aloittaa kuvan noudon mahdollisimman aikaisin, lyhentäen HTML:n toimituksen ja LCP-elementin piirtämisen välistä aikaa.
  • Sisällytä kriittinen CSS (inline). Renderöinnin estävän tyylitiedostopyynnön puuttuminen tarkoittaa, että selain voi piirtää nopeammin jopa kylmällä yhteydellä.
  • Lisää preconnect-vihjeitä kolmannen osapuolen alkuperille. Jos LCP-kuvasi tai renderöinnin estävä resurssi sijaitsee eri verkkotunnuksella, rel="preconnect"-vihje aloittaa TCP- ja TLS-työn aikaisin.

Saman alkuperän navigaatioille Speculation Rules API on nykyään vaikuttavin saatavilla oleva parannus. Todennäköisimmän seuraavan sivun esiesittäminen (prerendering) pudottaa LCP:n lähes nollaan näissä siirtymissä.

Navigaation alkuperä kontekstissa

Navigaation alkuperä toimii hyvin yhdessä Navigation Type -ulottuvuuden (joka erottelee navigate, reload, back-forward ja prerender -navigaatiot) ja Effective Connection Type -ulottuvuuden kanssa. Eri alkuperän navigaatio hitaalla yhteydellä on vaikein skenaario, jonka sivustosi kohtaa. Näiden kahden ehdon yhdistäminen suodattimilla näyttää todellisen huonoimman tapauksen suorituskykysi ja sen, missä suurimmat parannukset ovat tehtävissä.