QUIC · WebTransport · Real UDP Datagrams · 2 Server Locations
📡 Latency (RTT)
〰️ Jitter
⚠️ Packet Loss
⬇️ Download · Steady-State
⬆️ Upload · Server-Measured
RTT and jitter are measured via UDP datagram echo — not TCP round-trips or HTTP polling. Each ping embeds a high-resolution timestamp and sequence number for sub-millisecond accuracy.
200 datagrams are fired concurrently; any that fail to echo within 2 seconds count as lost. Rolling 20-probe windows reveal per-burst loss patterns across your connection path.
QUIC: 12 concurrent WebTransport streams download data over a time-bounded window. The first 1.5 seconds are discarded to exclude congestion-control ramp-up; only the steady-state window is averaged.
TCP: 6 parallel HTTP/1.1 streams, each on an independent TCP connection. HTTP/1.1 is negotiated (not HTTP/2) on purpose: under HTTP/2 the browser would coalesce all 6 streams onto a single TCP connection, where one stalled connection drags all 6 to zero via head-of-line blocking. The server sends pseudo-random bytes to defeat ISP compression inflation.
QUIC: 16 WebTransport streams each send data to the server. The server independently times each stream from first byte to FIN, discards the first 2 seconds (slow-start ramp-up), and reports steady-state Mbps. The 16 per-stream values are summed for the total. Chrome serialises writes within a single QUIC stream, so parallel streams are required to fill the shared CWND.
TCP: 6 parallel XHR streams each POST a 50 MB body over independent HTTP/1.1 connections. xhr.upload.onprogress fires as bytes leave the TCP socket; bytes are summed across all streams and divided by the fixed test-duration window: Up_Mbps = Σ B_u,i × 8 / T_ms / 1000 (T = 8 s standard · 12 s deep). XHR is used (not fetch()) because Chrome throws a TypeError when a streaming ReadableStream body with duplex:'half' is sent over an HTTP/1.1 connection.
A background traceroute streams hop-by-hop data to the UI in real time as the test runs, using multi-method mtr probes from the server (ICMP, UDP/53, TCP/80) merged per hop. Each visible hop is reverse-geolocated via GeoLite2 to show city and ISP. Hops that filter all probe methods show as gaps in the chain.
After the test, a composite stability score is computed from RTT, jitter, loss, and throughput — classifying your link as suitable for gaming, video calls, or general browsing, with ranked issue diagnosis and percentile comparison against real users in the last 30 days.
QUIC uses UDP as its carrier, but it reimplements everything TCP does on top of it: reliability, retransmission, congestion control, flow control, packet ordering. The "UDP is fast" reputation applies to unreliable protocols (DNS, game state updates) that skip all that work. QUIC skips none of it — and then adds TLS 1.3 encryption per-packet entirely in the browser process, not the kernel. For reliable bulk transfer, QUIC and TCP carry the same logical overhead.
TCP is implemented inside the OS kernel and benefits from hardware offload (TSO, GSO, GRO) that processes thousands of bytes per CPU instruction. QUIC runs inside the browser's process — every packet cycles through userspace code before touching the kernel's UDP socket. This CPU overhead is why TCP wins on raw upload throughput. Your RTT result tells the real story: QUIC observed latency is typically lower than TCP — QUIC measures a bare UDP datagram echo; TCP measures an HTTP fetch over a keep-alive connection, which adds framing overhead and delayed-ACK effects. The latency advantage is real, but partly reflects measurement methodology.
Google, YouTube, and Cloudflare use QUIC not for raw speed but because it eliminates head-of-line blocking (a slow stream can't stall all others), survives IP changes without reconnecting (mobile handoffs), and establishes connections faster with 0-RTT resumption. On lossy or congested paths, QUIC's per-stream recovery dramatically outperforms TCP. These are the use cases QUIC was designed for — not beating TCP on a clean link throughput test.
Note on 0-RTT: This server has 0-RTT (early data) disabled on the WebTransport endpoint. Every QUIC session shown here is a full 1-RTT handshake — no session ticket shortcut. The RTT you see is the true baseline cost of a QUIC connection to this server, not a resumed session.
Both download and upload are comparable. Download measures bytes received at the browser (steady-state, post-1.5s trim); QUIC upload measures bytes received at the server per stream (steady-state, post-2s trim); TCP upload measures bytes leaving the client socket (via xhr.upload.onprogress) divided by the fixed test-duration window (8 s standard · 12 s deep). All three methods report the connection's real sustained capacity, not a burst artifact. A QUIC value more than 30–35% below TCP on either direction suggests ISP protocol differentiation (UDP deprioritisation).
Upload gap: QUIC vs TCP. QUIC upload uses server-measured steady-state throughput with a 2-second warmup exclusion. TCP upload uses client-side bytes reported by xhr.upload.onprogress (bytes leaving the socket) divided by the fixed test-duration window. A gap between the two reflects real protocol efficiency differences — QUIC upload runs over userspace QUIC in the browser process; TCP upload runs over kernel TCP with hardware offload (TSO/GSO), giving TCP a structural advantage on raw upload throughput.
QUIC upload faster than TCP upload: Unusual — would suggest the ISP is actively prioritising UDP, or the TCP measurement is running over a congested path.
The RTT gap — QUIC typically lower than TCP — is a reliable signal that both tests ran cleanly. QUIC measures a raw datagram echo; TCP measures an HTTP round-trip including framing overhead. If TCP RTT were substantially lower than QUIC RTT, it would suggest unusual network conditions or a measurement anomaly.
For general browsing and streaming HD video, 25 Mbps download is typically sufficient. For 4K streaming or working from home, 100 Mbps or more is recommended. For gaming, the ping (RTT) matters more than raw speed — under 30 ms is excellent, under 60 ms is good. Jitter should be below 5 ms for smooth real-time applications.
Ping, or Round-Trip Time (RTT), measures how long it takes a data packet to travel from your device to the server and back, in milliseconds (ms). Lower is better. Under 20 ms is excellent, under 60 ms is good for most uses, and over 150 ms can cause noticeable delays in gaming or video calls. This speed test measures RTT using true UDP datagrams over QUIC — more accurate than TCP-based ping measurements.
Jitter is the variation in ping times between packets, measured as the standard deviation of RTT in milliseconds (ms σ). High jitter means your connection's latency is inconsistent, which causes choppy video calls, audio dropouts, and lag spikes in gaming. Below 3 ms σ is excellent, below 10 ms σ is acceptable, and above 20 ms σ can cause real-world problems.
Packet loss is the percentage of data packets that fail to arrive at their destination. Even 1% packet loss can significantly degrade video calls and online gaming, as it causes retransmissions and delays. This test sends 200 UDP datagrams in a burst and measures how many return within the timeout window. Zero packet loss is ideal — anything above 2% is problematic.
Most speed tests (including Speedtest.net and Fast.com) use TCP-based HTTP connections, which include congestion control and retransmission that can mask real network conditions. This test uses QUIC (HTTP/3) and WebTransport with true UDP datagrams for RTT and packet loss measurements. QUIC download uses 12 concurrent WebTransport streams with a trimmed-mean that discards the first 1.5 seconds of ramp-up. TCP download uses 6 parallel HTTP/1.1 streams, each on an independent TCP connection. HTTP/1.1 is negotiated (not HTTP/2) on purpose: under HTTP/2 the browser would coalesce all 6 streams onto a single TCP connection, where one stalled connection drags all 6 to zero via head-of-line blocking. QUIC upload is measured server-side, discarding the first 2 seconds across 16 WebTransport streams. TCP upload uses 6 XHR streams over independent HTTP/1.1 connections; bytes are tracked client-side via onprogress as they leave the socket, divided by the fixed test-duration window (8 s standard · 12 s deep). All approaches report the connection's real sustained capacity, not a burst or ramp-up artifact. It also provides jitter analysis, packet loss probing, and a full network fingerprint with a stability score.
QUIC is a modern transport protocol developed by Google and standardized by the IETF. It runs over UDP instead of TCP, which means faster connection setup, no head-of-line blocking, and built-in encryption (TLS 1.3). Using QUIC for speed testing gives results that reflect your connection's performance for modern web traffic (YouTube, Google services, Cloudflare sites all use QUIC). WebTransport is a browser API that exposes QUIC streams and datagrams directly to web pages.
After your test completes, the 'What's Limiting You?' engine analyses every metric — latency, jitter, packet loss, buffer bloat, Wi-Fi detection, congestion, download and upload speed — and produces a ranked list of issues sorted by severity (critical, warning, notice, or OK). Each issue includes a plain-English explanation of the cause and a specific fix suggestion, so you know exactly what to do to improve your connection.
QUIC runs over UDP, not TCP. Many ISPs — including Charter/Spectrum, Comcast, and others — apply Quality of Service (QoS) policies that rate-limit or deprioritise UDP traffic relative to TCP. This means a TCP-based speed test to a farther server can show higher speeds than a QUIC test to a nearby server, because the ISP is applying a different traffic policy to each protocol. This speed test measures your real QUIC/HTTP3 performance — which is exactly what your browser uses for Google, YouTube, Cloudflare, and other modern sites. If your QUIC upload is significantly lower than your TCP upload, the most likely cause is ISP UDP deprioritisation — but congestion control differences, browser userspace overhead, and packet pacing can also contribute. A gap above 30–35% is a strong indicator of ISP protocol differentiation.
Yes. PQ Crypta Speed Test has two server locations: US East (Virginia) and US Midwest (Missouri). The test automatically selects the nearest server based on your location when the page loads. You can manually switch servers using the location picker at the top of the page — the connection re-establishes instantly and a new path trace runs to the selected server. Both servers run QUIC/WebTransport on UDP port 4433 using post-quantum TLS (ML-KEM-768) and HTTP/1.1 on port 443.
Compare Me shows your percentile ranking across five metrics — latency (RTT), jitter, packet loss, download speed, and upload speed — compared against all users who have run a test in the last 30 days. A percentile of 80% means your connection beats 80% of users on that metric. The comparison is calculated server-side from anonymised test results stored in a rolling 30-day window, and grows more meaningful as more users run the test.