Core/Dash Dimension: Nätverkshastighet

Dimension: Nätverkshastighet (dl)

Dimensionen dl visar den effektiva nedladdningsbandbredden för varje användares anslutning vid tidpunkten för sidbesöket, mätt i megabit per sekund (Mbps). CoreDash hämtar värdet från webbläsarens Network Information API och grupperar besöken i bandbreddsnivåer. Varje rad i CoreDash-tabellen motsvarar ett specifikt hastighetsintervall. Det gör att du kan jämföra dina Core Web Vitals-resultat sida vid sida för användare med snabbt bredband, medelsnabba anslutningar och långsamma anslutningar eller mobilanslutningar.

Bandbredd är en av två nätverksegenskaper som avgör en sidas laddningsprestanda. Den andra är latens, som styr tur-och-retur-tiden till servern. CoreDashs dl-dimension isolerar bandbreddsvariabeln så att du kan besvara en konkret fråga: försämras dina Core Web Vitals-resultat när anslutningshastigheten sjunker, och i så fall hur mycket?

Varför nätverkshastighet spelar roll för Core Web Vitals

Nedladdningsbandbredd har en direkt och mätbar inverkan på Largest Contentful Paint. LCP triggas nästan alltid av en hero-bild, en stor bakgrundsbild eller ett tungt webbtypsnitt. På en 100 Mbps-anslutning tar det ungefär 32 millisekunder att överföra en hero-bild på 400 KB. På en 5 Mbps-anslutning tar samma bild över 640 millisekunder i enbart överföringstid, innan latens eller bearbetning räknas in. Den skillnaden kan i sig göra att ett godkänt LCP-resultat hamnar i kategorin ”behöver förbättras”.

Time to First Byte är mindre känsligt för bandbredd. TTFB domineras av serverns bearbetningstid och nätverkets tur-och-retur-latens, inte av mängden överförda byte. Ett långsamt serversvar är långsamt oavsett anslutningshastighet. Om TTFB är dåligt över alla bandbreddsnivåer i CoreDash tyder det på problem med servern eller CDN:et, snarare än ett bandbreddsproblem på klientsidan.

Interaction to Next Paint är nästan helt CPU-bundet. INP mäter tiden mellan användarinteraktion och nästa visuella uppdatering. Tung JavaScript-exekvering, long tasks och blockering av main thread ger dåliga INP-resultat. En långsam anslutning kan fördröja den första nedladdningen av JavaScript-bundles, vilket indirekt kan försämra INP om skripten fortfarande parsas när användaren interagerar med sidan för första gången. Men när skripten väl är laddade bestäms INP-prestandan av enhetens processorkraft, inte av nätverket.

I praktiken syns bandbreddsproblem tydligt i LCP-laddningstiden, den del av LCP som mäter hur lång tid webbläsaren ägnade åt att ladda ned LCP-resursen efter att den upptäcktes. CoreDash rapporterar LCP-laddningstid separat, vilket gör det enkelt att bekräfta om långsamma användare väntar på nätverket eller på något annat.

Tolka datan

Trafiken i CoreDash för typiska webbplatser fördelas på tre bandbreddsnivåer. Att förstå vad varje nivå innebär hjälper dig att prioritera åtgärder.

Snabbt bredband: 50 Mbps och uppåt

Ungefär 35 % av trafiken i CoreDash hamnar på denna nivå. Detta inkluderar fiberanslutningar, kabelbredband och 5G-mobilanvändare med god täckning. Den genomsnittliga nedladdningshastigheten för 5G under 2025 ligger runt 184 Mbps, och snittet för fast bredband i USA har nått 214 Mbps. Användare på denna nivå drabbas sällan av nätverksrelaterade LCP-fördröjningar på väloptimerade sidor. Om LCP-resultaten är dåliga här ligger problemet i serverns svarstid, render-blocking resurser eller fördröjd upptäckt av LCP-elementet – inte i bandbredden.

