Measurement methodology
Distinguish probe measurements, provider claims and display order before comparing regions and time periods. Pages may use different windows or published snapshots; check locations, sample counts and timestamps together.
Last revised 2026-09-14
Data sources
Measurements, claims and editorial information are different kinds of evidence.
- Probe measurementsTTFB · HTTP
- Latency and success rates come from recorded probe requests and their validation results. No valid samples means no measurement, not a substitute from provider claims or static values.
- Provider informationProvider-declared
- Node counts, prices, service regions and protection capabilities come from published provider profiles. An ordinary HTTP probe does not verify scrubbing capacity or production throughput.
Latency metrics
TTFB measures time to the first response byte. It is not ping latency or full page load time.
- Within one locationMedian
- Use the median of valid TTFB samples at that location and within the selected window to reduce outlier influence. Failed samples do not contribute latency but remain in the success-rate denominator.
- Comparing pagesMatch the scope
- Boards aggregate selected locations; provider pages may summarize a broader set of requests. The same provider can have different values across regions or observation windows.
Request success rate
Success rate describes collected request outcomes, not future availability or a provider SLA.
- Calculationsuccess / total × 100%
- Divide successful requests passing status and content validation by the total recorded requests. Timeouts, connection failures and validation failures reduce the rate.
- Sample coverageChecked per board
- Boards apply minimum sample requirements to providers and locations. Insufficient coverage is not 100% reliability and must not be filled with invented measurements.
Scores and display order
Calculated scores, calculated ranks and editorial display positions are distinct. Reordering a provider does not improve its measured performance.
- Metrics and weightsΣ weights = 100%
- Each board configures its own metrics, weights and candidates. Price, node or capability factors are provider information when used, not probe measurements.
- Editorial orderingMay be enabled
- The platform can adjust a board’s display order. Evaluate the calculated score, measured metrics and board explanation rather than inferring absolute performance from position alone.
Normalization and weighting
t = (x − min) / (max − min)
score↑ = t × 100 · score↓ = (1 − t) × 100
total = Σ(score × weight)
x is the metric value; min and max come from the same board’s candidates. Use 1 − t for lower-is-better metrics, otherwise t. Equal values receive 100; ratio-scaled metrics are log-transformed first. Weighted contributions are summed and rounded for display, so absolute scores across boards are not directly comparable.
Sampling and freshness
Measurements depend on active available probes, verified targets and completed jobs. Configuring a location does not mean it has produced data.
- Observation windowSee the board
- Each board aggregates its own observation period and locations. Compare matching regions, windows and metric definitions.
- Data freshnessActual timestamps
- Scheduling, measurement, snapshot generation and publication can occur at different times. A page revision date is not a measurement timestamp; use the data’s own time.
Known limitations
Use results to narrow your shortlist, then test on your own network and workload.
- Networks and regionsNot universal coverage
- Data-center probes do not represent every residential, mobile or carrier network. Results in one region do not establish results elsewhere.
- Workloads and protectionRequires specific testing
- Small-object HTTP latency does not establish large-file throughput, video start-up quality or DDoS capacity. Cache policy, origin, object size and attack type also matter.