This widget times a tiny HTTPS request to /api/latency on the same host that served the page. That is a round-trip time (RTT) sample through TCP, TLS, and HTTP on whatever path your packets took to reach my edge, not an ICMP echo like the pingutility prints. I built the wording this way because I once sat on a Discord call in Karachi where my in-game ping read 42 ms to a Singapore shard while this style of browser RTT to a European SaaS API sat near 280 ms: two completely different destinations, two different numbers, both "true." Use the results here as a before and aftersignal when you toggle VPN servers, switch Wi‑Fi bands, or replace a router, not as a substitute for a game client's built-in meter.
Latency is more than one number in a cable
Network engineers split delay into pieces: propagation (distance at roughly two thirds the speed of light in fiber), serialization (how long bits spend on the wire at your link speed), queueing (waiting behind other packets inside routers), and processing (host stacks, firewalls, TLS crypto). A single RTT sample collapses all of that into one millisecond figure. That is useful, but it hides whether you are dominated by physics (oceanic distance) or by policy (bufferbloat under load).
Bandwidth answers how much data per second you can move once the pipe is full. Latencyanswers how long until the first byte of a response arrives. A gigabit link with 400 ms idle RTT still feels sluggish for voice, games, and interactive SSH because human perception keys off response time, not bulk throughput. The classic reference here is RFC 792 for ICMP echo semantics, even though browsers cannot emit ICMP directly from JavaScript.
Why this page measures HTTPS instead of ping
The web security model never exposed raw ICMP sockets to untrusted pages. If you need classic ping, run it from a terminal (examples below). What is available to this site is a timed fetch() to the same origin: the browser performs DNS (usually cached), opens or reuses a TCP connection, negotiates TLS unless a session ticket resumes, sends a minimal HTTP request, and waits for headers. That path mirrors real API traffic more closely than a 64-byte ICMP echo, so the number tends to sit a few milliseconds above ping on a clean link and can jump further when packet loss forces retransmissions.
Warm connections skew low because TLS 1.3 resumption and HTTP keep-alive remove handshakes you paid on the first sample. Cold starts skew high. That is not a bug; it is what your users experience when they open a new site tab. When you compare VPN products, run several batches and discard only the obvious outliers caused by background sync or OS sleep.
Rough RTT budgets by activity
These are rules of thumb for interactive feel, not guarantees. Competitive first-person shooters optimize toward double-digit milliseconds inside the same region. Voice over IP tolerates one-way delays up to about 150 ms before people talk over each other. Video streaming mostly buffers seconds of video, so last-mile RTT matters far less than throughput until you run out of buffer.
Latency requirements by use case
| Activity | Acceptable RTT | Comfortable RTT | When it falls apart |
|---|---|---|---|
| Web browsing | < 200 ms | < 80 ms | Lossy Wi‑Fi with retransmits; DNS stalls |
| Video streaming (buffered) | < 300 ms | < 120 ms | Throughput too low for chosen bitrate |
| Video call (WebRTC) | < 250 ms one-way equivalent | < 120 ms RTT to SFU region | Jitter spikes without adaptive jitter buffer |
| Online FPS (competitive) | < 80 ms to game region | < 40 ms | Queueing under load; Wi‑Fi airtime contention |
| MMO / turn-based | < 200 ms | < 100 ms | Packet loss without client prediction |
| Fighting games (rollback) | Low jitter matters more than mean | < 30 ms variance | Unstable Wi‑Fi micro-spikes |
| Automated trading (co-located) | < 1 ms within rack | < 100 µs on RDMA paths | Any internet path (wrong tool entirely) |
WebRTC deployments often publish regional targets; see W3C WebRTC for the protocol surface this traffic shares with video calls.
Why the same apartment shows different numbers hour to hour
Wi‑Fi is half-duplex: every neighbor on the channel competes for airtime. Microwave ovens leak into 2.4 GHz. VPN servers change exit cities when providers rebalance load. Mobile handoffs pause forwarding for tens of milliseconds. Even on wired Ethernet, your ISP may route you through a cheaper peering path at night than during business hours. Trend lines beat single samples; log ten readings after dinner and ten before work if you suspect congestion.
Bufferbloat is the silent killer: an oversize queue at your router or ISP absorbs bursts but adds delay whenever the link is saturated. Run this latency tool idle, then run a large download and click measure again. If RTT doubles while throughput is pegged, you are seeing queueing, not a bad speed test server.
Measuring latency from the command line
These commands hit whichever host you pass; replace the example with your game server, office VPN gateway, or DNS anycast address.
Windows (PowerShell or Command Prompt)
ping -n 20 1.1.1.1
tracert -d 1.1.1.1ping issues ICMP echo requests if the path allows them (some routers drop ICMP under load). tracert prints per-hop timings toward the target; -d skips reverse DNS lookups so the output stays fast.
macOS and Linux
ping -c 20 1.1.1.1
traceroute -n 1.1.1.1
mtr -rwzc 100 1.1.1.1mtr combines ping and traceroute into a rolling report; install via brew install mtr on macOS or your distro package manager on Linux. It is the fastest way I know to prove intermittent loss on a Wi‑Fi hop without guessing.
Practical steps that actually lower RTT
Use wired Ethernet for anything competitive. Pick the closest VPN city that still meets your legal requirements. Enable SQM or a modern AQM (CoDel / FQ-CoDel) on your router so uploads cannot inflate queues. In games, choose the server region the client recommends instead of chasing friends on another continent unless you all accept the penalty.
A VPN can increase RTT because it adds encryption work and hairpins traffic through a remote POP. It can sometimes decreaseperceived lag if your ISP peers poorly with a game network but the VPN provider peers well: you are trading one routing policy for another. Measure both paths with the same tool rather than trusting marketing copy about "gaming mode."
Frequently asked questions
What is the difference between latency and bandwidth?
Bandwidth is capacity: megabits per second you can sustain after the pipe fills. Latency is delay: how long a small request takes to return. A satellite link can show high bandwidth and unusable latency for voice; a low-bandwidth leased line can feel snappy for SSH. This page only measures delay to this origin, not throughput.
What is a good ping for gaming?
For fast-twitch shooters, double-digit milliseconds to the publisher's regional relay is the competitive norm. Strategy games and MMOs tolerate higher RTT thanks to prediction. Always compare against the same server region; a 30 ms reading here does not imply 30 ms to a Tokyo shard if this site's edge is closer.
Why is my Wi‑Fi latency worse than wired?
Wi‑Fi shares one radio channel with every nearby network. Each retransmission adds milliseconds. Microwaves, Bluetooth accessories, and DFS radar avoidance on 5 GHz all insert jitter. Ethernet avoids those collisions entirely. If you must stay on wireless, sit closer to the access point, use 5 GHz or 6 GHz when available, and enable Wi‑Fi Multimedia (WMM) so small packets queue with higher priority.
How do I lower my ping?
Start with physics: pick servers physically closer. Then fix your access layer: wire the PC, move off congested Wi‑Fi, and cap upload-heavy cloud backups while gaming. Finally tune routing: try a different VPN city, call the ISP if traceroute shows a bad domestic hop, or enable SQM if bufferbloat spikes RTT whenever someone uploads a video.
Can a VPN reduce latency?
Usually no: encryption and extra hops add milliseconds. Occasionally yes, when your ISP routes you through a congested peering point but the VPN exits onto a healthier path to the destination. Treat it as an experiment: measure ten samples on VPN and ten off, same time of day, same server choice.
Related tools
Throughput still matters for downloads: run Internet Speed Test. If you are checking whether inbound services answer from the internet, pair RTT with What Is My Open Ports. Organization routing context is in What Is My ISP. For VPN path consistency, follow up with VPN Leak Test.
Sources cited above
- RFC 792: Internet Control Message Protocol
- RFC 9000: QUIC transport (what modern HTTPS stacks often ride on)
- W3C WebRTC: realtime media over UDP/TLS
- Bufferbloat.net wiki: mitigations for queue-induced latency