Core/Dash-dimensjon: Nettverkshastighet

Dimensjon: Nettverkshastighet (dl)

Dimensjonen dl 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 dine Core Web Vitals-poengsummer på tvers av brukere med raskt bredbånd, tilkoblinger med middels hastighet og trege eller mobile tilkoblinger side om side.

Båndbredde er en av to nettverksegenskaper som former ytelsen for sideinnlasting. Den andre er forsinkelse (latency), som styrer rundreisetiden til serveren. CoreDashs dl-dimensjon isolerer båndbreddevariabelen slik at du kan svare på et konkret spørsmål: forverres dine Core Web Vitals-poengsummer når 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 hovedbilde (hero image), et stort bakgrunnsbilde eller en tung webfont. På en 100 Mbps-tilkobling ankommer et hovedbilde på 400 KB i løpet av omtrent 32 millisekunder med overføringstid. På en 5 Mbps-tilkobling tar det samme bildet over 640 millisekunder i overføringstid alene, før man tar høyde for eventuell forsinkelse eller prosesseringsforsinkelse. Den forskjellen alene kan skyve en godkjent LCP-poengsum ned i kategorien "trenger forbedring" (needs improvement).

Time to First Byte er mindre følsom for båndbredde. TTFB domineres av serverens behandlingstid og nettverkets rundreiseforsinkelse, ikke mengden bytes som overføres. 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 i stedet for et båndbreddeproblem på klientsiden.

Interaction to Next Paint er nesten utelukkende prosessorbundet (CPU-bound). INP måler tiden mellom brukerinndata og neste visuelle oppdatering. Tung JavaScript-kjøring, lange oppgaver (long tasks) og blokkering av hovedtråden fører til dårlige INP-poengsummer. En treg tilkobling kan forsinke den innledende nedlastingen av JavaScript-pakker (bundles), noe som indirekte kan forverre INP hvis skriptene fremdeles analyseres (parsing) når brukeren først samhandler med siden. Men når skriptene er lastet inn, bestemmes INP-ytelsen av enhetens prosesseringskraft, ikke nettverket.

I praksis kommer båndbreddeproblemer tydelig frem i LCP Load Time, den underordnede delen 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 høyere

Omtrent 35 % av CoreDash-trafikken faller inn i dette nivået. Dette inkluderer fibertilkoblinger, kabelbredbånd og 5G-mobilbrukere med gode signalforhold. Gjennomsnittlig 5G-nedlastingshastighet i 2025 ligger på rundt 184 Mbps, og gjennomsnittet for fast bredbånd i USA har nådd 214 Mbps. Brukere på dette nivået vil neppe oppleve nettverksdrevne LCP-forsinkelser på godt optimaliserte sider. Hvis LCP-poengsummene er dårlige her, er problemet serverresponstid, gjengivelsesblokkerende ressurser (render-blocking resources), eller forsinkelse i oppdagelsen av LCP-elementet, ikke båndbredde.

Middels 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 med fast trådløst bredbånd. Et hovedbilde på 300 KB tar mellom 48 og 240 millisekunder i overføringstid ved 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" gjør en målbar forskjell.

Tregt og mobilt: Under 10 Mbps

Omtrent 25 % av CoreDash-trafikken kommer fra tilkoblinger under 10 Mbps. Dette inkluderer 3G-mobilbrukere, faste tilkoblinger i rurale strøk, og 4G-brukere med dårlig signal eller overbelastede nettverksforhold. Ved 5 Mbps tar et bilde på 400 KB over 640 millisekunder i overføringstid. LCP-feil på dette nivået er nesten uunngåelige med mindre LCP-bildet har blitt aggressivt komprimert, levert via en CDN edge-node i nærheten av brukeren, og forhåndslastet riktig. Hvis virksomheten din betjener brukere i regioner med historisk tregere infrastruktur, sjekk CoreDash-dimensjonen for land (Country) sammen med dl for å bekrefte om trafikk med lav hastighet er geografisk konsentrert.

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 årsaken til en underkjent LCP-poengsum, er LCP-ressursen for stor for trege tilkoblinger. Komprimer bildet ytterligere, bytt til AVIF-format, og bekreft at ressursen leveres fra et CDN med en nærliggende edge-node til de berørte brukerne.
2. Kryssreferér med land-dimensjonen (Country). Hvis brukere med lav hastighet 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 edge-node 200 ms unna, vil få en langt dårligere opplevelse enn en bruker på samme hastighet som betjenes av en node 10 ms unna.
3. Sjekk INP- og TTFB-poengsummene på tvers av nivåer. Hvis INP forverres på lave båndbreddenivåer, men ikke på høye, lastes store JavaScript-pakker fremdeles ned når brukere først samhandler. Del opp din JavaScript, utsett (defer) ikke-kritiske skript, og vurder å yield to the main thread under initialisering for å redusere INP-eksponeringen under analysefasen (parse phase).

Tekniske tommelfingerregler

• 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 "above the fold" (over bretten) bør holdes 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å ressurser med lavere prioritet først.
• Lever alle statiske ressurser (assets) fra et CDN. Båndbreddetall i CoreDash måler klientens tilkobling, ikke serverens. En rask klienttilkobling hjelper ikke hvis serveren er geografisk langt unna og legger til 300 ms forsinkelse før den første byten ankommer.
• Hvis mer enn 15 % av trafikken din er på nivået under 10 Mbps og LCP feiler for disse brukerne, bør bildeoptimalisering og CDN-dekning behandles som P1-problemer (høyeste prioritet) før noe annet tas tak i.