Methodik · technische Transparenz

Wie wir deine Verbindung wirklich messen

Glaube einem Speedtest nicht einfach auf sein Wort. Hier erklären wir Schritt für Schritt, wie RealMbps funktioniert: Zielserver, adaptive Algorithmen, Perzentile, Fehlerbehandlung. Alles nachprüfbar, alles transparent.

1. Architektur

Der Test läuft vollständig in deinem Browser (Client-seitiges JavaScript) und fragt die globale Infrastruktur von Cloudflare ab:

• Latenz/Jitter: https://speed.cloudflare.com/__down?bytes=N mit kleinem N (1 KB), um minimale RTTs zu ermitteln
• Download: derselbe Endpunkt mit N variabel zwischen 1 MB und 50 MB
• Upload: https://speed.cloudflare.com/__up POST
• Geolokalisierung: https://speed.cloudflare.com/meta

Cloudflare wählt automatisch den PoP aus, der deiner IP am nächsten liegt (rund 300+ globale Rechenzentren). Es gibt keine „gefälligen" Server im Netz deines Anbieters, wie es bei anderen Tests der Fall ist.

2. Messung der Latenz (Ping) und des Jitters

Wir führen 12 aufeinanderfolgende Messungen eines 1-KB-Downloads durch. Für jede berechnen wir die Round-Trip-Time (RTT). Dann:

• Ping = Median der 12 Werte (schließt Ausreißer aus)
• Jitter = mittlere absolute Abweichung vom Median

Warum der Median und nicht der Mittelwert? Der Mittelwert ist anfällig für Ausreißer (ein einzelner verlorener Paket kann ihn aufblähen). Der Median spiegelt die „typische" Latenz wider, die du im normalen Betrieb erlebst.

3. Messung des Downloads

Wir stellen Anfragen mit zunehmender Größe (1, 2, 5, 10, 25, 50 MB), bis genügend Stichproben vorliegen. Für jede Anfrage:

1. Messen wir die Übertragungszeit mit performance.now()
2. Berechnen wir den Durchsatz in Mbit/s = (Bytes × 8) / (Sekunden × 1.000.000)
3. Fügen wir den Wert der Stichprobenliste hinzu

Die Endabschätzung ist das 90. Perzentil der zweiten Hälfte der Stichproben. Übersetzt: Wir verwerfen die Anfangsphase (TCP Slow-Start, in der die Geschwindigkeit künstlich niedrig ist) und nehmen den „stabilen" Wert im Regelbetrieb, wobei nur die anomalen Spitzen oberhalb des 90. Perzentils ausgeschlossen werden.

4. Messung des Uploads (mit adaptivem Algorithmus)

Der Upload ist der heikelste Teil, besonders im Mobilfunknetz. Unser Ansatz:

• Adaptive Chunks: Wir starten mit kleinen Blöcken (256 KB) und verdoppeln sie, wenn das Netz mithält. In schnellen Netzen (FTTH) gehen wir bis zu 8 MB; im langsamen Mobilfunk (5 Mbit/s real) bleiben wir bei 256-512 KB, nehmen aber viele Stichproben.
• Parallele Worker: 3 parallele Verbindungen auf Desktop, 1 auf Mobilgeräten (unter 720 px), um den Upload nicht mit unnötiger Nebenläufigkeit zu überlasten.
• Timeout pro Anfrage: Jeder POST hat einen AbortController, der ihn nach 3 Sekunden (oder der verbleibenden Zeit) beendet. Ein kurzer Aussetzer im Mobilfunk blockiert den Test nicht.
• Fehlertoleranz: Bis zu 8 transiente Fehler werden mit Backoff und automatischer Reduktion der Chunk-Größe akzeptiert.
• Endabschätzung: 75. Perzentil der zweiten Hälfte der Stichproben (konservativer als der Download, weil der Upload naturgemäß rauschanfälliger ist).

5. Was die Ergebnisse beeinflusst

Selbst mit der besten Methodik liegen einige Faktoren außerhalb unserer Kontrolle und beeinflussen die Messung:

• WLAN: Bei FTTH 1 Gbit/s übersteigt heimisches WLAN in der Praxis selten 400-600 Mbit/s. Um die Leitung selbst zu messen, nutze ein Ethernet-Kabel.
• Hardware: Alte PCs mit 802.11n-WLAN überschreiten praktisch keine 150 Mbit/s. Einsteiger-Smartphones limitieren ähnlich.
• Aktive VPN: fügt einen Zwischenhop hinzu, reduziert die Geschwindigkeit und erhöht den Ping.
• Andere Aktivitäten im Haus: TV-Streaming, Smart Speaker, Kameras verbrauchen still und leise Bandbreite.
• Veraltete Browser: Schlechte HTTP/2-Umsetzung senkt den Durchsatz.
• Netzauslastung des Anbieters: Zwischen 21-23 Uhr (abendliche Hauptzeit) kann die reale Geschwindigkeit um 20-30 % sinken.

6. Typische Fehlerbereiche

Im Vergleich mit offiziellen Messwerkzeugen (z. B. Bundesnetzagentur / breitbandmessung.de in Deutschland, Ne.Me.Sys von AGCOM in Italien) liegen die typischen Fehler bei:

• Download: ±5 % unter kontrollierten Bedingungen (Ethernet-Kabel, keine anderen Aktivitäten)
• Upload: ±10 % (naturgemäß variabler)
• Ping: ±2 ms
• Jitter: ±1 ms

Für den persönlichen und diagnostischen Gebrauch ist RealMbps völlig ausreichend. Für den rechtlichen Gebrauch (förmliche Beschwerde beim Anbieter mit Beweiswert) ist ein von der nationalen Regulierungsbehörde anerkanntes Messwerkzeug erforderlich: In Deutschland ist das die Desktop-App der Bundesnetzagentur (breitbandmessung.de). Siehe dazu unsere lokalen Ratgeber unter richtig messen.

7. Transparenz und Quellcode

Der Algorithmus ist vollständig in JavaScript, das vom Browser geladen wird. Du kannst ihn einsehen mit:

• F12 (DevTools) → Tab „Sources" → Datei script.js
• Suche nach den Funktionen measureLatency(), measureDownload(), measureUpload()

Keine Verschleierung, kein versteckter Code. Was du siehst, ist das, was wir messen.

8. Unterschiede zu anderen Speedtests

Was RealMbps von Speedtest by Ookla, Fast.com etc. unterscheidet:

• Neutrale Cloudflare-Server, keine vom Anbieter kontrollierten Server (Speedtest.net nutzt häufig anbietereigene Server)
• Privacy first: keine Tracking-Cookies, keine IP-Erfassung, kein Datenverkauf
• Adaptiver Algorithmus für Mobilgeräte: Wir liefern eine messbare Upload-Rate auch im langsamen 4G/5G (Speedtest.net scheitert oder unterschätzt oft mobil)
• Open Methodology: auf dieser Seite dokumentiert und in DevTools nachprüfbar
• Community-Wall: öffentliche Bestenliste zur Gamification und zum Vergleich mit anderen Nutzern deines Landes