Why Do Speed Test Results Vary?

Two speed tests run a minute apart can give different numbers. Run the same test on two devices and the gap can be larger. Use a different speed-test website and the gap can be larger still. None of this means anything is broken — but it does mean that one number from one test, taken in isolation, is not a great representation of "how fast your internet is".

This article explains the genuine sources of variation, separates "noise you can ignore" from "signal worth investigating", and gives you a way to test that produces results you can actually compare over time.

What a speed test is really measuring

A browser-based speed test downloads files from one or more servers and times how long that takes. Latency is measured by sending small requests and measuring the round-trip time. Upload, when measured directly, sends bytes the other way and times them. Each of those measurements involves a chain of components — your device, your Wi-Fi or Ethernet, your router, your modem, your provider's network, the path across the internet, and the test server itself. The number on screen is the speed of the slowest link in that chain at the moment of the test.

That is why "the speed test" can disagree with itself. The slowest link is not the same from one run to the next.

Sources of variation, in roughly the order that matters

1. Wi-Fi between you and the router

Wi-Fi is by far the largest source of variation in everyday testing. The signal strength changes when someone moves through the room, when a microwave turns on, when a neighbour's network shifts to the same channel, or when your laptop decides to switch antennas. A test from the kitchen and a test from the sofa, on the same plan, can land 100 Mbps apart.

If you want to measure your line speed, plug the device into the router with a cable. If you want to measure your Wi-Fi setup, test wirelessly — but accept that those numbers will move around.

2. The test server

Every speed test downloads from somewhere. CheckMySpeed uses files hosted on public CDNs (Cloudflare and similar). Other tests use dedicated servers in specific cities. Two factors come from this:

• The geographic distance between you and the server affects latency, and on slower lines indirectly affects download speed too.
• The server itself has a cap. If you are on a 2 Gbps line and the test server only serves 1 Gbps, you will measure 1 Gbps no matter what your line can do.

This is why a 5 Gbps fiber connection can show "only" 1.5 Gbps in a browser test and still be working perfectly.

3. Time of day on a shared medium

Cable and fixed-wireless connections share capacity at the neighbourhood or cell level. At 9 AM the segment is mostly idle; at 8 PM it is shared with everyone watching streaming TV. A 30–40% evening dip on cable is normal behaviour, not a fault. Fiber lines are far less affected by this.

4. Your device and browser

Speed tests run inside a browser. The browser has to schedule the network requests, decode the data, and update the page — all of which uses CPU. On a slow or busy laptop, the bottleneck can be your computer rather than your line. Closing other tabs, plugging in to power, and rerunning the test often nudges the result up by a noticeable amount on lower-end machines.

5. Background bandwidth use

Cloud sync, software updates, video calls in another room, smart-home backups, a torrent client you forgot about — anything that is moving bytes will reduce what is left over for the test. Many "why is my speed so slow today?" questions resolve themselves when the user spots a 30 GB system update running in the background.

6. Wi-Fi channel and band

The 2.4 GHz band is slower and more congested than 5 GHz, but it travels further. If your phone connected over 2.4 GHz because it is far from the router, you will measure low numbers even though the line itself is fine. Most modern routers support both bands; checking which one a device is on is often more useful than rerunning the test.

7. The protocol used to measure upload

Some tests measure upload directly by sending bytes back to a server. Others — including CheckMySpeed — estimate upload based on connection characteristics, because measuring it directly requires a server to receive and discard those bytes. Estimates and direct measurements can disagree, especially on highly asymmetric connections like cable.

8. Routing across the internet

The path between your provider and a test server is not fixed. Maintenance, peering changes, or congestion at an exchange point can route traffic differently from one test to the next. Most users never see this, but it is a real source of variability for tests over long distances.

Worked example: reading a sequence of tests

Say you are on a nominal "200 Mbps cable" plan and you run four tests:

What does this tell you?

• Your line works. The wired morning test is at ~95% of the headline plan speed.
• The evening dip is the shared medium. -25% in the evening is unremarkable for cable.
• Wi-Fi is the bigger story. Going from 142 wired to 86 wireless on the same evening is a Wi-Fi problem, not an ISP problem. Try a different room, or move to 5 GHz, before complaining to the provider.
• Latency is healthy. Single-digit-to-low-twenties ms on cable is normal.

The lesson: a single number is hard to interpret; a small set of numbers, varied across time and conditions, tells a real story.

How to make repeated tests comparable

If you want to actually track your connection over time, control the variables you can control:

1. Always test from the same device. A wired desktop is best.
2. Always use the same connection method. Wired or Wi-Fi from the same spot — do not mix them in your "is my speed dropping?" log.
3. Run three back-to-back tests and take the median, not the maximum or minimum.
4. Note the time and any other heavy users on the network. An evening result and a morning result are different measurements.
5. Repeat over several days before concluding anything. A single bad evening is not a pattern.

When the variation is actually a problem

Most variation is normal. The cases that warrant attention:

• Wired download is consistently and significantly below the headline plan speed at multiple times of day — likely an issue with your modem, cable, or the line.
• Latency is consistently above ~80 ms to nearby servers — could indicate routing problems or, on cable, signal-quality issues.
• Latency spikes dramatically when the line is in use — that is bufferbloat, and it has a specific fix.
• Sudden drop after working fine — restart the modem and router, then test again before contacting the provider.

Common mistakes when interpreting test results

• Comparing across different speed-test sites. They use different servers, different file sizes, different methodologies. Differences of 10–20% between tools mean very little.
• Cherry-picking the highest result. If you run the test five times and only quote the best one, you are measuring the best case, not the typical experience.
• Blaming the ISP for a Wi-Fi problem. Always rule out the wireless link first by testing wired.
• Ignoring that the test server has its own cap. Especially relevant on multi-gigabit lines.
• Forgetting that "Mbps" is megabits, not megabytes. A 200 Mbps line downloads at roughly 25 MB per second, not 200.

If your results vary a lot, in summary

For a refresher on what those download, upload and latency numbers mean in the first place, see Understanding Internet Speed. If your line is fine but the connection still feels slow, the next stop is bufferbloat — a specific failure mode that does not show up well in a normal speed test.