Core/Dash-dimensio: Verkon nopeus

Dimensio: Verkon nopeus (dl)

dl-dimensio (download) raportoi kunkin käyttäjän yhteyden tehollisen latauskaistanleveyden sivuvierailun hetkellä, mitattuna megabitteinä sekunnissa (Mbps). CoreDash kerää tämän arvon selaimen Network Information API:sta ja ryhmittelee vierailut kaistanleveystasoihin. Jokainen CoreDash-taulukon rivi edustaa tiettyä nopeusluokkaa, joten voit vertailla Core Web Vitals -tuloksiasi nopeiden laajakaistakäyttäjien, keskinopeiden yhteyksien sekä hitaiden tai mobiiliyhteyksien välillä vierekkäin.

Kaistanleveys on toinen kahdesta verkon ominaisuudesta, jotka muokkaavat sivun latauksen suorituskykyä. Toinen on viive (latency), joka hallitsee edestakaista matkaa (round-trip time) palvelimelle. CoreDashin dl-dimensio eristää kaistanleveysmuuttujan, jotta voit vastata konkreettiseen kysymykseen: heikkenevätkö Core Web Vitals -tuloksesi yhteysnopeuden laskiessa, ja kuinka paljon?

Miksi verkon nopeudella on merkitystä Core Web Vitals -mittareille

Latauskaistanleveydellä on suora ja mitattavissa oleva vaikutus Largest Contentful Paintiin (LCP). LCP:n laukaisee lähes aina hero-kuva, suuri taustakuva tai raskas verkkofontti. 100 Mbps:n yhteydellä 400 kt:n hero-kuva saapuu karkeasti 32 millisekunnin siirtoajassa. 5 Mbps:n yhteydellä sama kuva vie yli 640 millisekuntia pelkässä siirtoajassa, ennen kuin huomioidaan mitään viivettä tai käsittelyn yleiskustannuksia (overhead). Jo pelkästään tuo ero voi painaa hyväksytyn LCP-tuloksen "kaipaa parannusta" -alueelle.

Time to First Byte (TTFB) on vähemmän herkkä kaistanleveydelle. TTFB:tä hallitsevat palvelimen käsittelyaika ja verkon edestakainen viive, ei siirrettyjen tavujen määrä. Hidas palvelimen vastaus on hidas millä tahansa yhteysnopeudella. Jos TTFB on huono kaikilla kaistanleveystasoilla CoreDashissa, se viittaa palvelimen tai CDN:n ongelmiin asiakaspuolen kaistanleveysongelman sijaan.

Interaction to Next Paint (INP) on lähes kokonaan sidottu prosessoriin (CPU). INP mittaa aikaa käyttäjän syötteestä seuraavaan visuaaliseen päivitykseen. Raskas JavaScriptin suorittaminen, pitkät tehtävät ja pääsäikeen (main thread) tukkiminen aiheuttavat huonoja INP-tuloksia. Hidas yhteys voi viivästyttää JavaScript-pakettien alkuperäistä latausta, mikä voi epäsuorasti huonontaa INP:tä, jos komentosarjoja vielä jäsennetään (parsing), kun käyttäjä ensimmäisen kerran on vuorovaikutuksessa sivun kanssa. Mutta kun komentosarjat on ladattu, INP-suorituskyvyn määrittää laitteen prosessointiteho, ei verkko.

Käytännössä kaistanleveysongelmat nousevat selvästi esiin LCP Load Timessa, LCP:n osassa, joka mittaa kuinka kauan selain käytti LCP-resurssin lataamiseen sen löytymisen jälkeen. CoreDash raportoi LCP Load Timen erikseen, mikä tekee suoraviivaiseksi vahvistaa, odottavatko hitaat käyttäjät verkkoa vai jotain muuta.

Tietojen lukeminen

CoreDash-liikenne tyypillisillä sivustoilla jakautuu kolmeen kaistanleveystasoon. Ymmärtämällä, mitä kukin taso edustaa, voit priorisoida korjauksia.

Nopea laajakaista: 50 Mbps ja yli

Noin 35 % CoreDash-liikenteestä putoaa tälle tasolle. Tämä sisältää kuituyhteydet, kaapelilaajakaistan ja 5G-mobiilikäyttäjät hyvissä signaaliolosuhteissa. Keskimääräiset 5G-latausnopeudet vuonna 2025 ovat noin 184 Mbps, ja kiinteän laajakaistan keskiarvot Yhdysvalloissa ovat saavuttaneet 214 Mbps. Tämän tason käyttäjät eivät todennäköisesti koe verkkolähtöisiä LCP-viiveitä hyvin optimoiduilla sivuilla. Jos LCP-tulokset ovat täällä huonoja, ongelmana on palvelimen vasteaika, renderöinnin estävät resurssit tai LCP-elementin löytymisen viive, ei kaistanleveys.

Keskinopea: 10–50 Mbps

