Core/Dash Dimensie: Netwerksnelheid

Dimensie: Netwerksnelheid (dl)

De dl dimensie rapporteert de effectieve downloadbandbreedte van de verbinding van elke gebruiker op het moment van het paginabezoek, gemeten in Megabits per seconde (Mbps). CoreDash verzamelt deze waarde via de Network Information API van de browser en groepeert bezoeken in bandbreedtecategorieën. Elke rij in de CoreDash-tabel vertegenwoordigt een specifieke snelheidscategorie, zodat je jouw Core Web Vitals-scores van gebruikers met snel breedband, matige verbindingen en trage of mobiele verbindingen naast elkaar kunt vergelijken.

Bandbreedte is een van de twee netwerkeigenschappen die de prestaties van de paginalading bepalen. De andere is latentie, die de round-trip tijd naar de server regelt. De dl dimensie van CoreDash isoleert de bandbreedtevariabele, zodat je een concrete vraag kunt beantwoorden: verslechteren je Core Web Vitals-scores naarmate de verbindingssnelheid daalt, en met hoeveel?

Waarom netwerksnelheid belangrijk is voor Core Web Vitals

Downloadbandbreedte heeft een directe en meetbare impact op de Largest Contentful Paint. LCP wordt bijna altijd geactiveerd door een hero-afbeelding, een grote achtergrondafbeelding of een zwaar weblettertype. Op een verbinding van 100 Mbps arriveert een hero-afbeelding van 400 KB in ongeveer 32 milliseconden overdrachtstijd. Op een verbinding van 5 Mbps neemt diezelfde afbeelding alleen al voor de overdracht meer dan 640 milliseconden in beslag, nog voordat er rekening is gehouden met eventuele latentie of verwerkingsoverhead. Dat verschil alleen al kan een voldoende LCP-score naar het bereik "needs improvement" pushen.

Time to First Byte is minder gevoelig voor bandbreedte. TTFB wordt gedomineerd door serververwerkingstijd en netwerk round-trip latentie, niet door de hoeveelheid overgedragen bytes. Een trage serverrespons is op elke verbindingssnelheid traag. Als TTFB in alle bandbreedtecategorieën in CoreDash slecht is, wijst dat op server- of CDN-problemen in plaats van op een bandbreedteprobleem aan de clientzijde.

Interaction to Next Paint is bijna volledig CPU-gebonden. INP meet de tijd tussen gebruikersinvoer en de volgende visuele update. Zware JavaScript-uitvoering, lange taken en blokkering van de main thread zorgen voor slechte INP-scores. Een trage verbinding kan de initiële download van JavaScript-bundels vertragen, wat indirect INP kan verslechteren als scripts nog aan het parsen zijn wanneer de gebruiker voor het eerst met de pagina interageert. Maar zodra de scripts geladen zijn, worden de INP-prestaties bepaald door de verwerkingskracht van het apparaat, niet door het netwerk.

In de praktijk komen bandbreedteproblemen duidelijk naar voren in de LCP Load Time, het subonderdeel van LCP dat meet hoe lang de browser bezig was met het downloaden van de LCP-resource nadat deze was ontdekt. CoreDash rapporteert de LCP Load Time afzonderlijk, waardoor je eenvoudig kunt bevestigen of trage gebruikers wachten op het netwerk of op iets anders.

De gegevens lezen

Het CoreDash-verkeer over typische sites kan worden onderverdeeld in drie bandbreedtecategorieën. Door te begrijpen wat elke categorie vertegenwoordigt, kun je beter prioriteit geven aan oplossingen.

Snel breedband: 50 Mbps en hoger

Ongeveer 35% van het CoreDash-verkeer valt in deze categorie. Dit omvat glasvezelverbindingen, kabelbreedband en mobiele 5G-gebruikers met goede signaalomstandigheden. Gemiddelde 5G-downloadsnelheden liggen in 2025 rond de 184 Mbps, en gemiddelden voor vast breedband in de VS hebben 214 Mbps bereikt. Gebruikers in deze categorie ervaren op goed geoptimaliseerde pagina's waarschijnlijk geen netwerkgestuurde LCP-vertragingen. Als de LCP-scores hier slecht zijn, ligt het probleem bij de reactietijd van de server, render-blocking resources of de ontdekkingsvertraging van het LCP-element, niet bij de bandbreedte.

