Waarom een broncode voor een internetsnelheidstest afwijkende resultaten geeft

Wat betekent een afwijkende meting?

Een internetsnelheidstest meet de prestaties tussen jouw apparaat en een specifieke testserver. De uitkomst hoeft daarom niet gelijk te zijn aan de maximale snelheid van je abonnement. Vooral bij een zelfgebouwde test op basis van broncode kunnen de meetmethode, de browser en de server een grote invloed hebben. Een lagere download- of uploadsnelheid betekent dus niet automatisch dat er een storing bij de ISP of operator is.

Vergelijk steeds meerdere metingen onder dezelfde omstandigheden. Noteer de gebruikte verbinding, het tijdstip, de testserver en of de meting via ethernet of Wi-Fi is uitgevoerd.

Oorzaak 1: de testserver heeft onvoldoende capaciteit

Een testserver die ver weg staat of veel gelijktijdige gebruikers verwerkt, kan de gemeten snelheid beperken. Dit is vooral zichtbaar bij glasvezel- en kabelverbindingen met hoge downloadsnelheden. De internetverbinding kan technisch sneller zijn dan de server of de route naar die server aankan.

Zo controleer je dit

Voer dezelfde test uit tegen meerdere servers in Nederland of een nabijgelegen regio. Als de resultaten sterk verschillen per server, ligt de oorzaak waarschijnlijk bij servercapaciteit, peering of netwerkroute en niet direct bij je modem of abonnement.

Oorzaak 2: de broncode gebruikt te weinig gelijktijdige verbindingen

Een eenvoudige test die één groot bestand sequentieel downloadt, benut een snelle verbinding soms niet volledig. TCP heeft tijd nodig om de overdracht op te bouwen en de beschikbare bandbreedte te vullen. Bij een korte test blijft de gemeten snelheid daardoor te laag.

Gebruik voor de downloadtest meerdere gelijktijdige streams en verdeel de totale hoeveelheid data over die verbindingen. Voor uploads geldt hetzelfde, maar controleer ook of de server meerdere gelijktijdige uploads accepteert. Beperk het aantal streams wel, omdat te veel verbindingen de browser of server onnodig kunnen belasten.

Oorzaak 3: de browser of JavaScript-code vormt de bottleneck

Een browsergebaseerde snelheidstest deelt netwerkverkeer, verwerking en opslag met andere tabbladen en processen. JavaScript kan bovendien vertraging veroorzaken wanneer de code grote hoeveelheden data op de hoofdthread verwerkt. Op oudere laptops, mobiele apparaten of energiezuinige systemen kan de processor de meting begrenzen voordat de internetverbinding dat doet.

Gebruik eenvoudige buffers, vermijd onnodige verwerking tijdens de meting en voer de test uit zonder zware webapps op de achtergrond. Meet ook in een tweede browser. Een duidelijk verschil tussen browsers wijst eerder op de implementatie of het apparaat dan op de lijn zelf.

Oorzaak 4: Wi-Fi veroorzaakt verlies en wisselende snelheid

Wi-Fi wordt beïnvloed door afstand, muren, naburige netwerken en andere apparaten. De verbinding kan daardoor tijdelijk terugschakelen naar een lagere modulatie. Dit leidt niet alleen tot minder download- en uploadsnelheid, maar ook tot hogere latency, jitter en pakketverlies.

Voer eerst een meting uit met een netwerkkabel rechtstreeks op de router of het modem. Is de snelheid via ethernet duidelijk hoger, test dan Wi-Fi op korte afstand, bij voorkeur op een geschikt 5 GHz- of 6 GHz-netwerk. Controleer ook of de router automatisch van kanaal wisselt of veel apparaten tegelijk bedient.

Oorzaak 5: modem, router of lokaal netwerk is overbelast

Een modem of router kan tijdens de test bezig zijn met andere downloads, cloudback-ups, videostreams of firmwaretaken. Ook functies zoals QoS, ouderlijk toezicht, VPN-verwerking en beveiligingsfilters kunnen de beschikbare capaciteit beperken. Bij oudere apparatuur ontstaat soms vooral hoge latency tijdens een grote download.

