How we measure

StackNest tools are browser probes, not lab instruments. They use the same APIs any web page has: fetch, performance.now(), RTCPeerConnection and a handful of navigator properties. That is enough to answer "is something wrong here?" in a few seconds, and not enough to replace a wired test rig, your provider's own measurement, or the game client itself.

Nothing is installed and no account is needed. The measurement logic runs on your device — our server does not compute your latency, speed or hardware profile for you.

Each target is probed three times over HTTP, timed with performance.now() from just before the request until the response arrives. We report the median of the successful samples rather than the average, so a single hiccup cannot dominate a three-sample series. Every request carries a cache-buster and is sent with no-store, so nothing is answered from cache, and any attempt still open after 8 seconds is aborted.

The targets are stable public assets: a champion image on the League of Legends CDN, favicons on official publisher domains, a Steam CDN image, a Cloudflare edge. They approximate the path to a region, not the actual match server. In Portuguese the South American targets are probed first; in English, North America and Europe.

This is not your in-game ping, and it is normally higher. An HTTP round trip includes DNS resolution, TCP and TLS handshakes and a web server's response, while your game client sends UDP packets over a session it already holds with the match server. Use our result to compare regions and spot a bad route — use the game's own scoreboard for the number that decides your match.

The speed test uses Cloudflare's public endpoints. Latency is eight zero-byte requests; download is three transfers of 250 KB, 1 MB and 2.5 MB; upload is three of 200 KB, 750 KB and 1.5 MB. Each transfer's rate is bytes × 8 ÷ elapsed seconds, and the figure shown is the median of the transfers that completed. Anything still running after 25 seconds is abandoned rather than reported.

These payloads are deliberately light — enough to be honest on a phone with a data cap, not enough to saturate a fast link. On gigabit connections the result reads low, because a 2.5 MB file finishes before the connection reaches full speed. To argue with your provider, use a saturating multi-server test; to find out whether something is wrong right now, this is faster and costs far less data.

Jitter is the mean absolute difference between consecutive latency samples — how much the round trip moved from one request to the next. It needs at least two successful samples. Treat it as a stability signal, not as the ITU-T packet delay variation a network engineer would quote.

The leak test opens an RTCPeerConnection against public STUN servers, collects the addresses WebRTC reveals over a three-second window, and compares them with the public IP the page sees. WebRTC exposing a local address (192.168.x.x and similar) is expected and harmless; a public address that differs from your VPN's is the case worth looking at.

For DNS we read which resolver answered on your behalf, with its IP and coarse location. A resolver IP that differs from your public IP is normal — most people use their provider's recursive resolver — so we report it as an observation, not a verdict.

We do not print a definitive "you are leaking" from browser signals alone. When the evidence does not settle the question the result says inconclusive and shows what was observed. A conclusive leak test needs probes from outside your browser, and claiming certainty we cannot have would be worse than saying we do not know.

Hardware figures are whatever the browser chooses to expose, and browsers blur them on purpose to resist fingerprinting. navigator.hardwareConcurrency reports logical cores, but privacy modes routinely pin it to 2 regardless of the real processor.

Memory is blurrier still: navigator.deviceMemory exists only in Chromium and is rounded into a bucket between 0.25 and 8 GB. A 16 GB Mac reports 8 GB at best, and Safari and Firefox report nothing at all. When the value is missing we say the browser does not expose it — we never estimate RAM from other signals.

When we see two cores together with missing or very low memory, we label it a likely privacy protection rather than a weak machine. Battery works the same way: if navigator.getBattery is absent, the tool says so instead of guessing a percentage.

Colours and labels come from fixed thresholds, so the same result always reads the same way:

Ping — good / fair / high

< 55 ms · 55–95 ms · ≥ 95 ms

Speed-test latency

< 40 ms · 40–90 ms · ≥ 90 ms

Jitter — stable / moderate / unstable

< 8 ms · 8–25 ms · ≥ 25 ms

Download

< 5 · 5–25 · 25–100 · 100–300 · ≥ 300 Mbps

These are consumer-oriented buckets chosen for legibility, not standards. A 60 ms ping is fine in a strategy game and painful in a shooter; 20 Mbps is plenty for one stream and tight for a household of four.

Close other tabs and downloads, prefer a cable or stand near the router, and run the test more than once at different times of day — a single sample says little about a connection that only degrades at night. Battery saver mode and background sync also slow the browser enough to show up in the numbers.

If our result and a specialised tool disagree, trust the specialised tool: the game client for match latency, a saturating multi-server test for throughput, a probe outside your browser for a definitive leak check. These tools exist to tell you quickly whether something deserves that deeper look.