Pong.com Methodology

Bufferbloat

Routers buffer packets to keep their bandwidth numbers high under load. The cost is latency: a connection that pings 15ms idle can balloon to 300ms or more once a download is saturating the line. That is what makes a video call freeze when someone else uploads a video, and it is invisible to single-number speed tests. We measure the delta between idle ping and ping under load, in both directions, and grade it.

Jitter

Average latency tells you how fast packets get there. Jitter tells you how consistent the timing is. A 30ms ping with 2ms jitter feels rock solid; a 30ms ping with 40ms jitter feels worse than a stable 60ms ping because every other packet arrives off-beat. Voice and video codecs can hide a small amount of jitter with playback buffers, but past a threshold the buffer drains and packets are dropped.

Why download alone is insufficient

A 1Gbps download is irrelevant to a Zoom call that needs 4Mbps up and stable latency. A 500Mbps download is irrelevant to a Warzone session that needs sub-50ms ping with sub-10ms jitter. Picking connections by raw download is like picking cars by top speed without checking whether the brakes work. Pong measures all the failure modes that matter to real applications, then translates them into per-use-case experience scores.

All speed-test results on Pong.com come from our own measurements against our own servers. Nothing on the test page is sourced from third parties. For the analysis content on the blog and on city, state, and ISP pages, we cite and cross-reference the following public datasets:

• FCC Broadband Data Collection (BDC). Authoritative US broadband availability and provider coverage.
• Ookla open data. Quarterly tile-level performance datasets used for cross-checks.
• NTIA broadband maps. Federal funding allocation and underserved-area data.
• BroadbandNow. Provider directory and pricing references.
• Measurement Lab (M-Lab). Independent open measurement data, useful for sanity-checking regional trends.

Pong measures what your browser sees over TCP and HTTP. That is the same protocol stack used by streaming video, video calls, cloud storage, web apps, and most modern software, so the numbers map directly to the experience of using those apps. The measurement is honest about what a browser can and cannot see.

What we cannot do from a browser is talk raw UDP or measure ping with the same overhead a native game client gets. Real games use UDP and have direct kernel paths to the network stack; a browser test adds roughly 5 to 15 milliseconds of overhead from the HTTP/TCP/TLS layers. Treat Pong's latency numbers as an upper bound on what an in-game ping should be against the same target server. The relative comparisons (server A vs server B, before router fix vs after) are unaffected by the overhead and remain accurate.

We also cannot measure links beyond the test endpoint. A test from your house to our Newark server tells you about the path between those two endpoints. If your specific game server lives in a different facility on a different network, your in-game numbers may differ. The 16-city server mesh is designed to keep at least one Pong endpoint close to wherever your real traffic is going, but it is not a substitute for measuring the exact path of a specific application.

Pong publishes its full methodology because trust in a measurement tool requires the ability to reproduce its results. Most major consumer speed tests, including the largest commercial providers, keep their server selection, scoring, and aggregation logic proprietary. That makes it difficult to know why two tools disagree, or to evaluate whether a result is meaningful.

The page you are reading describes every measurement Pong performs, the order they run in, the parameters used, and the limitations of each. For a deeper background read, see How internet speed tests work.