A speed test is a short measurement that estimates the download throughput, upload throughput and latency of an internet connection by transferring test data between the user’s device and a nearby test server. In network performance, it is the most common way to check whether a mobile or fixed connection delivers what a plan promises.
A speed test measures the end-to-end path at one moment, not the access line alone. The result therefore reflects the device, the Wi-Fi or radio link, the operator network, the route to the server and the server itself, which is why two tests a few minutes apart can differ noticeably.
How a speed test measures a connection
A speed test runs in three phases: a latency measurement, a download phase and an upload phase. It first selects a server, usually the one with the lowest round-trip time, and sends a series of small packets to measure ping and jitter. It then opens several parallel TCP connections and transfers data as fast as possible for roughly 10 to 15 seconds in each direction.
Parallel connections are used because a single TCP stream often cannot fill a fast link, especially over long distances. Most tools also discard the ramp-up period while TCP is still increasing its sending rate, and report a figure based on the stable part of the transfer. Newer tools additionally measure latency under load, the delay observed while the link is busy, which reveals bufferbloat that an idle ping hides.
The table below explains the standard metrics a speed test reports.
| Metric | Unit | What it describes |
|---|---|---|
| Download speed | Mbit/s | Data rate from the server to the device |
| Upload speed | Mbit/s | Data rate from the device to the server |
| Ping (idle latency) | ms | Round-trip time on an unloaded connection |
| Jitter | ms | Variation in latency between packets |
| Latency under load | ms | Round-trip time while the link is saturated |
| Packet loss | % | Share of packets that never arrive |
Typical speed test results by connection type
Speed test results depend strongly on the access technology, and a reading is meaningful only relative to what that technology can deliver. The ranges below are typical real-world results rather than theoretical maxima, and they vary with plan, distance, load and equipment.
| Connection type | Typical download | Typical upload | Typical idle ping |
|---|---|---|---|
| 4G LTE | 10-100 Mbit/s | 5-40 Mbit/s | 25-60 ms |
| 5G mid band | 100-900 Mbit/s | 20-150 Mbit/s | 15-40 ms |
| DSL (VDSL2) | 20-250 Mbit/s | 5-40 Mbit/s | 10-30 ms |
| Fiber (FTTH) | Up to the plan rate, often 300-2,000 Mbit/s | Often symmetric | 2-10 ms |
| LEO satellite | 50-250 Mbit/s | 10-40 Mbit/s | 25-60 ms |
| GEO satellite | 10-100 Mbit/s | 1-10 Mbit/s | About 600 ms |
Mobile results fluctuate more than fixed ones because signal strength, cell load and distance to the base station change constantly. A fixed fiber line, by contrast, should deliver close to its contracted rate at most times, so a large shortfall there points to a local or configuration problem.
Factors that distort speed test results
A speed test result is distorted whenever a bottleneck other than the connection under test limits the transfer. The most common culprit on fixed lines is Wi-Fi: a fast fiber connection measured over a congested 2.4 GHz network may show a fraction of its real capacity.
| Symptom | Likely cause | How to rule it out |
|---|---|---|
| Speed far below plan on Wi-Fi only | Wi-Fi bottleneck | Repeat over an Ethernet cable |
| Low results at evening peak | Network congestion | Repeat at several times of day |
| Gigabit plan stuck near 940 Mbit/s | Ethernet overhead on 1 Gbit/s port | Expected; use a faster port to exceed it |
| Mobile speed drops after heavy use | Mobile data throttling | Check the plan’s fair use limits |
| Good speed, sluggish browsing | High latency under load | Check loaded latency, enable smart queue management |
| Very different results across apps | Server choice or method | Use the same server and tool for comparisons |
Device limits also matter: older phones, low-power laptops and browser-based tests on weak hardware can cap results below what the line delivers. Background updates, cloud backups and VPNs consume bandwidth or add detours, so they should be paused before testing.
Speed test compared with related measurements
A speed test is a snapshot of throughput, whereas several related measurements describe other aspects of performance. A ping test measures only latency, and signal strength readings such as RSRP describe the radio link without saying how much data it can carry.
For long-term assessment, operators and regulators rely on continuous monitoring with fixed probes or large numbers of crowdsourced tests, and some regulators provide certified measurement tools whose results can support a complaint when a fixed line repeatedly falls short of its contracted speed. A single user test is useful for troubleshooting but rarely sufficient as evidence.
How to run a reliable speed test
A reliable speed test isolates the connection and repeats the measurement under controlled conditions. The following practices produce results that can be compared over time or presented to a provider.
- Use a wired connection for fixed lines, with other devices idle.
- Run three to five tests and use the median rather than the best result.
- Test at different times, including the evening peak, to reveal congestion.
- Keep the same server and tool when comparing results over days or weeks.
- For mobile tests, note the location and signal level, because a few meters can change the outcome.
In everyday language
A speed test works like timing water through a hose. The tool pours a stream of data to the device and back again and measures how much gets through each second, and how long a single drop takes to make the trip.
The result depends on the whole path, not just the internet plan. A kink in the hose, such as weak Wi-Fi or a busy network, slows everything down, so one test is a clue rather than a final verdict.
Seen in the real world
A household with a 500 Mbit/s fiber plan complains that video calls stutter in the evening. A phone speed test in the living room shows only 80 Mbit/s download and a ping that jumps to 180 ms during the test.
The household connects a laptop directly to the router with a cable and repeats the test five times: the median result is 470 Mbit/s with a loaded latency of 25 ms. The line is fine; the bottleneck is the Wi-Fi, which uses a crowded 2.4 GHz channel through two walls. After moving the router and switching devices to the 5 GHz band, the living-room result rises to 320 Mbit/s and the evening stuttering disappears.