Core/Dash-dimensjon: Nettverkshastighet

Dimensjon: Nettverkshastighet (dl)

dl-dimensjonen rapporterer den effektive nedlastingsbåndbredden for hver brukers tilkobling på tidspunktet for sidebesøket, målt i megabit per sekund (Mbps). CoreDash samler inn denne verdien fra nettleserens Network Information API og grupperer besøk i båndbreddenivåer. Hver rad i CoreDash-tabellen representerer en spesifikk hastighetskategori, slik at du kan sammenligne Core Web Vitals-poengsummene dine på tvers av brukere med raskt bredbånd, moderate tilkoblinger og trege eller mobile tilkoblinger side om side.

Båndbredde er en av to nettverksegenskaper som former ytelsen til sideinnlasting. Den andre er forsinkelse (latency), som styrer tur-retur-tiden til serveren. CoreDash sin dl-dimensjon isolerer båndbreddevariabelen slik at du kan svare på et konkret spørsmål: forringes Core Web Vitals-poengsummene dine etter hvert som tilkoblingshastigheten synker, og med hvor mye?

Hvorfor nettverkshastighet er viktig for Core Web Vitals

Nedlastingsbåndbredde har en direkte og målbar innvirkning på Largest Contentful Paint. LCP utløses nesten alltid av et heltebilde, et stort bakgrunnsbilde eller en tung webfont. På en 100 Mbps-tilkobling ankommer et 400 KB heltebilde på omtrent 32 millisekunder i overføringstid. På en 5 Mbps-tilkobling tar det samme bildet over 640 millisekunder i overføringstid alene, før man tar hensyn til forsinkelse eller prosesseringskostnader. Den forskjellen alene kan skyve en godkjent LCP-poengsum inn i området som "trenger forbedring".

Time to First Byte er mindre følsom for båndbredde. TTFB domineres av serverens behandlingstid og nettverkets tur-retur-forsinkelse, ikke volumet av overførte byte. En treg serverrespons er treg uansett tilkoblingshastighet. Hvis TTFB er dårlig på tvers av alle båndbreddenivåer i CoreDash, peker det på server- eller CDN-problemer snarere enn et båndbreddeproblem på klientsiden.

Interaction to Next Paint er nesten utelukkende CPU-bundet. INP måler tiden fra brukerinndata til neste visuelle oppdatering. Tung JavaScript-kjøring, lange oppgaver og blokkering av hovedtråden driver dårlige INP-poengsummer. En treg tilkobling kan forsinke den opprinnelige nedlastingen av JavaScript-pakker, som indirekte kan forverre INP hvis skript fortsatt analyseres når brukeren først samhandler med siden. Men når skriptene først er lastet inn, bestemmes INP-ytelsen av enhetens prosessorkraft, ikke nettverket.

I praksis dukker båndbreddeproblemer tydelig opp i LCP Load Time, underdelen av LCP som måler hvor lang tid nettleseren brukte på å laste ned LCP-ressursen etter at den ble oppdaget. CoreDash rapporterer LCP Load Time separat, noe som gjør det enkelt å bekrefte om trege brukere venter på nettverket eller på noe annet.

Lese dataene

CoreDash-trafikk på tvers av typiske nettsteder deles inn i tre båndbreddenivåer. Å forstå hva hvert nivå representerer hjelper deg med å prioritere feilrettinger.

Raskt bredbånd: 50 Mbps og over

Omtrent 35 % av CoreDash-trafikken faller i dette nivået. Dette inkluderer fibertilkoblinger, kabelbredbånd og 5G-mobilbrukere med gode signalforhold. Gjennomsnittlig nedlastingshastighet for 5G i 2025 ligger på rundt 184 Mbps, og gjennomsnittet for fast bredbånd i USA har nådd 214 Mbps. Det er usannsynlig at brukere i dette nivået vil oppleve nettverksdrevne LCP-forsinkelser på godt optimaliserte sider. Hvis LCP-poengsummene er dårlige her, er problemet serverens responstid, gjengivelsesblokkerende ressurser eller forsinkelse i oppdagelse av LCP-elementet, ikke båndbredde.

