Interactive diagnostic
Internet stability test
Watch latency change over time instead of trusting one ping. Measure browser HTTP round-trip stability, p95 tail delay, jitter, spikes, and missed application probes over 15–60 seconds.
Browser RTT monitor
Run a connection stability test
Send small no-store HTTP probes about twice per second. Keep this tab visible and avoid changing networks until the run finishes.
This monitor times browser HTTP requests to one selected endpoint. A missed request is an application probe miss, not proof of network-layer packet loss. Browser scheduling, device load, HTTP/TLS behavior, the selected route, and server distance can all affect the result.
Transparent classification
How the stability label is assigned
The label is a SwiftSpeedTest editorial diagnostic, not a service-level certification. A run must have at least five attempts and five successful probes. It receives the first label for which every boundary below is met; anything above the Variable boundaries is labeled Unstable.
| Label | Application misses | Jitter | p95 above median | Latency spikes |
|---|---|---|---|---|
| Steady | ≤ 1% | ≤ 10 ms | ≤ 30 ms | ≤ 1% |
| Mostly Steady | ≤ 2% | ≤ 20 ms | ≤ 60 ms | ≤ 5% |
| Variable | ≤ 5% | ≤ 40 ms | ≤ 120 ms | ≤ 15% |
A spike is a successful probe above the run's median plus the greater of 30 ms or 75% of that median. The separate latency tier uses the median: Low ≤50 ms, Moderate ≤100 ms, High ≤200 ms, and Very high above 200 ms.
Measurement method
What the browser actually measures
- 1. Warm the path. One unreported request reduces the effect of initial connection setup on the recorded series.
- 2. Time small HTTP requests. The monitor uses the browser's monotonic Performance API clock and subtracts reported server processing time when that header is available.
- 3. Preserve tail evidence. The robust median resists isolated outliers, while p95, maximum, spike count, and discarded-sample count keep the unstable tail visible.
- 4. Count application misses. A request that times out, fails, or returns an error is counted separately. It is never relabeled as IP packet loss.
Controlled troubleshooting
Turn one unstable run into evidence
- Keep the device, endpoint, duration, and time window fixed; change only Wi-Fi versus Ethernet first.
- Repeat near the router and in the problem room to isolate wireless coverage or interference.
- Compare a quiet run with a busy upload or download. Use the bufferbloat test's loaded-latency grade for the intentional load comparison.
- Compare morning and busy-hour runs before blaming one device or provider. Export the per-probe CSV when escalating a repeated pattern.
Methodology sources
These references define the underlying concepts. SwiftSpeedTest applies them to an application-level browser diagnostic and states where the method differs from network-layer measurement. References checked 2026-07-24.
- Federal Communications Commission: Eleventh Measuring Broadband America Fixed Broadband Report
Defines latency and packet loss as distinct network-quality measurements and explains why latency affects interactive applications.
- Microsoft Learn: Use CQD to manage call and meeting quality in Microsoft Teams
Explains round-trip time, jitter, and packet loss as separate contributors to real-time media quality.
- IETF RFC 4689: Terminology for Benchmarking Network-layer Traffic Control Mechanisms
Defines jitter as delay variation between consecutive received packets and distinguishes it from loss.
- MDN Web Docs: Performance.now()
Documents the browser's monotonic high-resolution timer used to measure elapsed request time.
FAQ
Internet stability test questions
- What does the internet stability test measure?
- It sends small no-store HTTP requests to one selected SwiftSpeedTest endpoint about twice per second. It reports browser-observed round-trip time, p95 tail latency, jitter, latency spikes, and application-probe misses.
- Is this an online packet loss test?
- No. A browser fetch that times out or fails is reported as an application-probe miss. The test does not send ICMP or UDP packets and cannot prove network-layer packet loss. Use operating-system or purpose-built network tools when that distinction matters.
- How long should I run the test?
- Use 15 seconds for a quick check, 30 seconds for the normal baseline, and 60 seconds when drops are intermittent. Keep the tab visible and repeat under the same conditions before comparing results.
- Why can the stability result change by endpoint?
- Each endpoint follows a different network path and may be a different distance from the device. Compare the same endpoint when testing a router move, Ethernet cable, Wi-Fi band, or time-of-day change.
- Can a connection be steady but still have high latency?
- Yes. Stability describes variation and missed application probes, while the latency tier describes the typical delay. A distant or satellite path can be consistent but still too slow for a latency-sensitive use case.