Core/Dash Dimension: Network Speed

Dimension: Network Speed (dl)

dl-dimensionen rapporterer den effektive downloadbåndbredde for hver brugers forbindelse på tidspunktet for sidebesøget, målt i Megabits per sekund (Mbps). CoreDash indsamler denne værdi fra browserens Network Information API og grupperer besøg i båndbreddeniveauer. Hver række i CoreDash-tabellen repræsenterer en specifik hastighedskategori, så du kan sammenligne dine Core Web Vitals-scores på tværs af hurtige bredbåndsbrugere, forbindelser med moderat hastighed og langsomme eller mobile forbindelser side om side.

Båndbredde er en af to netværkskarakteristikker, der former sideindlæsningsydelsen. Den anden er latenstid, som styrer rundrejsetiden til serveren. CoreDash' dl-dimension isolerer båndbreddevariablen, så du kan besvare et konkret spørgsmål: forringes dine Core Web Vitals-scores, når forbindelseshastigheden falder, og med hvor meget?

Hvorfor Network Speed er vigtig for Core Web Vitals

Downloadbåndbredde har en direkte og målbar indvirkning på Largest Contentful Paint. LCP udløses næsten altid af et hero-billede, et stort baggrundsbillede eller en tung webfont. På en 100 Mbps-forbindelse ankommer et 400 KB hero-billede på cirka 32 millisekunder i overførselstid. På en 5 Mbps-forbindelse tager det samme billede over 640 millisekunder i overførselstid alene, før man medregner latenstid eller behandlingsomkostninger. Denne forskel alene kan skubbe en bestået LCP-score ind i kategorien "skal forbedres".

Time to First Byte er mindre følsom over for båndbredde. TTFB domineres af serverbehandlingstid og netværkets rundrejselatenstid, ikke mængden af overførte bytes. En langsom serverrespons er langsom uanset forbindelseshastighed. Hvis TTFB er dårlig på tværs af alle båndbreddeniveauer i CoreDash, peger det på server- eller CDN-problemer snarere end et klient-side båndbreddeproblem.

Interaction to Next Paint er næsten udelukkende CPU-bundet. INP måler tiden mellem brugerinput og den næste visuelle opdatering. Tung JavaScript-eksekvering, lange opgaver og blokering af hovedtråden forårsager dårlige INP-scores. En langsom forbindelse kan forsinke den indledende download af JavaScript-bundler, hvilket indirekte kan forværre INP, hvis scripts stadig parses, når brugeren først interagerer med siden. Men når scripts er indlæst, bestemmes INP-ydelsen af enhedens processorkraft, ikke netværket.

I praksis viser båndbreddeproblemer sig tydeligt i LCP Load Time, den deldel af LCP der måler, hvor lang tid browseren brugte på at downloade LCP-ressourcen, efter den blev opdaget. CoreDash rapporterer LCP Load Time separat, hvilket gør det ligetil at bekræfte, om langsomme brugere venter på netværket eller på noget andet.

Aflæsning af data

CoreDash-trafik på tværs af typiske sites fordeler sig i tre båndbreddeniveauer. Forståelse af hvad hvert niveau repræsenterer, hjælper dig med at prioritere rettelser.

Hurtigt bredbånd: 50 Mbps og derover

Cirka 35% af CoreDash-trafikken falder i dette niveau. Dette inkluderer fiberforbindelser, kabelbredbånd og 5G-mobilbrugere under gode signalforhold. Gennemsnitlige 5G-downloadhastigheder i 2025 ligger omkring 184 Mbps, og gennemsnitlige faste bredbåndshastigheder i USA har nået 214 Mbps. Brugere i dette niveau oplever sandsynligvis ikke netværksdrevne LCP-forsinkelser på veloptimerede sider. Hvis LCP-scores er dårlige her, er problemet serverresponstid, render-blokkerende ressourcer eller forsinkelse i opdagelsen af LCP-elementet, ikke båndbredde.

