Core/Dash-ulottuvuus: Verkon nopeus

Ulottuvuus: verkon nopeus (dl)

dl-ulottuvuus kertoo käyttäjän yhteyden todellisen latauskaistanleveyden sivuvierailun hetkellä megabitteinä sekunnissa (Mbps). CoreDash kerää tämän arvon selaimen Network Information API -rajapinnasta ja jakaa vierailut kaistanleveysluokkiin. Jokainen CoreDash-taulukon rivi edustaa tiettyä nopeusluokkaa. Voit siis vertailla Core Web Vitals -tuloksiasi nopeiden laajakaistojen, keskinopeiden yhteyksien sekä hitaiden ja mobiiliyhteyksien välillä rinnakkain.

Kaistanleveys on toinen sivun latausnopeuteen vaikuttavista verkon ominaisuuksista. Toinen on viive, joka määrittää edestakaisen matka-ajan palvelimelle. CoreDashin dl-ulottuvuus eristää kaistanleveysmuuttujan. Sen avulla voit vastata konkreettiseen kysymykseen: heikkenevätkö Core Web Vitals -tuloksesi yhteysnopeuden hidastuessa ja kuinka paljon?

Miksi verkon nopeudella on merkitystä Core Web Vitals -tuloksille

Latauskaistanleveydellä on suora ja mitattava vaikutus Largest Contentful Paint -arvoon. LCP:n aiheuttaa lähes aina pääkuva (hero-kuva), suuri taustakuva tai raskas verkkofontti. 100 Mbps:n yhteydellä 400 KB:n pääkuvan siirtoaika on noin 32 millisekuntia. 5 Mbps:n yhteydellä saman kuvan siirto vie pelkästään yli 640 millisekuntia ennen viiveiden tai prosessoinnin huomioimista. Tämä ero yksinään voi pudottaa hyväksytyn LCP-tuloksen "tarvitsee parannuksia" -luokkaan.

Time to First Byte on vähemmän herkkä kaistanleveydelle. TTFB:hen vaikuttavat eniten palvelimen prosessointiaika ja verkon edestakainen viive, ei siirrettyjen tavujen määrä. Hidas palvelinvastus on hidas kaikilla yhteysnopeuksilla. Jos TTFB on huono kaikissa CoreDashin kaistanleveysluokissa, ongelma viittaa palvelin- tai CDN-ongelmiin eikä asiakaspään kaistanleveyteen.

Interaction to Next Paint on lähes kokonaan CPU-sidonnainen. INP mittaa käyttäjän syötteen ja seuraavan visuaalisen päivityksen välistä aikaa. Raskas JavaScript-suoritus, long taskit ja main threadin lukittuminen aiheuttavat huonoja INP-tuloksia. Hidas yhteys voi viivästyttää JavaScript-pakettien latautumista. Tämä voi heikentää INP-arvoa epäsuorasti, jos skriptien jäsennys on kesken käyttäjän tehdessä ensimmäisen toiminnon sivulla. Kun skriptit on ladattu, INP-suorituskyky riippuu laitteen suorituskyvystä, ei verkosta.

Käytännössä kaistanleveysongelmat näkyvät selvästi LCP Load Time -arvossa. Se on LCP:n aliosa, joka mittaa selaimen käyttämää aikaa LCP-resurssin lataamiseen sen löytymisen jälkeen. CoreDash raportoi LCP Load Time -arvon erikseen. Tämän ansiosta on helppo varmistaa, odottavatko hitaat käyttäjät verkkoa vai jotain muuta.

Datan tulkinta

CoreDash-liikenne jakautuu tyypillisesti kolmeen kaistanleveysluokkaan. Luokkien ymmärtäminen auttaa priorisoimaan korjauksia.

Nopea laajakaista: vähintään 50 Mbps

Noin 35 % CoreDash-liikenteestä kuuluu tähän luokkaan. Tähän kuuluvat valokuituyhteydet, kaapelimodeemit ja 5G-mobiilikäyttäjät hyvissä signaaliolosuhteissa. Vuonna 2025 keskimääräinen 5G-latausnopeus on noin 184 Mbps, ja kiinteän laajakaistan keskiarvo Yhdysvalloissa on saavuttanut 214 Mbps. Tämän luokan käyttäjät tuskin kohtaavat verkosta johtuvia LCP-viiveitä hyvin optimoiduilla sivuilla. Jos LCP-tulokset ovat täällä huonoja, ongelma on palvelimen vastausajassa, render blocking -resursseissa tai LCP-elementin löytymisviiveessä, ei kaistanleveydessä.

Keskinopea: 10–50 Mbps

