How Our Tests Work
The technology behind each test — WebRTC DataChannels, HTTPS timing, and MTR-based hop-by-hop analysis.
Overview
NetworkTests.com uses advanced, browser-based techniques to provide accurate insight into real-world network performance. Each test is designed to measure different aspects of connectivity using methods that closely reflect how modern applications transmit data.
WebRTC DataChannel with UDP-like behavior
• Packet loss
• Round-trip latency
• Jitter
• Network stability
HTTPS timing to Google, Cloudflare, Amazon, Microsoft
• DNS resolution
• TCP handshake
• TLS negotiation
• Total connect time
MTR from server to your NAT-mapped UDP endpoint
• Per-hop latency
• Per-hop jitter
• Per-hop loss
• Path visibility
UDP Packet Loss & Latency
WebRTC DataChannel · UDP-likeBrowser
WebRTC DataChannel
unreliable + unordered (UDP semantics)
Server
WebRTC DataChannel
Sequentially numbered packets
#001
✓
22ms
#002
✗
lost
#003
✓
24ms
#004
✓
21ms
Calculations:
Packet loss = (sent - received) / sent
Latency = round-trip from server timestamps
Jitter = variation between consecutive arrivals
Our platform uses WebRTC DataChannels configured for unreliable and unordered delivery to closely emulate UDP behavior. Unlike reliable TCP-based channels, packets that are lost are not retransmitted — just like real UDP traffic.
By sending sequentially numbered packets, we can precisely detect which packets were lost and calculate performance consistency.
Round-trip latency is measured using server-side timestamps, which helps avoid inaccuracies caused by time differences between your device and our servers. The server records the send timestamp in each packet. When the browser receives a packet and sends a response, the server calculates the true round-trip time.
TCP Latency
HTTPS · TCPBrowser
Target Servers
google.com
cloudflare.com
amazon.com
microsoft.com
◄─────── Total measured time ───────►
TCP latency is measured using precise HTTPS request timing to major global cloud providers, including Google, Cloudflare, Amazon, and Microsoft.
This approach captures the complete connection setup time, including DNS resolution, TCP handshake, and TLS negotiation. Together, these provide a realistic view of how quickly your device can establish secure connections to widely used internet services.
DNS
12ms
TCP
18ms
TLS
34ms
HTTP
22ms
Note: The first request to each target includes DNS and TLS setup time. Subsequent requests reuse the connection, showing only round-trip latency. We discard the first sample and use subsequent measurements for accuracy.
Hop-by-Hop Analysis
MTR · UDP via WebRTC NAT→
203.0.113.47:52341
→
Server
knows your IP:port
1ms
4ms
12ms
18ms
*
22ms
You
MTR probes toward 203.0.113.47
Browser
displays live table
◄── WebSocket ──
hop-by-hop data
Server
streams MTR
For reverse path diagnostics, our servers perform hop-by-hop analysis toward your connection using MTR. This process uses your public IP address and the NAT-mapped UDP port discovered during WebRTC ICE negotiation.
By traversing the network path in this way, we can estimate latency, jitter, and packet loss across each intermediate hop from our server to your internet edge. This provides deeper visibility into where performance degradation may be occurring along the route.
Per-Hop Latency
See exactly how much delay each router adds to your connection.
Per-Hop Jitter
Identify which routers introduce inconsistency into your connection.
Per-Hop Loss
Find the router or link that's dropping your packets.
Our detailed guide explains how to read MTR output — what packet loss patterns, latency jumps, and asterisks really mean.
→ Reading MTR Results