Ein Browser. Ein Netzweg. Ein Messserver.
Die Messung läuft zwischen Ihrem Browser und unserem eigenen Server über HTTPS. Sie umfasst damit auch Ihr Gerät, das Heimnetz, den Router und die beteiligten Netze. Wir betreiben in dieser Version kein weltweit verteiltes Netz von Messstandorten und wählen keinen jeweils nächstgelegenen Fremdserver aus.
Der Test kann nicht automatisch belegen, dass Ihre Anschlussleitung tatsächlich Glasfaser ist. Er funktioniert grundsätzlich auch über andere Zugangstechniken. LAN, WLAN und Tarifwerte stammen – falls ausgefüllt – aus Ihren freiwilligen Angaben.
So läuft eine Messung ab
Zunächst reserviert der Browser einen Messplatz. Ist die konfigurierte Zahl gleichzeitiger Tests erreicht, wird kein weiterer Test dazugemischt. Danach folgt eine vorbereitende Latenzanfrage, die nicht in den Leerlaufwert eingeht. Anschließend werden acht kleine HTTP-Anfragen versucht. Mindestens vier gültige Antworten sind für die Fortsetzung nötig.
Im Standardmodus läuft vor dem gewerteten Download eine kurze Anlaufphase von höchstens 1,5 Sekunden beziehungsweise 64 MiB. Sie reduziert Anlaufeffekte von TCP und HTTP, ohne bei sehr schnellen Anschlüssen das Datenbudget schon vor der Messung aufzubrauchen. Danach werden acht Sekunden gewertet; im Modus „Daten sparen“ entfällt diese Anlaufphase und der Download hat einen Zielzeitraum von fünf Sekunden. Eine kleine Pause trennt Download und Upload. Der Upload wird zuvor kalibriert; seine eigentliche Messphase dauert abhängig vom ermittelten Uplink und der Blockgröße zwischen neun und 18 Sekunden. Datenlimits oder Fehler können eine Phase früher beenden.
„Daten sparen“ begrenzt vor allem die übertragbare Nutzdatenmenge. Auf schnellen Anschlüssen kann das Budget deshalb vor dem Zeitfenster erreicht werden; auf sehr langsamen Uplinks darf die Messung dagegen länger laufen, damit überhaupt vollständige Testblöcke bestätigt werden können.
Download: tatsächlich empfangene Nutzdaten
Der Browser lädt hochentropische Testdaten in vier parallelen Datenströmen. Im Standardmodus laufen diese Ströme zunächst kurz an; erst danach fließen die Bytes in den Geschwindigkeitswert ein. Eine einzelne Download-Anfrage startet mit 1 MiB und wird nach vollständig übertragenen Blöcken an die beobachtete Dauer angepasst; erlaubt sind 64 KiB bis 16 MiB je Anfrage. Der Server liest dafür immer aus derselben 16-MiB-Testdatei. Mehrere physische Dateien sind nicht nötig, weil der Endpunkt pro Anfrage exakt die angeforderte Teilmenge streamt und der Browser nur tatsächlich empfangene Bytes zählt.
Die Datenrate ergibt sich aus den empfangenen Nutzdaten in Bit geteilt durch die verstrichene Zeit. Wir zeigen einen Mittelwert dieser Phase, nicht den schönsten Einzelwert der Live-Kurve. Die Daten werden über Fetch und ReadableStream verarbeitet, ohne die vollständigen Antworten im JavaScript-Speicher zu sammeln. Komprimierte Testantworten werden zurückgewiesen.
Upload: erst kalibrieren, dann passend belasten
Der Browser erzeugt künstliche Binärdaten. Nach einem 1-KiB-Priming folgen bis zu vier parallele Kalibrierungsanfragen mit 64 KiB; ab ungefähr 8 Mbit/s wird zusätzlich mit 512 KiB pro Strom nachgemessen. Aus dieser Kalibrierung wird ein Profil mit einem, zwei oder vier Datenströmen gewählt. Die eigentlichen Blöcke reichen je nach Uplink von 8 KiB bis 8 MiB.
Bei hoher HTTP-Latenz darf das Profil größere Blöcke wählen, solange mindestens ein Block einschließlich Antwort innerhalb des Messfensters plausibel abschließbar bleibt. Das reduziert den Anteil der Antwortwartezeit, ohne langsame Leitungen mit übergroßen Requests festzusetzen.
Zum Messende zählt auch der bis dahin gemeldete Fortschritt eines gerade laufenden Uploadblocks. Mindestens ein kompletter Block der Messphase muss jedoch vom Server bestätigt worden sein. Fehlt diese Bestätigung, wird die Messung verworfen. Diese Kombination vermeidet die deutliche Unterbewertung, die entstehen würde, wenn der letzte teilweise gesendete Block grundsätzlich verloren ginge.
Latenz, Jitter und Last-Latenz
Die Latenz ist HTTP-basiert und enthält neben dem Transport auch Anteile von Browser- und Serververarbeitung. Als Ping zeigen wir den Median der gültigen Leerlaufproben. Jitter ist der mittlere absolute Unterschied aufeinanderfolgender Leerlaufproben. Der exportierte p95-Wert wird durch lineare Interpolation zwischen sortierten Leerlaufproben bestimmt.
Während der Download- und Uploadphase werden weitere kleine HTTP-Anfragen gestellt. Zwischen abgeschlossenen Proben liegt eine Pause von 250 ms. Aus mindestens drei gültigen Proben entsteht jeweils der Median unter Last. Bei weniger Antworten bleibt dieser Wert leer. Ein Timeout ist kein Nachweis für IP-Paketverlust; deshalb zeigen wir keine vermeintlich präzise Paketverlustrate an.
Datenverbrauch und Speicher
Im Standardmodus sind höchstens 1 GiB Download- und 1,25 GiB Upload-Nutzdaten vorgesehen. Die Download-Anlaufphase ist im 1-GiB-Downloadbudget bereits enthalten. Im Sparmodus sind es 32 MiB Download und 16 MiB Upload. Dazu kommt Protokoll-Overhead. Download-Anlaufdaten, Upload-Kalibrierung sowie abgebrochene oder noch unbestätigte Uploads können außerdem Daten verbraucht haben, die im abschließenden Zähler „Für Ergebnis gewertete Daten“ nicht enthalten sind. Die Anzeige ist daher keine Abrechnungsgrundlage für einen Mobilfunktarif.
Zusätzlich gibt es serverseitige Laufzeit-, Parallelitäts-, Start- und Tagesbudgets als Missbrauchsschutz. Ein abgebrochener Request gibt sein reserviertes Traffic-Budget nicht wieder frei. Das ist absichtlich vorsichtig und verhindert, dass wiederholte Abbrüche die Begrenzung umgehen.
Wie die Selbstkontrolle einordnet
Die Anwendung kontrolliert ihre eigenen Messplätze und Datenbudgets. Sofern die zugewiesene CPU-Kapazität hinterlegt ist und das Betriebssystem die nötigen Angaben liefert, wird die Systemlast vor und nach dem Test eingeordnet. Eine hinterlegte Serveranbindung ist eine Betreiberangabe, keine unabhängige Echtzeitmessung der verfügbaren Netzkapazität.
Eine fehlende Kapazitätskonfiguration, auffällige Systemlast, ausgeblendete Tabs, knappe Latenzproben, erreichte Datenlimits und Übertragungsphasen unter drei Sekunden erzeugen Messhinweise. Es gibt keine automatische Garantie, dass damit jeder Engpass auf Server- oder Netzseite erkannt wird. Besonders hohe Geschwindigkeiten müssen vor einem entsprechenden Leistungsversprechen auf der realen Infrastruktur kalibriert werden.
Diagnose und Vergleich bleiben Hinweise
Die Einordnung verwendet offengelegte Orientierungsschwellen: 90 Prozent für die Nähe zu einer freiwillig angegebenen Downloadrate und 40 ms für einen deutlichen Anstieg des Last-Medians. Bereiche nahe 100 Mbit/s oder 1 Gbit/s können bei passenden Tarifangaben einen Hinweis auf mögliche LAN-Grenzen auslösen. Keine dieser Regeln identifiziert automatisch eine konkrete fehlerhafte Komponente.
Der Vorher-nachher-Vergleich stellt zwei Einzelmessungen gegenüber. Unterschiedliche Modi werden gekennzeichnet. Eine angezeigte Differenz ist weder ein statistischer Signifikanznachweis noch der sichere Beweis einer Ursache. Das Tool ist kein zertifiziertes Nachweisverfahren zur Durchsetzung vertraglicher Ansprüche.
Geteilte Ergebnisse sind keine fälschungssicheren Zertifikate
Die Messwerte werden im Browser berechnet und erst auf Ihren Wunsch zur Veröffentlichung übertragen. Der Server prüft Datentypen, Wertebereiche, Testfreigabe und zugehörige Datenbudgets. Eine vollständige unabhängige Verifikation aller Browserwerte ist damit nicht verbunden. Die Ergebnisgrafik und ihr QR-Code dienen dem einfachen Teilen, nicht der Beweisführung.
Technische Grundlagen: ReadableStream (MDN) und XMLHttpRequest und Fortschrittsereignisse (MDN). Die oben beschriebenen Zeitfenster, Budgets und Einordnungen sind die eigene Methodik dieser Version.