So funktioniert der Speedmesser-Test
Du sollst nicht raten müssen, wie wir messen. Hier steht alles: welche Server wir nutzen, wie wir Werte berechnen, welche Toleranzen wir akzeptieren – und wo unsere Grenzen liegen.
1. Die Test-Infrastruktur
Speedmesser nutzt das Cloudflare Speed-Test-Backend (speed.cloudflare.com). Cloudflare betreibt eines der größten Backbone-Netze der Welt mit über 300 Rechenzentren – allein in Deutschland in Frankfurt, München, Hamburg, Düsseldorf und Berlin. Dein Browser verbindet sich automatisch mit dem geografisch nächsten Knoten (Anycast-Routing). Damit ist die Strecke zwischen dir und dem Test-Server in der Regel kürzer als 30 Millisekunden Round-Trip-Time.
Wir nutzen Cloudflare bewusst statt eigener Server, weil:
- Cloudflare-Knoten haben in der Regel 10 Gbit/s bis 100 Gbit/s pro Server – mehr, als selbst ein 1-Gbit/s-Glasfaseranschluss saturieren könnte.
- Die Server-Auslastung ist niedrig genug, dass kein Engpass auf der Server-Seite entsteht.
- Die Standorte sind nah an den großen Internet-Knoten DE-CIX (Frankfurt) und BCIX (Berlin), was realistische Werte für deutsche Nutzer liefert.
2. Wie Ping gemessen wird
Der Ping (Round-Trip-Time, RTT) ist die Zeit, die ein winziges Datenpaket vom Browser zum Server und zurück braucht. Speedmesser sendet 12 aufeinanderfolgende HEAD-Requests an den Cloudflare-Endpoint und misst die Zeit zwischen Anfrage-Start und vollständiger Antwort.
Auswertung:
- Die 2 höchsten und 2 niedrigsten Werte werden verworfen (Trimming gegen Ausreißer).
- Aus den verbleibenden 8 Werten bilden wir den arithmetischen Mittelwert – das ist dein angezeigter Ping.
- Die Standardabweichung dieser 8 Werte ist dein Jitter.
Genauigkeit: ± 2 ms bei Werten unter 50 ms, ± 5 ms darüber. Browser-Overhead durch fetch-API ist eingeplant.
3. Download-Messung
Für den Download öffnet Speedmesser vier parallele HTTPS-Verbindungen zum Cloudflare-Endpoint und lädt jeweils eine 100-MB-Datei. Parallelität ist essenziell, weil eine einzelne TCP-Verbindung mit klassischen Algorithmen (Cubic, BBR) eine moderne Glasfaserleitung nicht voll sättigt – TCP-Slow-Start und Receive-Window-Probleme verhindern das.
Der Test läuft 10 Sekunden. Während dieser Zeit:
- Wird alle 400 ms die aktuelle Übertragungsrate berechnet und angezeigt (die Gauge-Animation).
- Werden die ersten 1,5 Sekunden bei der Endauswertung nicht gezählt (Warm-up gegen TCP-Slow-Start).
- Das Endergebnis ist die Gesamtmenge übertragener Bytes geteilt durch die effektive Mess-Zeit.
Wir geben den Wert in Mbit/s aus (1 Mbit = 1.000.000 Bit, nicht 1.048.576 wie bei Mebibit). Das ist der Wert, den auch dein Provider in Verträgen angibt.
4. Upload-Messung
Der Upload funktioniert spiegelverkehrt: drei parallele POST-Requests senden je 5 MB Zufallsdaten an den Cloudflare-Endpoint. Die Mess-Dauer beträgt 8 Sekunden. Das gleiche Verfahren (Warm-up-Phase, Bytes pro Sekunde) wird angewendet.
Wichtig: Bei asymmetrischen Anschlüssen (DSL, Kabel) ist der Upload oft 5–10x niedriger als der Download. Das ist kein Fehler, sondern Eigenschaft der Anschlussart.
5. Paketverlust
Cloudflare's Speed-Test-API liefert keine direkten Paketverlust-Metriken. Wir schätzen den Verlust aus der Differenz zwischen erwarteter und tatsächlicher Datenmenge plus der Anzahl der TCP-Retransmits, soweit diese im Browser sichtbar sind. Die ausgegebene Zahl ist eine konservative Schätzung mit einer Genauigkeit von ± 1 Prozentpunkt.
6. Warum unsere Werte manchmal von anderen Speedtests abweichen
Wenn du parallel bei speedtest.net (Ookla), fast.com (Netflix) und Speedmesser misst, bekommst du nie identische Werte. Das hat strukturelle Gründe:
- Server-Standort: Ookla wählt den nächstgelegenen Server eines Partner-ISPs – oft sehr nah, dadurch optimistische Werte. Speedmesser nutzt Cloudflare-Anycast, das im Mittel realistischere Wege misst.
- Anzahl der TCP-Streams: Manche Tests öffnen 8 oder 16 parallele Verbindungen, was höhere Spitzenwerte liefert, aber die reale Nutzungssituation (1–4 Streams für einen Download/Stream) überzeichnet.
- Mess-Dauer: Kürzere Tests neigen zu höheren Werten, weil TCP-Slow-Start am Anfang die Leitung nicht ausreizt. Längere Tests sind realistischer.
- Datei-Typ: Komprimierte vs. unkomprimierte Daten ergeben Unterschiede, wenn der Provider Traffic-Shaping einsetzt.
Generell liefern Speedmesser-Werte etwas konservativere Zahlen als Ookla – ein realistisches Bild dessen, was du im Alltag spürst.
7. Was wir nicht messen (und warum)
- Buffer-Bloat: Latenz unter Last. Aussagekräftig, aber sehr umstritten in der Auswertung. Wir prüfen, ob wir das in einer späteren Version aufnehmen.
- DNS-Lookup-Zeit: Browser-abhängig und mit verschlüsseltem DNS (DoH) nicht zuverlässig messbar.
- Routing-Hops: Browser können kein traceroute. Dafür braucht es System-Tools.
8. Rechtliche Verwertbarkeit
Für eine rechtsgültige Anfechtung deines Internet-Vertrags nach § 57 TKG benötigst du die offizielle Breitbandmessung der Bundesnetzagentur (breitbandmessung.de). Das ist die einzige Methode, die als Beweismittel anerkannt wird – sie erfordert eine Desktop-App, mindestens 30 Messungen über zwei Tage, an drei unterschiedlichen Kalendertagen.
Speedmesser ist kein Ersatz dafür, sondern der schnelle Vortest: Wenn unsere Werte deutlich unter deiner Vertragsgeschwindigkeit liegen, ist es höchste Zeit für die offizielle BNetzA-Messung.
9. Datenschutz bei der Messung
Die Messung läuft komplett in deinem Browser. Wir haben keine eigene Datenbank, keine Logs deiner Messwerte. Cloudflare verarbeitet die für die Test-Übertragung notwendigen Daten gemäß DSGVO und EU-US Data Privacy Framework. Details in unserer Datenschutzerklärung.
10. Open Source und Reproduzierbarkeit
Der Mess-Code liegt unverschleiert in der index.html der Startseite. Du kannst per Rechtsklick → „Seitenquelltext anzeigen" jeden Schritt nachvollziehen. Wir planen, den Code in einem separaten GitHub-Repository zur Diskussion zu stellen.
Hast du Vorschläge für ein besseres Mess-Verfahren oder Anmerkungen zur Methodik? Schreib uns: hello@schnelligkeitstest.de.