Moderat hastighet: 10 til 50 Mbps

Omtrent 40 % av CoreDash-trafikken havner i dette området. Dette nivået dekker eldre kabeltilkoblinger, 4G LTE under gjennomsnittlige signalforhold (typiske 4G-hastigheter i den virkelige verden ligger mellom 10 og 50 Mbps), og noen brukere av trådløst bredbånd. Et heltebilde på 300 KB tar mellom 48 og 240 millisekunder i overføringstid med disse hastighetene. Sider med uoptimaliserte bilder eller flere gjengivelsesblokkerende ressurser vil begynne å feile LCP-terskler i dette nivået. Dette er nivået der valg av bildeformat (WebP, AVIF) og aggressiv forhåndsinnlasting med fetchpriority="high" utgjør en målbar forskjell.

Treg og mobil: Under 10 Mbps

Omtrent 25 % av CoreDash-trafikken kommer fra tilkoblinger under 10 Mbps. Dette inkluderer 3G-mobilbrukere, faste tilkoblinger i distriktene, og 4G-brukere med dårlig signal eller i nettverk med mye trafikk. Ved 5 Mbps tar et bilde på 400 KB over 640 millisekunder i overføringstid. LCP-feil i dette nivået er nesten sikre med mindre LCP-bildet har blitt aggressivt komprimert, servert via en CDN-kantnode nær brukeren, og forhåndslastet riktig. Hvis virksomheten din betjener brukere i regioner med historisk tregere infrastruktur, kan du sjekke CoreDash Country-dimensjonen sammen med dl for å bekrefte om treg trafikk konsentreres geografisk.

Arbeidsflyt for feilsøking

1. Filtrer til nivået under 10 Mbps i CoreDash og sjekk LCP Load Time. Hvis LCP Load Time er den dominerende bidragsyteren til en feilende LCP-poengsum, er LCP-ressursen for stor for trege tilkoblinger. Komprimer bildet ytterligere, bytt til AVIF-format, og bekreft at ressursen serveres fra et CDN med en nærliggende kantnode for de berørte brukerne.
2. Kryssreferer med Country-dimensjonen. Hvis trege brukere er konsentrert i spesifikke land, sjekk om din CDN har god dekning i disse regionene. En bruker på en 15 Mbps-tilkobling som betjenes av en CDN-kantnode 200 ms unna, vil ha en mye dårligere opplevelse enn en bruker med samme hastighet som betjenes av en node 10 ms unna.
3. Sjekk INP- og TTFB-poengsummer på tvers av nivåer. Hvis INP forverres ved lave båndbreddenivåer, men ikke ved høye, lastes fortsatt store JavaScript-pakker ned når brukerne først samhandler. Del opp din JavaScript, utsett (defer) ikke-kritiske skript, og vurder å yield til hovedtråden under initialisering for å redusere INP-eksponering i analysefasen.

Tommelfingerregel for utviklere

• Sikt på en LCP-bildefilstørrelse under 100 KB (AVIF eller WebP) for å holde LCP Load Time under 200 ms, selv på 5 Mbps-tilkoblinger.
• Total sidevekt for ressurser over folden bør holde seg under 500 KB for å gi en rimelig LCP på 10 Mbps-tilkoblinger innenfor terskelen på 2,5 sekunder.
• Bruk fetchpriority="high" på LCP-bildet og forhåndslast det i dokumentets <head> slik at nettleseren ikke kaster bort båndbredde på lavere prioriterte ressurser først.
• Server alle statiske ressurser fra et CDN. Båndbreddetallene i CoreDash måler klientens tilkobling, ikke serverens. En rask klienttilkobling hjelper ikke hvis serveren er geografisk langt unna og legger til 300 ms i forsinkelse før den første byten ankommer.
• Hvis mer enn 15 % av trafikken din er i nivået under 10 Mbps, og LCP feiler for disse brukerne, bør du behandle bildeoptimalisering og CDN-dekning som P1-problemer før du tar tak i noe annet.