Medelsnabb hastighet: 10 till 50 Mbps

Ungefär 40 % av trafiken i CoreDash hamnar i detta intervall. Denna nivå täcker äldre kabelanslutningar, 4G LTE under normala signalförhållanden (typiska verkliga 4G-hastigheter ligger mellan 10 och 50 Mbps) samt vissa användare med fast trådlös anslutning. En hero-bild på 300 KB tar mellan 48 och 240 millisekunder att överföra i dessa hastigheter. Sidor med ooptimerade bilder eller flera render-blocking resurser börjar missa gränsvärdena för LCP på den här nivån. Det är på den här nivån som valet av bildformat (WebP, AVIF) och aggressiv förhandsladdning med fetchpriority="high" gör mätbar skillnad.

Långsamt och mobilt: under 10 Mbps

Ungefär 25 % av trafiken i CoreDash kommer från anslutningar under 10 Mbps. Detta inkluderar 3G-mobilanvändare, fasta anslutningar på landsbygden och 4G-användare med dålig täckning eller i överbelastade nätverk. Vid 5 Mbps tar en bild på 400 KB över 640 millisekunder i överföringstid. LCP-missar på den här nivån är nästan garanterade om inte LCP-bilden har komprimerats aggressivt, levererats via en CDN-nod nära användaren och förhandsladdats korrekt. Om din verksamhet vänder sig till användare i regioner med historiskt sett långsammare infrastruktur bör du kontrollera Country-dimensionen i CoreDash tillsammans med dl för att se om den långsamma trafiken är koncentrerad geografiskt.

Debugging Workflow

1. Filtrera på nivån under 10 Mbps i CoreDash och kontrollera LCP-laddningstiden. Om LCP-laddningstiden är den dominerande orsaken till ett underkänt LCP-resultat är LCP-resursen för stor för långsamma anslutningar. Komprimera bilden ytterligare, byt till AVIF-format och bekräfta att resursen levereras från ett CDN med en nod nära de berörda användarna.
2. Korsreferera med Country-dimensionen. Om långsamma användare är koncentrerade till specifika länder bör du kontrollera om ditt CDN har bra täckning i dessa regioner. En användare med en 15 Mbps-anslutning som betjänas av en CDN-nod 200 ms bort får en betydligt sämre upplevelse än en användare med samma hastighet som betjänas av en nod 10 ms bort.
3. Kontrollera INP- och TTFB-resultaten över olika nivåer. Om INP blir sämre på låga bandbreddsnivåer men inte på höga hämtas fortfarande stora JavaScript-bundles när användarna interagerar för första gången. Dela upp din JavaScript, skjut upp icke-kritiska skript och överväg att yielda till main thread under initieringen för att minska INP-exponeringen under tolkningsfasen.

Tekniska tumregler

• Sikta på en filstorlek för LCP-bilden under 100 KB (AVIF eller WebP) för att hålla LCP-laddningstiden under 200 ms, även på 5 Mbps-anslutningar.
• Den totala sidvikten för resurser ovanför sidbrytningen bör ligga under 500 KB för att ge en rimlig LCP på 10 Mbps-anslutningar inom gränsen på 2,5 sekunder.
• Använd fetchpriority="high" på LCP-bilden och förhandsladda den i dokumentets <head> så att webbläsaren inte slösar bandbredd på resurser med lägre prioritet först.
• Leverera alla statiska resurser från ett CDN. Bandbreddssiffrorna i CoreDash mäter klientens anslutning, inte serverns. En snabb klientanslutning hjälper inte om servern är geografiskt avlägsen och lägger till 300 ms latens innan första byten anländer.
• Om mer än 15 % av din trafik ligger på nivån under 10 Mbps och LCP är underkänd för dessa användare bör du behandla bildoptimering och CDN-täckning som P1-problem innan du åtgärdar något annat.