Noin 40 % CoreDash-liikenteestä laskeutuu tälle alueelle. Tämä taso kattaa vanhemmat kaapeliyhteydet, 4G LTE:n keskimääräisissä signaaliolosuhteissa (tyypilliset 4G:n todelliset nopeudet ovat 10–50 Mbps) ja jotkut kiinteän langattoman verkon käyttäjät. 300 kt:n hero-kuva vie näillä nopeuksilla 48–240 millisekuntia siirtoaikaa. Sivut, joilla on optimoimattomia kuvia tai useita renderöinnin estäviä resursseja, alkavat epäonnistua LCP-kynnyksissä tällä tasolla. Tämä on taso, jolla kuvaformaattivalinnat (WebP, AVIF) ja aggressiivinen esilataus (preloading) käyttämällä fetchpriority="high" tekevät mitattavissa olevan eron.

Hidas ja mobiili: Alle 10 Mbps

Noin 25 % CoreDash-liikenteestä tulee alle 10 Mbps:n yhteyksistä. Tämä sisältää 3G-mobiilikäyttäjät, maaseudun kiinteät yhteydet ja 4G-käyttäjät huonoissa signaali- tai ruuhkaisissa verkko-olosuhteissa. 5 Mbps:n nopeudella 400 kt:n kuva vie yli 640 millisekuntia pelkässä siirtoajassa. LCP-epäonnistumiset tällä tasolla ovat lähes varmoja, ellei LCP-kuvaa ole pakattu aggressiivisesti, tarjoiltu käyttäjää lähellä olevan CDN-reunasolmun (edge node) kautta ja esiladattu oikein. Jos yrityksesi palvelee käyttäjiä alueilla, joilla on historiallisesti hitaampi infrastruktuuri, tarkista CoreDashin Maa-dimensio (Country) yhdessä dl:n kanssa vahvistaaksesi, keskittyykö hidas liikenne maantieteellisesti.

Vianmäärityksen työnkulku

1. Suodata alle 10 Mbps:n tasoon CoreDashissa ja tarkista LCP Load Time. Jos LCP Load Time on hallitseva tekijä hylättyyn LCP-tulokseen, LCP-resurssi on liian suuri hitaille yhteyksille. Pakkaa kuvaa edelleen, vaihda AVIF-muotoon ja varmista, että resurssi tarjoillaan CDN:stä, jonka reunasolmu on lähellä kyseisiä käyttäjiä.
2. Vertaa Maa-dimensioon (Country). Jos hitaiden nopeuksien käyttäjät keskittyvät tiettyihin maihin, tarkista, onko CDN:lläsi hyvä kattavuus näillä alueilla. Käyttäjä 15 Mbps:n yhteydellä, jota palvelee 200 ms:n päässä oleva CDN-reunasolmu, saa paljon huonomman kokemuksen kuin samalla nopeudella oleva käyttäjä, jota palvelee 10 ms:n päässä oleva solmu.
3. Tarkista INP- ja TTFB-tulokset tasojen yli. Jos INP huononee alhaisen kaistanleveyden tasoilla mutta ei korkeilla, suuria JavaScript-paketteja ladataan edelleen, kun käyttäjät ovat ensimmäisen kerran vuorovaikutuksessa. Jaa JavaScript osiin, siirrä (defer) ei-kriittisiä komentosarjoja tuonnemmaksi ja harkitse pääsäikeelle (main thread) luovuttamista alustuksen aikana INP-altistumisen vähentämiseksi jäsentämisvaiheessa.

Nyrkkisääntö insinööreille

• Tähtää alle 100 kt:n LCP-kuvatiedostokokoon (AVIF tai WebP) pitääksesi LCP Load Timen alle 200 ms:ssa jopa 5 Mbps:n yhteyksillä.
• Sivun yläosan (above-the-fold) resurssien kokonaispainon tulisi pysyä alle 500 kt:ssa, jotta saavutetaan kohtuullinen LCP 10 Mbps:n yhteyksillä 2,5 sekunnin kynnyksen sisällä.
• Käytä fetchpriority="high" LCP-kuvassa ja esilataa se dokumentin <head>-osiossa, jotta selain ei tuhlaa kaistanleveyttä alemman prioriteetin resursseihin ensin.
• Tarjoile kaikki staattiset resurssit CDN:stä. CoreDashin kaistanleveysluvut mittaavat asiakkaan yhteyttä, eivät palvelimen. Nopea asiakasyhteys ei auta, jos palvelin on maantieteellisesti kaukana ja lisää 300 ms viivettä ennen kuin ensimmäinen tavu saapuu.
• Jos yli 15 % liikenteestäsi on alle 10 Mbps:n tasolla ja LCP epäonnistuu näillä käyttäjillä, käsittele kuvan optimointia ja CDN-kattavuutta P1-ongelmina ennen kuin puutut mihinkään muuhun.