Matige snelheid: 10 tot 50 Mbps

Ongeveer 40% van het CoreDash-verkeer landt in dit bereik. Deze categorie dekt oudere kabelverbindingen, 4G LTE in gemiddelde signaalomstandigheden (typische 4G praktijksnelheden liggen tussen 10 en 50 Mbps), en sommige vaste draadloze gebruikers. Een hero-afbeelding van 300 KB neemt bij deze snelheden tussen de 48 en 240 milliseconden overdrachtstijd in beslag. Pagina's met ongeoptimaliseerde afbeeldingen of meerdere render-blocking resources zullen in deze categorie beginnen te falen op LCP-drempelwaarden. Dit is de categorie waar keuzes in afbeeldingsformaten (WebP, AVIF) en agressief preloaden met fetchpriority="high" een meetbaar verschil maken.

Traag en mobiel: Onder 10 Mbps

Ongeveer 25% van het CoreDash-verkeer is afkomstig van verbindingen onder de 10 Mbps. Dit omvat mobiele 3G-gebruikers, landelijke vaste verbindingen en 4G-gebruikers in slechte signaalomstandigheden of op drukke netwerken. Bij 5 Mbps neemt een afbeelding van 400 KB meer dan 640 milliseconden aan overdrachtstijd in beslag. LCP-fouten zijn in deze categorie vrijwel zeker, tenzij de LCP-afbeelding agressief is gecomprimeerd, wordt geserveerd via een CDN edge node dicht bij de gebruiker, en correct is gepreload. Als je bedrijf gebruikers bedient in regio's met een historisch tragere infrastructuur, controleer dan de CoreDash Country-dimensie naast dl om te bevestigen of traag verkeer zich geografisch concentreert.

Debugging workflow

1. Filter op de categorie onder 10 Mbps in CoreDash en controleer de LCP Load Time. Als de LCP Load Time de grootste bijdrage levert aan een falende LCP-score, is de LCP-resource te groot voor trage verbindingen. Comprimeer de afbeelding verder, schakel over naar het AVIF-formaat en bevestig dat de resource wordt geserveerd vanaf een CDN met een nabijgelegen edge node voor de getroffen gebruikers.
2. Vergelijk met de Country-dimensie. Als trage gebruikers zich in specifieke landen concentreren, controleer dan of je CDN een goede dekking heeft in die regio's. Een gebruiker op een 15 Mbps-verbinding die wordt geserveerd door een CDN edge node op 200 ms afstand, zal een veel slechtere ervaring hebben dan een gebruiker op dezelfde snelheid die wordt geserveerd door een node op 10 ms afstand.
3. Controleer de INP- en TTFB-scores over de categorieën heen. Als INP verslechtert bij lage bandbreedtecategorieën, maar niet bij hoge, zijn grote JavaScript-bundels nog aan het downloaden wanneer gebruikers voor het eerst interageren. Splits je JavaScript, stel niet-kritieke scripts uit en overweeg yielding to the main thread tijdens de initialisatie om INP-blootstelling tijdens de parse-fase te verminderen.

Technische vuistregels

• Streef naar een bestandsgrootte van de LCP-afbeelding onder de 100 KB (AVIF of WebP) om de LCP Load Time onder de 200 ms te houden, zelfs op 5 Mbps-verbindingen.
• Het totale paginagewicht voor resources above-the-fold moet onder de 500 KB blijven om een redelijke LCP te garanderen op 10 Mbps-verbindingen binnen de drempel van 2.5 seconden.
• Gebruik fetchpriority="high" op de LCP-afbeelding en preload deze in de <head> van het document, zodat de browser geen bandbreedte verspilt aan resources met een lagere prioriteit.
• Serveer alle statische assets vanaf een CDN. Bandbreedtecijfers in CoreDash meten de verbinding van de client, niet die van de server. Een snelle clientverbinding helpt niet als de server zich geografisch ver weg bevindt en 300 ms latentie toevoegt voordat de eerste byte arriveert.
• Als meer dan 15% van je verkeer zich in de categorie onder 10 Mbps bevindt en LCP voor die gebruikers faalt, behandel dan afbeeldingsoptimalisatie en CDN-dekking als P1-problemen voordat je iets anders aanpakt.