Controlled before and after
Compare internet speed test results
Run a baseline, change one condition, and test again. Compare download, upload, idle and loaded response with transparent change guards and explicit warnings when the test conditions do not match.
Run a controlled before-and-after test
Run a baseline, change one condition, then repeat with the same device, endpoint, and context.
Optional context is saved with recent results and included only if you copy a share link.
Low-data measurement
Active because the browser cannot report connection quality. The time- and byte-bounded run requests at most about 52 MiB of test payload, and usually less. Protocol overhead may add a little more.
Test endpoint
Default Server - Nearest Location
Same-origin hosted endpoint
Endpoint readiness unavailable
Default endpoint is ready.
For a fair A/B comparison, change one condition and keep the device, endpoint, test context, and time window as consistent as possible.
Controlled comparison protocol
Make the before-and-after result interpretable
Network conditions move even when you change nothing. A useful comparison records the context, changes one variable, and treats the result as evidence to repeat—not as proof that the changed variable caused the difference.
1. Record the baseline
Choose the device, connection type, test endpoint, provider label, room or location, and use-case context.
2. Change one condition
Examples include Wi-Fi versus Ethernet, one router position, one supported band, or background traffic paused versus active.
3. Repeat the same test
Keep the device, endpoint, context, and time window as consistent as practical. The newest two results are selected automatically.
4. Repeat both conditions
For a purchase, provider dispute, or equipment decision, collect several runs per condition and inspect the median and spread.
Versioned method 1.0
Exact meaningful-change guards
A metric changes only when its absolute guard passes and, where listed, its relative guard also passes. These are SwiftSpeedTest editorial noise guards for a practical two-run screen. They are not confidence intervals and do not establish statistical significance.
| Metric | Better | Absolute guard | Relative guard | Measured value |
|---|---|---|---|---|
| Download speed | higher | ≥ 2 Mbps | ≥ 10% | Measured browser download throughput |
| Upload speed | higher | ≥ 1 Mbps | ≥ 10% | Measured browser upload throughput |
| Idle latency | lower | ≥ 5 ms | ≥ 10% | Retained median browser HTTP latency before load |
| Idle jitter | lower | ≥ 2 ms | ≥ 15% | Variation in retained idle browser HTTP latency |
| Worse loaded latency | lower | ≥ 5 ms | ≥ 10% | Worse retained median from the download-loaded and upload-loaded stages |
| Worse loaded jitter | lower | ≥ 2 ms | ≥ 15% | Worse retained jitter from the download-loaded and upload-loaded stages |
| Browser HTTP probe misses | lower | ≥ 1 pp | Not used | Difference in failed or timed-out browser HTTP application probes |
Aggregate verdict
Mixed evidence stays mixed
- Improved: one or more metrics meaningfully improve and none regress.
- Regressed: one or more metrics meaningfully regress and none improve.
- Mixed: at least one metric improves and another regresses.
- Similar: no metric passes its published guards.
- Retest before comparing: required evidence is incomplete or unverified.
Comparability check
Changed conditions remain visible
The app compares endpoint, connection type, provider label, location label, use-case label, loaded-response method, and test time. A mismatch is a caution, not an automatic excuse to discard the measurements.
Comparing Wi-Fi with Ethernet intentionally changes the connection condition. That can isolate a useful association, but the result still does not prove which router, radio, cable, adapter, port, route, or traffic source caused the difference.
Measurement sources
IETF guidance informs the emphasis on repeatability, consistent traffic patterns, and uncertainty under changing production conditions. The FCC technical appendix illustrates how a large-scale broadband measurement program documents controls, server selection, and methodology. SwiftSpeedTest separately publishes its own editorial change guards and limitations. References checked 2026-07-24.
- IETF: RFC 2330: Framework for IP Performance Metrics
Defines repeatability as a core measurement-method property and explains why uncontrolled path conditions create uncertainty.
- IETF: RFC 7312: Advanced Stream and Sampling Framework
Expands repeatability guidance, including consistent traffic patterns and the limits of assuming production-network conditions are identical.
- FCC: Measuring Broadband America technical appendix
Documents a large-scale fixed-broadband measurement program, including concurrent-traffic controls, server-selection considerations, and open methodology.
FAQ
Speed test comparison questions
- How do I compare two internet speed test results?
- Run a baseline, save its device, connection, endpoint, provider, location, and time context, change one condition, then run the same test again. The comparison tool selects any two locally saved results and shows metric changes plus condition warnings.
- How much difference between speed tests is meaningful?
- SwiftSpeedTest publishes metric-specific editorial noise guards. For example, download must move by at least 2 Mbps and 10 percent, while idle latency must move by at least 5 ms and 10 percent. These guards screen small changes; they are not a statistical-significance test.
- Can a before-and-after speed test prove what caused a change?
- No. It can show an association after a condition changed, but it cannot prove causation. Background traffic, Wi-Fi conditions, routing, endpoint load, device state, and time-of-day demand can also change.
- Why does the comparison say Retest before comparing?
- The overall verdict is withheld when either run lacks retained loaded responsiveness, full download and upload transfer confidence, distinct measured result IDs, or measured rather than editable shared values.
- Should I compare more than one run per condition?
- Yes for higher-stakes decisions. A two-run A/B screen is convenient but does not estimate natural variance. Repeat each condition several times, keep every result, and inspect the median and spread.
- Where are my comparison results stored?
- Recent measured results are stored in local browser storage on the device running the test. They are not uploaded as an account history. You can export the local history as JSON or CSV and clear it at any time.
- Are browser HTTP probe misses the same as packet loss?
- No. They are failed or timed-out application-level browser HTTP requests. The tool does not relabel them as ICMP, UDP, RTP, or network-layer packet loss.