Stop tijdelijk ander verkeer en herstart het modem of de router volgens de instructies van de operator. Controleer in de beheeromgeving of er veel actieve clients zijn. Als bekabelde metingen structureel laag blijven terwijl het lokale netwerk rustig is, vergelijk dan de resultaten met een tweede apparaat.

Oorzaak 6: de meetdata of timing in de broncode klopt niet

Een onjuiste berekening kan een betrouwbare netwerkmeting alsnog verkeerd weergeven. Veelvoorkomende fouten zijn het verwarren van bits en bytes, het meten van bestandsgrootte in plaats van werkelijk ontvangen data, het afronden van een te korte test en het gebruiken van lokale tijdstempels met onvoldoende resolutie.

Reken snelheid om naar megabits per seconde door het aantal ontvangen bytes met acht te vermenigvuldigen en door de verstreken tijd in seconden te delen. Gebruik een monotone klok voor tijdmetingen en laat de test lang genoeg lopen om korte schommelingen uit te middelen. Meet download en upload afzonderlijk en sluit de meting pas af nadat alle datastromen werkelijk zijn beëindigd.

Oorzaak 7: latency, jitter en pakketverlies worden niet goed gemeten

Een snelheidstest die alleen doorvoersnelheid toont, kan een instabiele verbinding onopgemerkt laten. Hoge latency vertraagt de eerste reactie, jitter veroorzaakt variatie tussen pakketten en pakketverlies leidt tot opnieuw verzenden. Daardoor kan een korte downloadtest redelijk lijken terwijl videobellen, online gamen of werken via een VPN toch problemen geeft.

Voeg afzonderlijke metingen toe voor ping, jitter en pakketverlies. Gebruik meerdere verzoeken naar dezelfde server en rapporteer naast het gemiddelde ook de spreiding en het percentage verloren pakketten. Een enkele hoge ping is minder belangrijk dan een patroon dat tijdens belasting terugkeert.

Hoe controleer je de meting stap voor stap?

1. Sluit onnodige downloads, uploads, VPN-verbindingen en streamingdiensten.
2. Verbind het testapparaat met een ethernetkabel en noteer de gebruikte netwerkadapter.
3. Test meerdere servers die geografisch dichtbij liggen.
4. Gebruik voldoende testduur en meerdere gelijktijdige datastromen.
5. Herhaal de meting op verschillende tijdstippen, bijvoorbeeld overdag en in de avond.
6. Vergelijk de resultaten met een tweede apparaat en met een bekende betrouwbare snelheidstest.
7. Noteer download, upload, latency, jitter en pakketverlies afzonderlijk.

Welke optimalisaties helpen?

• Voor de broncode: gebruik meerdere gecontroleerde streams, een monotone timer, correcte bit- en byteconversie en een duidelijke testduur.
• Voor de server: plaats testbestanden en upload-endpoints op een krachtige server met voldoende bandbreedte en kies een serverlocatie dicht bij de gebruiker.
• Voor het apparaat: sluit zware processen en test met een actuele browser en netwerkdriver.
• Voor Wi-Fi: verklein de afstand tot de router, beperk storingsbronnen en kies een geschikt kanaal of een bekabelde verbinding.
• Voor de router: controleer firmware, actieve apparaten en functies die verkeer inspecteren of prioriteren.

Wanneer ligt het probleem waarschijnlijk bij de provider?

Neem contact op met je ISP of operator wanneer meerdere apparaten via ethernet op verschillende momenten duidelijk onder de verwachte prestaties blijven. Vermeld daarbij het type aansluiting, zoals glasvezel, kabel of DSL, de testserver, het tijdstip en de gemeten download- en uploadsnelheid. Voeg ook informatie toe over latency, jitter en pakketverlies.

Een provider kan vervolgens de lijn, het modemsignaal, congestie en de aansluiting naar het thuisnetwerk controleren. Gebruik geen enkele meting als definitief bewijs: een reeks consistente resultaten onder gecontroleerde omstandigheden is veel waardevoller.