Core/Dash Dimension: Netværkshastighed

Dimension: Netværkshastighed (dl)

dl-dimensionen rapporterer den effektive download-båndbredde for hver brugers forbindelse på tidspunktet for sidebesøget, målt i megabit i sekundet (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ærkskarakteristika, der har betydning for sidens indlæsningshastighed. Den anden er latenstid, som styrer round-trip-tiden til serveren. CoreDashs dl-dimension isolerer båndbreddevariablen, så du kan besvare et konkret spørgsmål: Forringes dine Core Web Vitals-scores i takt med at forbindelseshastigheden falder, og med hvor meget?

Hvorfor netværkshastighed er vigtig for Core Web Vitals

Download-bå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 hero-billede på 400 KB med en overførselstid på cirka 32 millisekunder. På en 5 Mbps-forbindelse tager det samme billede over 640 millisekunder alene i overførselstid, før der tages højde for latenstid eller processeringsoverhead. Den forskel alene kan skubbe en bestået LCP-score over i "kræver forbedring"-området.

Time to First Byte er mindre følsom over for båndbredde. TTFB domineres af serverens processeringstid og netværkets round-trip latenstid, ikke mængden af overførte bytes. Et langsomt serversvar er langsomt på enhver forbindelseshastighed. Hvis TTFB er dårlig på tværs af alle båndbreddeniveauer i CoreDash, peger det på server- eller CDN-problemer frem for et båndbreddeproblem på klientsiden.

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 main thread medfører dårlige INP-scores. En langsom forbindelse kan forsinke den indledende download af JavaScript-bundles, hvilket indirekte kan forværre INP, hvis scripts stadig parses, når brugeren interagerer med siden for første gang. Men når scripts først er indlæst, bestemmes INP-ydeevnen af enhedens processorkraft, ikke netværket.

I praksis kommer båndbreddeproblemer tydeligt til udtryk i LCP Load Time, som er den del 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 websites opdeles i tre båndbreddeniveauer. At forstå, 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 inden for dette niveau. Dette inkluderer fiberforbindelser, kabelbredbånd og 5G-mobilbrugere med gode signalforhold. Den gennemsnitlige 5G-downloadhastighed i 2025 ligger omkring 184 Mbps, og gennemsnittet for fast bredbånd i USA har nået 214 Mbps. Det er usandsynligt, at brugere på dette niveau vil opleve netværksdrevne LCP-forsinkelser på veloptimerede sider. Hvis LCP-scoren er dårlig her, er problemet serverens svartid, render-blocking ressourcer eller forsinkelse i opdagelsen af LCP-elementet, og 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 den virkelige verden ligger mellem 10 og 50 Mbps) samt nogle fixed-wireless brugere. Et hero-billede på 300 KB tager mellem 48 og 240 millisekunder i overførselstid ved disse hastigheder. Sider med uoptimerede billeder eller flere render-blocking ressourcer vil begynde at fejle LCP-tærsklerne på dette niveau. Det er på dette niveau, at 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 med dårligt signal eller under overbelastede netværksforhold. Ved 5 Mbps tager et billede på 400 KB over 640 millisekunder i overførselstid. LCP-fejl på dette niveau er næsten sikre, medmindre LCP-billedet er blevet aggressivt komprimeret, serveres via en CDN-edge-node tæt på brugeren og pre-loades korrekt. Hvis din virksomhed betjener brugere i regioner med historisk langsommere infrastruktur, bør du tjekke CoreDashs lande-dimension (Country) sammen med dl for at bekræfte, om den langsomme trafik er koncentreret geografisk.

Workflow til debugging

1. Filtrer til niveauet under 10 Mbps i CoreDash, og tjek LCP Load Time. Hvis LCP Load Time er den dominerende årsag til en dumpet LCP-score, er LCP-ressourcen for stor til langsomme forbindelser. Komprimer billedet yderligere, skift til AVIF-formatet, og bekræft, at ressourcen serveres fra et CDN med en nærliggende edge-node til de berørte brugere.
2. Krydsreferér med lande-dimensionen. Hvis langsomme brugere er koncentreret i specifikke lande, skal du tjekke, 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 user experience end en bruger med 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, er store JavaScript-bundles stadig ved at downloade, når brugerne interagerer første gang. Opdel din JavaScript, udskyd ikke-kritiske scripts, og overvej at bruge yielding til main thread under initialiseringen for at reducere INP-eksponeringen under parse-fasen.

Tekniske tommelfingerregler

• 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 forblive under 500 KB for at give en rimelig LCP på 10 Mbps-forbindelser inden for tærsklen på 2,5 sekunder.
• Brug fetchpriority="high" på LCP-billedet og pre-load det i dokumentets <head>, så browseren ikke spilder båndbredde på ressourcer med lavere prioritet først.
• Servér 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 befinder sig på niveauet under 10 Mbps, og LCP fejler for disse brugere, skal du behandle billedoptimering og CDN-dækning som P1-problemer, før du tager fat på noget andet.