Noin 40 % CoreDash-liikenteestä sijoittuu tälle välille. Tämä luokka kattaa vanhemmat kaapiliyhteydet, 4G LTE -yhteydet keskimääräisissä olosuhteissa (tyypilliset todelliset 4G-nopeudet ovat 10–50 Mbps) sekä osan kiinteistä langattomista yhteyksistä. Näillä nopeuksilla 300 KB:n pääkuvan siirto vie 48–240 millisekuntia. Sivut, joilla on optimoimattomia kuvia tai useita render blocking -resursseja, alkavat ylittää LCP-raja-arvot tässä luokassa. Tässä luokassa kuvaformaatin valinta (WebP, AVIF) ja aggressiivinen esilataus käyttäen fetchpriority="high"-määritettä tuovat mitattavan eron.

Hidas ja mobiili: alle 10 Mbps

Noin 25 % CoreDash-liikenteestä tulee alle 10 Mbps:n yhteyksistä. Tähän kuuluvat 3G-mobiilikäyttäjät, maaseudun kiinteät yhteydet sekä 4G-käyttäjät heikossa signaalissa tai ruuhkaisessa verkossa. 5 Mbps:n nopeudella 400 KB:n kuvan siirto kestää yli 640 millisekuntia. LCP-epäonnistumiset tässä luokassa ovat lähes varmoja. Vältyt niiltä vain, jos LCP-kuva on pakattu erittäin tehokkaasti, se tarjotaan käyttäjää lähellä olevasta CDN-reunapalvelimesta ja se esiladataan oikein. Jos yrityksesi palvelee käyttäjiä alueilla, joilla on hidas infrastruktuuri, tarkista CoreDashin Country-ulottuvuus dl-ulottuvuuden rinnalla. Näin näet, keskittyykö hidas liikenne maantieteellisesti.

Vianetsintätyönkulku

1. Suodata alle 10 Mbps:n luokkaan CoreDashissa ja tarkista LCP Load Time. Jos LCP Load Time on suurin tekijä epäonnistuneessa LCP-tuloksessa, LCP-resurssi on liian suuri hitaille yhteyksille. Pakkaa kuvaa enemmän, vaihda AVIF-muotoon ja varmista, että resurssi tarjotaan CDN-reunapalvelimelta läheltä kyseisiä käyttäjiä.
2. Vertaa tietoja Country-ulottuvuuteen. Jos hitaat käyttäjät keskittyvät tiettyihin maihin, tarkista CDN-verkkosi kattavuus kyseisillä alueilla. Käyttäjä, jolla on 15 Mbps:n yhteys ja jota palvelee 200 ms:n päässä oleva CDN-reunapalvelin, saa huomattavasti huonomman kokemuksen kuin saman nopeuden käyttäjä, jota palvelee 10 ms:n päässä oleva solmu.
3. Tarkista INP- ja TTFB-tulokset eri luokissa. Jos INP heikkenee matalan kaistanleveyden luokissa mutta ei nopeissa, suuria JavaScript-paketteja ladataan edelleen, kun käyttäjät tekevät ensimmäisen toimintonsa. Jaa JavaScript-koodisi osiin, viivästytä ei-kriittisiä skriptejä ja harkitse yielding to the main thread -menetelmää alustuksen aikana. Tämä vähentää INP-altistusta jäsennysvaiheen aikana.

Tekniset nyrkkisäännöt

• Tavoittele alle 100 KB:n LCP-kuvan tiedostokokoa (AVIF tai WebP). Näin pidät LCP Load Time -arvon alle 200 ms:ssa jopa 5 Mbps:n yhteyksillä.
• Sivun yläosan resurssien kokonaiskoon tulisi olla alle 500 KB. Se takaa kohtuullisen LCP:n 10 Mbps:n yhteyksillä 2,5 sekunnin aikarajassa.
• Käytä LCP-kuvassa määritettä fetchpriority="high" ja esilataa se dokumentin <head>-osaan. Näin selain ei tuhlaa kaistanleveyttä alemman prioriteetin resursseihin ensin.
• Tarjoa kaikki staattiset resurssit CDN-verkosta. CoreDashin kaistanleveyslukemat mittaavat asiakkaan yhteyttä, eivät palvelinta. Nopeasta asiakasyhteydestä ei ole hyötyä, jos palvelin sijaitsee kaukana ja lisää 300 ms viivettä ennen ensimmäisen tavun saapumista.
• Jos yli 15 % liikenteestäsi on alle 10 Mbps:n luokassa ja LCP epäonnistuu näillä käyttäjillä, käsittele kuvien optimointia ja CDN-kattavuutta P1-tason ongelmina ennen muiden asioiden korjaamista.