WebRTC Latency Test: Measure P2P Round-Trip Time

WebRTC Latency Test: Measure P2P Round-Trip Time

WebRTC latency measures the actual peer-to-peer round-trip. Because traffic travels through both users' routers, ISPs, and any NAT hardware in between, the round-trip time you see here reflects real network conditions that server-based ping tools cannot replicate.¹ A 20 ms server ping can coexist with 80 ms peer-to-peer latency on the same connection. Running two browser instances on different connections and completing the WebRTC handshake gives you the number your video conferencing software experiences when it routes a call directly between participants.

The STUN probe on this page runs automatically before the connection begins.² Contacting public STUN servers from Google and Cloudflare, it discovers your public IP address and classifies your NAT type, which tells you whether your network supports a direct WebRTC data channel or will require relay infrastructure.³ Probe packets then travel directly between the two browser instances at 100 ms intervals, and each round-trip time lands on the live sparkline as it arrives.⁴

What round-trip time measures in WebRTC

Round-trip time in WebRTC is the elapsed time between one peer sending a probe packet and receiving the echo back from the other peer. Unlike a server ping, which measures the path to a datacenter, this measurement captures every router, switch, and NAT translation layer between the two browsers.⁵ Consequently, RTT values here are always higher than the same network's ping to Google.com. That gap represents the overhead of home router NAT, residential ISP routing, and any carrier-grade NAT sitting in between.Values below 30 ms indicate a direct LAN or very low-latency ISP path; values above 150 ms point to geographic distance, congested ISP links, or relay routing through TURN infrastructure.⁶

What causes elevated WebRTC RTT

Geographic distance is the largest single factor in peer-to-peer RTT. Light travels through fiber at roughly 200,000 km per second, so a trans-continental connection adds a physical minimum of 30 to 70 ms before any routing overhead.⁷ Building on this, ISP peering arrangements can add further delay; two connections on the same city block but served by different ISPs may route through distant peering points. Symmetric NAT forces all traffic through a TURN relay server, adding a server hop that typically contributes 20 to 60 ms depending on relay location.⁸ ISP congestion during peak evening hours raises RTT by 20 to 40 ms on many residential connections.⁹

Interpreting results and taking action

An average RTT below 50 ms with jitter under 5 ms indicates a healthy direct connection suitable for video calls and gaming. RTT between 50 and 150 ms with low jitter is usable for most real-time applications but may show buffering in video calls. RTT above 150 ms or jitter above 20 ms will produce audible artifacts in VoIP and visible stuttering in video.⁶

Using the ICE candidate type to prioritize fixes

Yet the most actionable signal is whether the ICE candidate type shows "srflx" (direct NAT traversal) or "relay" (TURN server path).³ Switching from relay to direct reduces RTT by the full relay server round-trip, typically 20 to 60 ms.⁸ Checking the candidate type before adjusting router settings avoids wasted effort on configurations that will not change the relay status. A relay path means the NAT topology prevents a direct connection, and no amount of local QoS tuning will bypass the need for the relay.

Isolating router-added latency from the ISP path

Total P2P RTT combines contributions from three distinct network segments: your local router's processing and queuing delay, the backbone routing between the two ISPs, and the remote peer's local routing. Treating the result as a single number hides which segment is responsible for elevated latency. The simplest isolation step is running both browser instances on the same local network using two different devices connected to the same router. The RTT produced by this same-LAN test reflects only router processing overhead and wireless delay, with no ISP path contribution.¹

A typical wired same-LAN RTT is 1 to 4 ms; Wi-Fi adds 2 to 10 ms depending on band and distance from the router.¹⁰ Subtracting this baseline from a cross-ISP measurement isolates the ISP backbone contribution. For example, if same-LAN RTT is 3 ms and cross-ISP RTT is 80 ms, the ISP path contributes approximately 77 ms. Repeating the cross-ISP test with the remote browser on a mobile hotspot from a different carrier reveals whether the backbone routing or carrier-grade infrastructure adds the gap.

When to run a same-LAN baseline before comparing connections

Running a same-LAN baseline whenever you evaluate a router change or QoS configuration establishes a clean reference point. If a configuration change increases same-LAN RTT from 3 ms to 8 ms, the router itself has become slower, not the ISP path. This distinction prevents misattributing router-side regressions to the ISP. For Wi-Fi evaluation, compare same-LAN RTT on 2.4 GHz versus 5 GHz versus wired to quantify wireless overhead independently before testing across locations.

Comparing wired and wireless WebRTC latency

Switching from wireless to wired Ethernet is the single most effective step for reducing P2P RTT and jitter on a home network. Wireless connections introduce variable queuing from 802.11 frame retransmissions: when a frame fails on first transmission and is retransmitted, the retransmission delay (typically 2 to 8 ms at 5 GHz) adds a jitter spike to that packet's arrival time.¹¹ On 2.4 GHz, neighboring network interference increases retry frequency, often producing 10 to 30 ms jitter on a lightly loaded connection.¹⁰

Connect one test device to Ethernet and leave the second on Wi-Fi, both on the same router, and run the P2P tester between them. The measured RTT reflects the wireless contribution to round-trip time, with no ISP path component. A 5 GHz device typically adds 2 to 8 ms over the wired baseline; a 2.4 GHz device on a congested band can add 10 to 30 ms.¹²

Determining whether excess RTT is wireless or ISP in origin

If your total cross-ISP RTT is unacceptably high, splitting same-LAN RTT from cross-ISP totals confirms whether the excess sits in the wireless segment or further upstream, comparing same-LAN RTT on Wi-Fi versus wired. Wireless excess shows in both same-LAN and cross-ISP measurements; ISP excess shows only in cross-ISP measurements. This two-step process prevents adjusting router wireless settings when the actual problem is an ISP backbone bottleneck that no router setting can address.

Running the same-LAN and cross-ISP measurements on a schedule keeps the reference points honest as your router firmware and ISP routing change. A baseline that drifts upward over several weeks usually points to ISP-side changes rather than your local hardware, especially when the same-LAN number stays flat. Treat the wireless-versus-ISP split as a repeatable routine, not a one-time check, so you can defend any router purchase or ISP complaint with current numbers.

When to use this

Run this test when video calls feel laggy, when you want to compare wired and wireless connections, or when you need to verify that a router configuration change improved your direct peer-to-peer latency before committing to the change.

Examples