Core/Dash -ulottuvuus: Navigointityyppi

Ulottuvuus: Navigointityyppi (nt)

Jokainen sivulataus CrUX-datassasi sisältää navigointityypin. Se kertoo, miten selain latasi sivun, mikä määrittää, mitkä selainjärjestelmät olivat osallisina: verkkopino, back/forward cache, prerender-liukuhihna tai istunnon palautus. CoreDash näyttää tämän nt-ulottuvuutena, jotta voit suodattaa ja vertailla Core Web Vitals -lukemia erikseen jokaisessa navigointikontekstissa.

Data on peräisin PerformanceNavigationTiming API:sta, tarkemmin sanoen type-ominaisuudesta. Voit lukea sen komennolla performance.getEntriesByType("navigation")[0].type. Chrome raportoi tämän arvon jokaisen CrUXiin lähetetyn Web Vitals -mittauksen yhteydessä, ja CoreDash tallentaa sekä indeksoi sen, jotta voit segmentoida dataa kirjoittamatta omaa koodia sen seuraamiseksi.

Miksi navigointityypillä on merkitystä

LCP- tai INP-arvojen yhdistäminen kaikkien navigointityyppien yli tuottaa luvun, joka on teknisesti oikein, mutta käytännössä harhaanjohtava. Back/forward cache -osuma (bfcache) suoritetaan millisekunneissa. Kylmä navigointi odottaa DNS:ää, TCP:tä, TLS:ää ja TTFB:tä. Jos 20 % istunnoistasi on bfcache-osumia, ne vetävät p75 LCP -arvoa alaspäin ja vaikeuttavat uusien navigointien todellisten ongelmien havaitsemista.

Sama pätee myös käänteisesti. Jos bfcache on rikki sivustollasi, back/forward-istunnot suoriutuvat yhtä huonosti kuin uudet navigoinnit. Ilman navigointityypin mukaista segmentointia et koskaan huomaa tätä, koska aggregaatti pysyy vakaana.

Esilataus (prerender) on dramaattisin tapaus. Oikein esiladatun sivun LCP-arvon pitäisi olla lähellä nollaa, koska renderöinti on päättynyt jo ennen kuin käyttäjä edes klikkasi linkkiä. Jos esiladattujen sivujesi LCP-luvut ovat normaalitasolla, Speculation Rules -määritykset ovat pielessä ja prerender ei joko käynnisty tai se hylätään ennen käyttöä.

Navigointityypit

navigate

Vakionavigointi: käyttäjä kirjoitti URL-osoitteen, klikkasi linkkiä toiselta sivustolta tai seurasi uudelleenohjausta. Tämä on täysi sivun lataus ilman välimuistin oikoteitä. Selain käy läpi koko pyyntöliukuhihnan, mukaan lukien DNS-haun, yhteyden muodostamisen ja kaikkien resurssien lataamisen. CoreDash-datassa navigate kattaa noin 65 % istunnoista. Se on perustasosi. Kaikkia muita navigointityyppejä tulisi arvioida vertaamalla niitä navigate-lataukseen.

reload

Käyttäjä painoi F5:tä, klikkasi selaimen lataa uudelleen -painiketta tai koodisi kutsui location.reload() -funktiota. Selain lähettää uudelleenvahvistuspyyntöjä välimuistissa oleville resursseille, mikä tarkoittaa, että TTFB näyttää usein huonommalta kuin navigate-latauksessa, vaikka käyttäjä on samalla sivulla. Jos reload TTFB on huomattavasti korkeampi kuin navigate TTFB, välimuistiotsikkosi laukaisevat uudelleenvahvistuksen jokaisella uudelleenlatauksella sen sijaan, että ne tarjoaisivat vanhentunutta (stale) sisältöä. Tyypillisessä CoreDash-liikenteessä noin 10 % istunnoista on uudelleenlatauksia.

back_forward

