How LagScope measures your connection — and where it stops

A lag tool you can’t audit is just another opinion. This page is the full recipe: what we send down the wire, how every number is computed, what a browser physically cannot see, and when LagScope is the wrong tool entirely. If anything here ever drifts from what the tool actually does, the tool wins — tell us and we’ll fix the page.

What goes down the wire

In GAME TRAFFIC mode, LagScope opens a WebRTC connection to the nearest measurement node (US, EU or Brazil — auto-selected by lowest measured latency at page load) and sends 128-byte UDP packets at 30 Hz over an unreliable, unordered DataChannel — the same shape as real game traffic: small, frequent, and never retransmitted. That last part is the point. TCP-based tests quietly resend lost packets, so loss becomes invisible; our probes behave like your game’s packets, so a lost probe is recorded as loss, exactly the way your game felt it. If WebRTC is unavailable, the monitor falls back to lightweight HTTP probes and says so in the status line — HTTP timing still catches spikes and outages, but it can’t show true UDP loss.

The lighter 25-second tests on the game and symptom pages use the HTTP probe pattern against the same nodes. Same engine, shorter session, no WebRTC requirement.

How every number is computed

Baseline — the median of your last 120 good samples

Your “normal” is the rolling median of the last 120 clean samples (about four seconds of traffic). Two deliberate choices. Median, not average: a median ignores the spikes themselves — if we averaged, a lagspike would drag its own reference line upward and smaller follow-up spikes would escape detection. 120 samples, rolling: enough to be statistically stable, short enough to adapt when your line genuinely shifts (a different node, a different route, evening congestion becoming your new normal). Everything else — spikes, verdicts, per-game readiness — is measured against this line, not against an arbitrary ms number.

Spike threshold — adaptive, not fixed

A sample counts toward a spike when it sits above baseline + a noise-aware margin (the margin scales with the median absolute deviation of your recent samples) and the elevation holds for at least half a second. Consequence: a rock-solid fiber line gets a tight threshold, a noisy satellite or fixed-wireless link gets a wide one — so we don’t cry wolf on lines where ±10 ms of wobble is simply the weather. Micro-bursts shorter than ~0.5 s are absorbed by game netcode and never counted as events.

Jitter, loss, outages, bufferbloat

• Jitter is the mean difference between consecutive good samples over the last 60 seconds — how much your ping is swinging, not how high it is.
• Packet loss is the share of probes that never returned within the measurement window — true UDP loss in GAME TRAFFIC mode, not an estimate.
• Outages are runs of consecutive lost probes, rendered as an up/down timeline with exact start and end timestamps.
• Bufferbloat is measured by the 8-second stress test: baseline latency first, then latency again while the line is deliberately saturated with download and upload traffic. The gap between the two is your queueing delay — the classic bufferbloat fingerprint the networking community has documented for over a decade (bufferbloat.net).

Warmup and verdicts

The first ~10 seconds of a session are calibration: raw numbers render immediately (the proof surface is never a void), but verdicts, spike events and scores wait for the baseline to be trustworthy. First impressions get a label (“looking stable so far…”), not a fake verdict.

Why a hidden tab shows a gap, not a spike

Browsers throttle or fully freeze timers in background tabs — that’s specified behavior, not a bug (W3C Page Visibility; the WebRTC transport itself is standardized by the W3C WebRTC spec and RFC 8831). If we kept timing probes while your tab was hidden, the browser’s freeze would look like a massive lagspike on your connection — a fabricated event in your evidence log. So LagScope stops measuring when the tab hides and draws an honest gap band on the chart instead. Your evidence report covers only time that was actually measured. We’d rather show “no data” than show a lie.

Limitations — what a browser cannot see

• We measure the path to our node, not to your game server. Your browser → ISP → backbone → our nearest node is most of the journey and shares the segments that usually break (your line, your ISP’s edge). In-game ping adds the last hop from our region to the game server, so treat our numbers as your connection’s floor. Spikes, jitter and loss found on this path show up in-game exactly as they are.
• We can’t look inside your router’s queue directly. Bufferbloat is inferred the same way every serious test infers it: load the line, watch latency, measure the rise. That’s a measurement, not a guess — but the queue itself (which device, which buffer) is diagnosed from its fingerprint, not from router internals.
• Wi-Fi vs Ethernet is visible only indirectly. We see the latency fingerprint of a noisy wireless link (spiky jitter, loss bursts that vanish on a cable) — we can’t read your signal strength or channel interference directly. The A/B method is how you prove it on your own line.
• Browser sandbox limits. No raw ICMP pings, no traceroute from the page, no measurement while the tab is hidden. Where those matter (hop-by-hop path context), the evidence guide shows how to pair LagScope with a desktop traceroute.

