Core/Dash Dimension: Nätverkshastighet

Segmentera Core Web Vitals efter användarens nedladdningshastighet för att hitta vilka bandbreddsnivåer som skadar din LCP.

Dimension: Nätverkshastighet (dl)

Dimensionen dl rapporterar den effektiva nedladdningsbandbredden för varje användares anslutning vid tidpunkten för sidbesöket, mätt i megabit per sekund (Mbps). CoreDash samlar in detta värde från webbläsarens Network Information API och grupperar besök i bandbreddsnivåer. Varje rad i CoreDash-tabellen representerar en specifik hastighetsgrupp, så att du kan jämföra dina Core Web Vitals-poäng mellan användare av snabbt bredband, måttligt snabba anslutningar och långsamma eller mobila anslutningar sida vid sida.

Bandbredd är en av två nätverksegenskaper som formar sidans laddningsprestanda. Den andra är latens, som styr svarstiden (round-trip time) till servern. CoreDashs dimension dl isolerar bandbreddsvariabeln så att du kan svara på en konkret fråga: försämras dina Core Web Vitals-poäng 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 utlöses nästan alltid av en hjältebild (hero image), en stor bakgrundsbild eller ett tungt webbtypsnitt. På en anslutning på 100 Mbps anländer en hjältebild på 400 KB med en överföringstid på ungefär 32 millisekunder. På en anslutning på 5 Mbps tar samma bild över 640 millisekunder enbart i överföringstid, innan någon latens eller processkostnad (overhead) räknas in. Enbart denna skillnad kan knuffa ett godkänt LCP-resultat ner i intervallet "behöver förbättras".

Time to First Byte är mindre känsligt för bandbredd. TTFB domineras av serverns bearbetningstid och nätverkets svarstidslatens, 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 pekar det på server- eller CDN-problem snarare än ett bandbreddsproblem på klientsidan.

Interaction to Next Paint är nästan uteslutande CPU-bundet. INP mäter tiden mellan användarens inmatning och nästa visuella uppdatering. Tung JavaScript-exekvering, långa uppgifter och blockering av huvudtråden driver dåliga INP-poäng. En långsam anslutning kan fördröja den initiala nedladdningen av JavaScript-paket, vilket indirekt kan försämra INP om skripten fortfarande tolkas (parsing) när användaren först interagerar med sidan. Men när skripten väl är inlästa bestäms INP-prestandan av enhetens processorkraft, inte av nätverket.

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

Att läsa datan

CoreDash-trafik över typiska webbplatser fördelas i tre bandbreddsnivåer. Att förstå vad varje nivå representerar hjälper dig att prioritera åtgärder.

Snabbt bredband: 50 Mbps och över

Cirka 35 % av CoreDash-trafiken faller i denna nivå. Detta inkluderar fiberanslutningar, kabelbredband och 5G-mobilanvändare med goda signalförhållanden. Genomsnittliga 5G-nedladdningshastigheter år 2025 ligger runt 184 Mbps, och genomsnittet för fast bredband i USA har nått 214 Mbps. Det är osannolikt att användare i denna nivå upplever nätverksdrivna LCP-fördröjningar på väloptimerade sidor. Om LCP-poängen är dåliga här ligger problemet i serverns svarstid, renderingsblockerande resurser eller fördröjning i upptäckten av LCP-elementet, inte i bandbredden.

Måttlig hastighet: 10 till 50 Mbps

Cirka 40 % av CoreDash-trafiken landar i detta intervall. Denna nivå täcker äldre kabelanslutningar, 4G LTE i genomsnittliga signalförhållanden (typiska verkliga 4G-hastigheter ligger mellan 10 och 50 Mbps) och vissa användare med fast trådlös anslutning. En hjältebild på 300 KB tar mellan 48 och 240 millisekunder i överföringstid vid dessa hastigheter. Sidor med ooptimerade bilder eller flera renderingsblockerande resurser kommer att börja missa LCP-tröskelvärdena i denna nivå. Detta är nivån där val av bildformat (WebP, AVIF) och aggressiv förladdning (preloading) med fetchpriority="high" gör en mätbar skillnad.

Långsamt och mobilt: Under 10 Mbps

Cirka 25 % av CoreDash-trafiken kommer från anslutningar under 10 Mbps. Detta inkluderar 3G-mobilanvändare, fasta anslutningar på landsbygden och 4G-användare med dålig signal eller i överbelastade nätverk. Vid 5 Mbps tar en bild på 400 KB över 640 millisekunder enbart i överföringstid. LCP-misslyckanden i denna nivå är nästan säkra såvida inte LCP-bilden har komprimerats aggressivt, levererats via en CDN-nod nära användaren och förladdats korrekt. Om din verksamhet betjänar användare i regioner med historiskt långsammare infrastruktur, kontrollera CoreDashs dimension Land (Country) tillsammans med dl för att bekräfta om den långsamma trafiken koncentreras geografiskt.

Felsökningsarbetsflöde

1. Filtrera på nivån under 10 Mbps i CoreDash och kontrollera LCP Load Time. Om LCP Load Time är den dominerande orsaken till en underkänd LCP-poäng, är LCP-resursen för stor för långsamma anslutningar. Komprimera bilden ytterligare, byt till AVIF-format och bekräfta att resursen serveras från ett CDN med en edge-nod nära de berörda användarna.
2. Korsreferera med dimensionen Land (Country). Om användare med långsamma anslutningar koncentreras till specifika länder, kontrollera huruvida ditt CDN har god täckning i dessa regioner. En användare på en 15 Mbps-anslutning som betjänas av en CDN-edge-nod 200 ms bort kommer att ha en mycket sämre upplevelse än en användare med samma hastighet som betjänas av en nod 10 ms bort.
3. Kontrollera INP- och TTFB-poäng över olika nivåer. Om INP försämras vid låga bandbreddsnivåer men inte vid höga, laddas stora JavaScript-paket fortfarande ner när användarna interagerar för första gången. Dela upp ditt JavaScript, skjut upp (defer) icke-kritiska skript och överväg att lämna över kontrollen till huvudtråden (yield to main thread) under initialiseringen för att minska INP-exponeringen under tolkningsfasen.

   Tumregel för ingenjörer

   • Sikta på en LCP-bildfilstorlek under 100 KB (AVIF eller WebP) för att hålla LCP Load Time under 200 ms även på anslutningar med 5 Mbps.
   • Den totala sidvikten för resurser ovanför sidbrytningen (above-the-fold) bör hålla sig under 500 KB för att ge en rimlig LCP på 10 Mbps-anslutningar inom tröskelvärdet på 2,5 sekunder.
   • Använd fetchpriority="high" på LCP-bilden och förladda den i dokumentets <head> så att webbläsaren inte slösar bandbredd på lågprioriterade resurser först.
   • Servera alla statiska tillgångar 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 den första byten anländer.
   • Om mer än 15 % av din trafik befinner sig i nivån under 10 Mbps och LCP misslyckas för dessa användare, behandla bildoptimering och CDN-täckning som P1-problem innan du tar itu med något annat.
     [include]sidebarcoredash.html[\/include]