Käyttäjä painoi selaimen edellinen- tai seuraava-painiketta. Jos back/forward cache (bfcache) toimii, tämä on nopein mahdollinen navigointityyppi. Selain palauttaa sivun muistista ilman ainoatakaan verkkopyyntöä. LCP bfcache-osumalle on käytännössä aika, joka kuluu muistista piirtämiseen, mikä tapahtuu lähes välittömästi.

Jos back_forward-metriikkasi näyttää samalta kuin navigate, bfcache ei toimi. Yleisimmät syyt tähän ovat unload-tapahtumankäsittelijät, Cache-Control: no-store -vastausotsikot sekä avoimet IndexedDB-yhteydet, joita ei suljettu ennen navigointia. CoreDash-datan mukaan back/forward on noin 20 % istunnoista, mikä tekee tämän korjaamisesta erittäin hyödyllistä.

prerender

Sivu ladattiin taustalla käyttämällä Speculation Rules API:a ennen kuin käyttäjä klikkasi linkkiä. Kun käyttäjä klikkaa, esiladattu dokumentti aktivoidaan välittömästi. LCP oikein aktivoidulle prerender-lataukselle on lähellä nollaa, koska kaikki renderöintityö saatiin päätökseen ennen navigointitapahtumaa.

Jos prerender LCP näyttää normaalilta, on tapahtunut jokin kolmesta asiasta: prerender hylättiin ennen aktivointia, spekulointisääntö kohdistui vääriin URL-osoitteisiin, tai sivu käyttää otsikoita tai JavaScript-koodia, joka estää esilatauksen. Noin 3 % CoreDash-istunnoista on prerender-aktivointeja, mutta tämä osuus nousee nopeasti, kun Speculation Rules on otettu käyttöön.

restore

Välilehti palautettiin selaimen sulkemisen tai välilehden kaatumisen jälkeen. Selain lataa sivun alusta alkaen, mutta istuntoa pidetään palautuksena (restore) pikemminkin kuin uutena navigointina. Suorituskyky on samanlainen kuin kylmässä navigoinnissa. Tämä kattaa noin 2 % istunnoista ja on harvoin optimointityön pääkohteena, mutta sitä on syytä seurata, jos käyttäjilläsi on epävakaita selainistuntoja.

Debuggauksen työnkulku

1. Vertaile navigate LCP -arvoa yleiseen LCP-tavoitteeseesi. Tämä on perustotuutesi uuden latauksen suorituskyvylle. Jos navigate läpäisee tavoitteet jo nyt, ongelmasi on muualla.
2. Vertaile back_forward -latausta navigate-lataukseen. Jos ne ovat lähellä toisiaan, bfcache on rikki. Avaa Chrome DevTools, siirry Application-paneeliin ja suorita bfcache-testi. DevTools-tuloste luettelee tarkalleen, mitkä ominaisuudet tai otsikot estävät bfcachen kelpoisuuden.
3. Tarkista prerender LCP. Jos se on yli 200ms, prerender-liukuhihna ei toimi odotetusti. Varmista, että Speculation Rules JSON on kelvollinen, tarkista, etteivät kohdesivut palauta estävää logiikkaa, ja varmista Chrome DevToolsin Speculation Rules -osiosta, että aktivointeja lasketaan.

Insinöörin peukalosääntö

• navigate: Pitäisi saavuttaa LCP-rajasi normaalin optimoinnin kautta: nopea TTFB, fetchpriority="high" LCP-kuvassa, ei renderöintiä estäviä resursseja.
• back_forward: Pitäisi olla 10–20 kertaa nopeampi kuin navigate. Jos ei ole, bfcache on rikki.
• prerender: LCP:n pitäisi olla alle 200ms. Jos ei ole, Speculation Rules -määrityksesi ovat pielessä.
• reload: TTFB:n ei pitäisi olla huomattavasti huonompi kuin navigate-latauksessa. Jos on, korjaa välimuistin uudelleenvahvistusotsikot.

Navigointityyppi (Navigation Type) on ulottuvuus, joka erottaa kysymyksen "miten sivuni suoriutuu?" kysymyksestä "miten sivuni suoriutuu kullakin selaimen latausstrategialla?". Tämä ero on rajanveto arvaamisen ja debuggaamisen välillä.