When NOT to use LagScope

LagScope diagnoses the network. It is the wrong tool, and will honestly tell you nothing, for:

• FPS drops and stutter — that’s your GPU/CPU, shaders compiling, or background processes. Your connection can be perfect and the game still hitch.
• Crashes, bugs, anti-cheat issues — game-side problems; no network tool sees them.
• Raw speed questions — “am I getting the 500 Mbps I pay for?” is a capacity question. Use a capacity test (Speedtest, fast.com); that’s what they’re built for. See how the tools compare.
• Offline/single-player performance — no packets, no diagnosis.

What real sessions look like

Three anonymized sessions, in the exact shape of a proof report — baseline, jitter, loss, events, score — and what each one meant:

Session 1 — “It’s not your internet”

The player was dying to “lag” in Valorant ranked. The connection was spotless for three quarters of an hour — the deaths were server-side hit-reg and a frame-time problem. A clean result is information too: it redirects the hunt to the PC or the game server instead of the ISP.

Session 2 — Wi-Fi with a full signal

Average ping looked fine; the game felt terrible. The jitter and the spike log told the real story. Same session re-run on Ethernet: baseline 19 ms, jitter 2.1 ms, zero spikes. One cable, problem gone — and the timestamped before/after is the proof it was never the ISP.

Session 3 — Fine until the house wakes up

Nothing wrong with the line itself — the router was queuing game packets behind 4K streams. SQM (Cake) at 95% of line rate, stress test re-run: +14 ms under load. The bufferbloat guide walks the same fix.

Lag in game? The 60-second decision path

1. Run LagScope for 15 minutes while you play (tab visible).
2. Clean result (no loss, no spikes, low jitter)? → Your connection is innocent — look at the game server (check their status), your PC (FPS drops aren’t lag), or the server region you’re matched into.
3. Packet loss >0? → Real packets dying. On Wi-Fi? Test on Ethernet first — half of all loss is the last 3 meters of air. Wired and still losing? That’s an ISP conversation — bring evidence.
4. High jitter but no loss? → The rollercoaster. Classic Wi-Fi interference or congestion — wire up, or test at a different hour to isolate.
5. Latency explodes only when the network is busy? → Bufferbloat. Run the 8-second stress test to confirm, then fix the queue — free, tonight, on the router you already own.
6. Spikes at the same hours every day? → Congestion pattern, upstream of you. Log it for a few evenings — repetition turns an anecdote into a ticket your ISP’s network team can act on.

Machine-readable proof

Every shared result (/proof/{id}) has a machine-readable twin at /api/snapshot/{id}: the session’s score, plain-language summary, baseline, jitter, loss and the full spike/outage event lists as JSON. Anyone — your ISP’s support, a forum skeptic, an AI assistant — can verify the numbers behind the card instead of taking a screenshot’s word for it.

Sources

Primary sources only — standards, and the game developers’ own engineering posts:

• W3C WebRTC 1.0 and RFC 8831 (WebRTC Data Channels) — the unreliable/unordered UDP transport GAME TRAFFIC mode uses.
• W3C Page Visibility API — why hidden tabs freeze and LagScope pauses instead of fabricating spikes.
• bufferbloat.net FAQs and RFC 8289 (CoDel AQM) — the queueing problem the stress test detects, and the algorithm family that fixes it.
• Riot Games — Peeking into VALORANT’s Netcode — 128-tick servers and Riot’s latency targets; the basis for the Valorant thresholds.
• Valve — Counter-Strike 2 (sub-tick) — “tick rate no longer matters for moving, shooting, or throwing”; why steady ping is forgiven in CS2.
• Respawn/EA — Apex Legends netcode deep dive — 20 Hz servers, lag compensation, and why loss breaks hit registration.