Moderat hastighed: 10 til 50 Mbps

Cirka 40% af CoreDash-trafikken lander i dette interval. Dette niveau dækker ældre kabelforbindelser, 4G LTE under gennemsnitlige signalforhold (typiske 4G-hastigheder i virkeligheden ligger mellem 10 og 50 Mbps) og nogle fixed-wireless brugere. Et 300 KB hero-billede tager mellem 48 og 240 millisekunder i overførselstid ved disse hastigheder. Sider med uoptimerede billeder eller flere render-blokkerende ressourcer vil begynde at fejle LCP-tærskelværdier i dette niveau. Dette er niveauet, hvor valg af billedformat (WebP, AVIF) og aggressiv preloading med fetchpriority="high" gør en målbar forskel.

Langsom og mobil: Under 10 Mbps

Cirka 25% af CoreDash-trafikken kommer fra forbindelser under 10 Mbps. Dette inkluderer 3G-mobilbrugere, faste forbindelser i landdistrikter og 4G-brugere under dårlige signal- eller overbelastede netværksforhold. Ved 5 Mbps tager et 400 KB billede over 640 millisekunder i overførselstid. LCP-fejl i dette niveau er næsten sikre, medmindre LCP-billedet er komprimeret aggressivt, serveret via en CDN-edge node tæt på brugeren og preloadet korrekt. Hvis din virksomhed betjener brugere i regioner med historisk langsommere infrastruktur, tjek CoreDash Country-dimensionen sammen med dl for at bekræfte, om trafik med lav hastighed koncentrerer sig geografisk.

Fejlsøgningsworkflow

1. Filtrér til under-10 Mbps-niveauet i CoreDash og tjek LCP Load Time. Hvis LCP Load Time er den dominerende bidragyder til en fejlende LCP-score, er LCP-ressourcen for stor til langsomme forbindelser. Komprimer billedet yderligere, skift til AVIF-format, og bekræft at ressourcen serveres fra et CDN med en nærliggende edge node til de berørte brugere.
2. Krydsreferencér med Country-dimensionen. Hvis brugere med lav hastighed koncentrerer sig i specifikke lande, tjek om dit CDN har god dækning i disse regioner. En bruger på en 15 Mbps-forbindelse, der betjenes af en CDN-edge node 200 ms væk, vil have en langt dårligere oplevelse end en bruger på samme hastighed, der betjenes af en node 10 ms væk.
3. Tjek INP- og TTFB-scores på tværs af niveauer. Hvis INP forværres ved lave båndbreddeniveauer men ikke ved høje, downloades stadig store JavaScript-bundler, når brugerne først interagerer. Opdel dit JavaScript, udsæt ikke-kritiske scripts, og overvej at give kontrol til hovedtråden under initialisering for at reducere INP-eksponering under parsefasen.

Teknisk tommelfingerregel

• Sigt efter en LCP-billedfilstørrelse under 100 KB (AVIF eller WebP) for at holde LCP Load Time under 200 ms selv på 5 Mbps-forbindelser.
• Den samlede sidevægt for above-the-fold ressourcer bør holdes under 500 KB for at give en rimelig LCP på 10 Mbps-forbindelser inden for 2,5 sekunders tærsklen.
• Brug fetchpriority="high" på LCP-billedet og preload det i dokumentets <head>, så browseren ikke spilder båndbredde på lavere-prioritetsressourcer først.
• Server alle statiske aktiver fra et CDN. Båndbreddetal i CoreDash måler klientens forbindelse, ikke serverens. En hurtig klientforbindelse hjælper ikke, hvis serveren er geografisk fjern og tilføjer 300 ms latenstid, før den første byte ankommer.
• Hvis mere end 15% af din trafik er i under-10 Mbps-niveauet, og LCP fejler for disse brugere, behandl billedoptimering og CDN-dækning som P1-problemer, før du adresserer andet.