Core/Dash-ulottuvuus: Navigation Type

Ulottuvuus: Navigation Type (nt)

Jokainen sivukatselu CrUX-datassasi sisältää navigointityypin. Se kertoo, miten selain latasi sivun. Tämä määrittää, mitkä selaimen osat olivat käytössä: verkkopino, back/forward-välimuisti (bfcache), prerender-putki vai istunnon palautus. CoreDash tarjoaa tämän nt-ulottuvuutena, jotta voit suodattaa ja vertailla Core Web Vitals -tuloksia kussakin navigointikontekstissa erikseen.

Data saadaan PerformanceNavigationTiming API:sta, tarkemmin ottaen sen type-ominaisuudesta. Voit lukea sen koodilla performance.getEntriesByType("navigation")[0].type. Chrome raportoi tämän arvon jokaisen CrUX:iin lähetettävän web vitals -mittauksen yhteydessä. CoreDash tallentaa ja indeksoi arvon, joten voit tehdä segmentoinnin ilman erillistä instrumentointia.

Miksi navigointityypillä on väliä

LCP:n tai INP:n aggregointi kaikkien navigointityyppien yli tuottaa luvun, joka on teknisesti oikein mutta käytännössä harhaanjohtava. Back/forward-välimuistiosuma valmistuu millisekunteissa. Kylmä navigointi puolestaan odottaa DNS:ää, TCP:tä, TLS:ää ja TTFB:tä. Jos 20 % istunnoistasi on bfcache-osumia, ne vetävät LCP:n p75-arvoa alaspäin. Tämä vaikeuttaa uusien navigointien todellisten ongelmien havaitsemista.

Sama pätee myös toisinpäin. Jos sivustosi bfcache on rikki, back/forward-istunnot toimivat yhtä huonosti kuin uudet navigoinnit. Ilman segmentointia navigointityypin mukaan et koskaan huomaa tätä, koska kokonaisarvo pysyy vakaana.

Prerender on kaikkein dramaattisin tapaus. Oikein prerenderöidyn sivun LCP:n pitäisi olla lähellä nollaa, koska renderöinti valmistui jo ennen kuin käyttäjä edes klikkasi linkkiä. Jos prerenderöidyt sivusi näyttävät normaaleja LCP-lukuja, Speculation Rules -määritykset ovat väärin. Tällöin prerender ei joko käynnisty tai se hylätään ennen käyttöä.

Navigointityypit

navigate

Tavallinen navigointi: käyttäjä kirjoitti osoitteen, klikkasi linkkiä toiselta sivustolta tai seurasi uudelleenohjausta. Tämä on täysi sivunlataus ilman välimuistin oikoteitä. Selain käy läpi koko pyyntöprosessin, mukaan lukien DNS-selvityksen, yhteyden muodostamisen ja kaikkien resurssien lataamisen. CoreDash-datassa navigate kattaa noin 65 % istunnoista. Se on perustasosi. Kaikkia muita navigointityyppejä tulisi verrata siihen, miten ne pärjäävät suhteessa navigate-tyyppiin.

reload

Käyttäjä painoi F5-näppäintä, klikkasi selaimen päivityspainiketta tai koodisi kutsui funktiota location.reload(). Selain lähettää uudelleentarkistuspyyntöjä välimuistissa oleville resursseille. Tämän vuoksi TTFB näyttää usein huonommalta kuin tavallisessa navigoinnissa, vaikka käyttäjä on samalla sivulla. Jos reload-tyypin TTFB on huomattavasti korkeampi kuin navigate-tyypin TTFB, välimuistiotsikkosi laukaisevat uudelleentarkistuksen jokaisella päivityksellä sen sijaan, että ne tarjoaisivat vanhentunutta sisältöä suoraan välimuistista. Noin 10 % istunnoista on reload-tyyppisiä tyypillisessä CoreDash-liikenteessä.

back_forward

Käyttäjä painoi selaimen takaisin- tai eteenpäin-painiketta. Jos back/forward-välimuisti (bfcache) toimii, tämä on nopein mahdollinen navigointityyppi. Selain palauttaa sivun muistista tekemättä lainkaan verkkopyyntöjä. Bfcache-osuman LCP on käytännössä vain muistista piirtämiseen kuluva aika, eli se on lähes välitön.

Jos back_forward-mittarisi näyttävät samalta kuin navigate-mittarit, bfcache ei toimi. Yleisimmät syyt ovat unload-tapahtumankäsittelijät, Cache-Control: no-store -vastausotsikot sekä avoimet IndexedDB-yhteydet, joita ei suljettu ennen navigointia. CoreDash-datassa back/forward-lataukset kattavat noin 20 % istunnoista, joten tämä on erittäin vaikuttava korjauskohde.

prerender

Sivu ladattiin taustalla käyttäen Speculation Rules API:a ennen kuin käyttäjä klikkasi linkkiä. Kun käyttäjä klikkaa linkkiä, prerenderöity dokumentti aktivoidaan välittömästi. Oikein aktivoidun prerender-sivun LCP on lähes nolla, koska kaikki renderöintityö tehtiin jo ennen navigointitapahtumaa.

Jos prerender-latauksen LCP näyttää normaalilta, kyse on yhdestä kolmesta syystä: prerender-sivu hylättiin ennen aktivointia, speculation rule kohdistui vääriin URL-osoitteisiin tai sivu käyttää otsikoita tai JavaScriptiä, jotka estävät prerenderöinnin. Noin 3 % CoreDash-istunnoista on prerender-aktivointeja, mutta osuus kasvaa nopeasti, kun Speculation Rules otetaan käyttöön.

restore

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

Debuggauksen työnkulku

1. Vertaa navigate-LCP:tä kokonais-LCP-tavoitteeseesi. Tämä on perustotuutesi uuden latauksen suorituskyvylle. Jos navigate-lataukset läpäisevät jo tavoitteen, ongelmasi on muualla.
2. Vertaa back_forward-latauksia navigate-latauksiin. Jos ne ovat lähellä toisiaan, bfcache on rikki. Avaa Chrome DevTools, siirry Application-paneeliin ja aja bfcache-testi. DevTools listaa tarkasti, mitkä ominaisuudet tai otsikot estävät bfcache-kelpoisuuden.
3. Tarkista prerender-latausten LCP. Jos se on yli 200 ms, prerender-putki ei toimi oikein. Varmista, että Speculation Rules -JSON-määrityksesi on validi, tarkista, etteivät kohdesivut sisällä estävää logiikkaa, ja varmista Chrome DevToolsissa Speculation Rules -osiosta, että aktivoinnit rekisteröityvät.

Kehittäjän nyrkkisäännöt

• navigate: Pitäisi saavuttaa LCP-kynnysarvosi normaaleilla optimoinneilla: nopea TTFB, fetchpriority="high" LCP-kuvassa, ei render blocking -resursseja.
• back_forward: Pitäisi olla 10–20 kertaa nopeampi kuin navigate. Jos ei ole, bfcache on rikki.
• prerender: Pitäisi näyttää alle 200 ms LCP-aikoja. Jos ei näytä, Speculation Rules -määritykset ovat väärin.
• reload: TTFB ei saisi olla huomattavasti huonompi kuin navigate-tyypillä. Jos se on, korjaa välimuistin uudelleentarkistusotsikot.

Navigation Type on se ulottuvuus, joka erottaa kysymykset ”miten sivuni suoriutuu?” ja ”miten sivuni suoriutuu kullakin selaimen latausstrategialla?” toisistaan. Tämä erottelu tekee eron arvailun ja debuggaamisen välillä.