Core/Dash Dimensie: Netwerksnelheid (Network Speed)

Dimensie: Netwerksnelheid (dl)

De dimensie dl 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 snelheidsgroep, zodat u uw Core Web Vitals-scores van gebruikers met snel breedband, matig snelle verbindingen en trage of mobiele verbindingen naast elkaar kunt vergelijken.

Bandbreedte is een van de twee netwerkkenmerken die de prestaties van het laden van pagina's bepalen. De andere is latentie (latency), die de retourtijd (round-trip time) naar de server regelt. De dl-dimensie van CoreDash isoleert de bandbreedtevariabele, zodat u een concrete vraag kunt beantwoorden: verslechteren uw 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 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 komt een hero-afbeelding van 400 KB binnen in ongeveer 32 milliseconden overdrachtstijd. Op een verbinding van 5 Mbps neemt diezelfde afbeelding alleen al aan overdrachtstijd ruim 640 milliseconden in beslag, voordat er nog maar rekening is gehouden met latentie of verwerkingsoverhead. Dat verschil alleen al kan een voldoende LCP-score naar het bereik "verbetering nodig" duwen.

Time to First Byte is minder gevoelig voor bandbreedte. TTFB wordt gedomineerd door serververwerkingstijd en netwerkretourtijd (latency), niet door het volume van de overgedragen bytes. Een trage serverrespons is traag bij elke verbindingssnelheid. Als TTFB in alle bandbreedtecategorieën in CoreDash slecht is, wijst dit op problemen met de server of het CDN, in plaats van op een bandbreedteprobleem aan de clientzijde.

Interaction to Next Paint is vrijwel volledig CPU-gebonden. INP meet de tijd tussen de invoer van de gebruiker en de volgende visuele update. Zware JavaScript-uitvoering, lange taken (long tasks) en het blokkeren van de hoofdthread (main thread) zorgen voor slechte INP-scores. Een trage verbinding kan het initiële downloaden van JavaScript-bundels vertragen, wat de INP indirect kan verslechteren als scripts nog worden geparseerd wanneer de gebruiker voor het eerst met de pagina communiceert. Maar zodra scripts zijn geladen, worden de INP-prestaties bepaald door de verwerkingskracht van het apparaat, niet door het netwerk.

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

De gegevens lezen

CoreDash-verkeer op typische sites is onderverdeeld in drie bandbreedtecategorieën. Begrijpen wat elke categorie vertegenwoordigt, helpt u prioriteiten te stellen bij het oplossen van problemen.

Snel breedband: 50 Mbps en hoger

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

Matige snelheid: 10 tot 50 Mbps

Ongeveer 40% van het CoreDash-verkeer belandt in deze reeks. Deze categorie dekt oudere kabelverbindingen, 4G LTE onder gemiddelde signaalomstandigheden (typische 4G-snelheden in de praktijk liggen tussen 10 en 50 Mbps) en sommige gebruikers van vast draadloos internet. 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 renderblokkerende resources zullen in deze categorie de LCP-drempelwaarden niet meer halen. Dit is de categorie waarin keuzes voor afbeeldingsformaten (WebP, AVIF) en agressief preloading 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 3G-mobiele gebruikers, vaste verbindingen in landelijke gebieden en 4G-gebruikers met een slecht signaal of op overbelaste netwerken. Bij 5 Mbps neemt een afbeelding van 400 KB ruim 640 milliseconden overdrachtstijd in beslag. LCP-falingen in deze categorie zijn vrijwel zeker, tenzij de LCP-afbeelding agressief is gecomprimeerd, wordt aangeboden via een CDN edge-node dicht bij de gebruiker en correct wordt gepreload. Als uw bedrijf gebruikers bedient in regio's met een historisch tragere infrastructuur, controleer dan de CoreDash-dimensie Land (Country) in combinatie met dl om te bevestigen of langzaam verkeer zich geografisch concentreert.

Workflow voor foutopsporing

1. Filter op de categorie onder 10 Mbps in CoreDash en controleer de LCP Load Time. Als LCP Load Time de dominante oorzaak is van een onvoldoende 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 aangeboden vanaf een CDN met een edge-node in de buurt van de betreffende gebruikers.
2. Vergelijk dit met de dimensie Land (Country). Als gebruikers met lage snelheden zich in specifieke landen concentreren, controleer dan of uw CDN een goede dekking in die regio's heeft. Een gebruiker op een verbinding van 15 Mbps die wordt bediend door een CDN-edge-node op 200 ms afstand, zal een veel slechtere ervaring hebben dan een gebruiker met dezelfde snelheid die wordt bediend door een node op 10 ms afstand.
3. Controleer de INP- en TTFB-scores over alle categorieën heen. Als de INP verslechtert bij lage bandbreedtecategorieën maar niet bij hoge, worden grote JavaScript-bundels nog steeds gedownload wanneer gebruikers voor het eerst interactie hebben. Splits uw JavaScript op, stel niet-kritieke scripts uit (defer) en overweeg de controle terug te geven aan de hoofdthread (yielding) tijdens de initialisatie om INP-blootstelling tijdens de parseerfase te verminderen.

Vuistregel voor techniek

• Streef naar een bestandsgrootte van de LCP-afbeelding van minder dan 100 KB (AVIF of WebP) om de LCP Load Time onder de 200 ms te houden, zelfs op verbindingen van 5 Mbps.
• Het totale paginagewicht voor resources boven de vouw (above-the-fold) moet onder de 500 KB blijven om een redelijke LCP op 10 Mbps-verbindingen te garanderen binnen de drempelwaarde van 2,5 seconden.
• Gebruik fetchpriority="high" op de LCP-afbeelding en preload deze in de document-<head>, zodat de browser geen bandbreedte verspilt aan resources met een lagere prioriteit eerst.
• Bied alle statische assets aan via 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 op grote geografische afstand bevindt en 300 ms latentie toevoegt voordat de eerste byte arriveert.
• Als meer dan 15% van uw 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 u iets anders aanpakt.