How VelocityVerify Measures Your Connection

A browser test observes the path between your device and the configured test endpoints. It does not measure every application, certify an ISP, or locate a fault by itself. This page describes measurement contract http-rtt-v1, used by new snapshots that include measurement evidence.

Download and upload

The test transfers data through HTTP endpoints and estimates transfer rate in each direction. Download and upload are separate phases. The worker has configured parallel stream counts and browser-specific adjustments; this is not evidence of an adaptive 4–12-stream algorithm or guaranteed saturation on every connection.

Device load, browser scheduling, the local network, endpoint behavior and the route can limit an observation. A transfer result is not the same quantity as an advertised access-line rate.

Idle latency: minimum after warm-up

The worker times successful HTTP completion with performance.now(). Its default ping sequence has ten attempts: one warm-up and nine estimator inputs. It retains the minimum after warm-up, not a median. The sequence is intended to precede the tool's transfer phases; it cannot establish that unrelated household traffic was idle.

The existing sub-millisecond rule remains: an estimate below 1 ms uses the previous estimate, then a 1 ms floor if needed. Stored idle samples are these transformed estimator inputs. They are not an untouched packet trace. HTTP timing includes more than wire propagation, and this browser test does not send ICMP or UDP probes.

Jitter: a smoothed RTT-difference estimate

For consecutive post-warm-up RTT inputs, the worker takes the absolute difference. The first such difference initializes jitter. Later differences above the current estimate use 0.3 × previous jitter + 0.7 × difference; otherwise they use 0.8 × previous jitter + 0.2 × difference. The displayed result is rounded to two decimal places.

This is not standard deviation, a percentile or a direct measurement of one-way packet delay variation. Read how to interpret this jitter estimate before comparing it with another tool.

Loaded latency: a mean delta, not a grade

During the download phase, a separate sampler makes at most five sequential HTTP attempts, with 150 ms between attempts. A loaded result requires five accepted probes, no exclusions, a valid idle baseline, and evidence that each probe started and finished inside the worker-recorded download window.

Displayed delta (ms) = max(0, round(arithmetic mean of the five loaded RTTs − idle estimate)).

This is not P90. The zero floor and whole-millisecond rounding are presentation conventions: a displayed zero does not prove the absence of delay variation. The sampler does not provide a separate upload-loaded result, a bidirectional worst-case grade, or proof that the link was saturated. Five probes are a limited observation, not a confidence interval.

New letter grades are withheld. Existing grades in local history or old shared links are legacy values, not validated router diagnoses. See the loaded-latency measurement details.

What is accepted, and when a result is absent

Latency probes require HTTP 2xx completion and finite, nonnegative monotonic elapsed time within the request budget. HTTP errors, network failures, timeouts, aborts, request exceptions, invalid timing and stale callbacks are not successful probes. Loaded probes crossing a phase boundary are excluded.

The engineering limits are 2,000 ms per request, 6,000 ms for loaded sampling, and 20,000 ms for the idle sequence. These limits bound waiting; they are not validated quality thresholds and may exclude very slow connections. Failed idle sequences terminate rather than retrying indefinitely. A run-wide loaded attempt budget cannot restart on UI updates.

Missing or invalid values are shown as unavailable, not converted to zero. A genuine numeric zero remains distinct. If the baseline, sample plan or phase evidence is insufficient, there is no loaded delta.

Endpoint and comparison limits

Requests use the site's configured test routes. The application does not document a separately managed rotating physical-node pool, independent bare-metal endpoints or a verified multi-CDN comparison. It does not establish that an ISP cannot identify test traffic.

The new timing basis uses full HTTP completion rather than the earlier Resource Timing substitution. Retaining an estimator does not make old and new observations automatically comparable. Keep the contract version, setup, endpoint and time with your results; compare repeated like-for-like runs and the application where the problem occurs.

History, sharing and privacy

New schema-version-2 snapshots include the measurement contract, timing basis, attempts, accepted inputs, exclusions and statuses. Complete loaded plans also retain relative probe spans and a phase window. JSON retains structured evidence; CSV includes measurement metadata. Shared values and local history are user-controlled, not authenticated measurements.

Older records can lack this evidence. A legacy grade must not acquire an invented delta, sample count or current date. No raw IP address or account identifier is added by this measurement contract. Optional server storage and general data handling are separate concerns: see the Privacy Policy.

Publisher and corrections

Younes Kirat : Publisher and maintainer. Hardware and editorial claims need their own evidence; this diagnostic method is not proof of a laboratory review. The testing policy and editorial policy explain these boundaries.

Editorial update: Earlier measurement claims were revised; unsupported claims remain withdrawn. See editorial corrections.