Wie wir messen
Wie wir messen
Was unser Verbindungstest genau misst, wie die Werte berechnet werden und was ein Browser grundsätzlich nicht messen kann.
Diese Seite erklärt, was unser Verbindungstest tatsächlich misst, wie die Werte berechnet werden und was ein Browser grundsätzlich nicht messen kann. Sie ist kürzer als die englische Fassung – die vollständige Methodik bleibt auf Englisch maßgeblich.
Was der Test macht
- Ruhelatenz: 50 Anfragen an unseren eigenen Endpunkt, jeweils im Abstand von 60 ms, gemessen über die PerformanceResourceTiming-Schnittstelle des Browsers. Die ersten fünf Messwerte dienen als Aufwärmphase.
- Tick-Loop: 30 Sekunden lang 20 kleine Frames pro Sekunde über WebSocket – das Tempo eines typischen Shooter-Servers. Der Server spiegelt jedes Frame unverändert zurück.
- Latenz unter Last: eine große Download-Anfrage im Hintergrund, während alle 400 ms die Latenz gemessen wird.
Wie die Zahlen berechnet werden
- Perzentile mit linearer Interpolation. Wir zeigen p50, p95 und den schlechtesten Wert – niemals nur einen Mittelwert, denn Mittelwerte verstecken Spitzen.
- Jitter als mittlere absolute Differenz aufeinanderfolgender Messwerte, zusätzlich als 95. Perzentil.
- Ausbleibende Antworten nennen wir Timeouts, nicht Paketverlust: Der Transport ist TCP-basiert, TCP wiederholt verlorene Pakete.
- Ein Urteil gibt es erst ab 30 verwertbaren Messwerten. Sonst sagt der Test, dass er es nicht weiß.
Was ein Browser nicht messen kann
- Deinen In-Game-Ping: Ein Browser kann keinen Rohsocket zu einem Spielserver öffnen, und Spielserver antworten in der Regel nicht auf ICMP.
- Echten UDP-Paketverlust: Browser können keine rohen UDP-Pakete senden.
- Die Route zu einem Spielserver: Dafür braucht es Messpunkte in der Region des Spiels.
- FPS, Hardware und Netcode des Spiels: absichtlich außerhalb des Umfangs.
Die vollständige, maßgebliche Methodik veröffentlichen wir auf Englisch. Vollständige Methodik auf Englisch lesen (EN)