Common Mistakes People Make When Testing Internet Speed

Speed tests are easy to run wrong. Someone tests on a seven-year-old tablet over Wi-Fi from the far corner of their house at 9 PM while Netflix is streaming in the next room — then calls their ISP furious that their 500 Mbps plan is "only delivering 60 Mbps." Another person runs one test, gets a bad number, and calls to cancel service. Speed tests are simple tools, but they're easy to misuse. This guide covers the ten most common mistakes and how to fix each one.

Mistake 1: Testing Over Wi-Fi Instead of a Wired Connection

This is the single most common error. It causes a huge number of needless ISP complaint calls. When you plug an Ethernet cable from your router or modem into your computer, you get a clean, direct measure of what your ISP actually delivers to your home. When you test over Wi-Fi, you're measuring a mix of your ISP link, your router's radio quality, the distance from the router, walls and signal problems in between, and whatever other devices are competing for airtime on the same channel.

Wi-Fi is a shared medium. Every device on the same 2.4 GHz or 5 GHz band takes turns. Your neighbor's router might be on the same channel. The microwave in your kitchen kills 2.4 GHz signals for a second or two while it runs. None of this shows up in your ISP contract. Your ISP delivers signal to the coax or fiber at your wall. What happens after that is your gear's job.

A customer with a genuine gigabit fiber link can easily see 200–300 Mbps on a speed test if they're testing on the 2.4 GHz band three rooms away. The ISP isn't to blame. The Wi-Fi is. Always test with a wired Ethernet link when you want to measure what your ISP delivers. If you don't have an Ethernet port on your device, buy a USB-C or USB-A to Ethernet adapter — they cost about ten dollars and let you run a real test.

The only time you should test over Wi-Fi is when you want to measure Wi-Fi speed in a given room. Even then, label it as a Wi-Fi test — not an ISP test.

Mistake 2: Running the Test With Other Devices and Apps Active

Your internet link is a pipe. When you run a speed test, you want the pipe as empty as possible so the test can fill it and measure maximum throughput. If other things are using the pipe at the same time, the test shares capacity with them and reports a lower number.

The common offenders that people forget about are:

• Cloud backup services like iCloud, Google Drive, Dropbox, or OneDrive syncing files in the background
• Windows Update or macOS software updates downloading in the background
• Another TV or device streaming video in the house
• A game console that decided to download a 40 GB patch at 2 AM — which is still running when you test at 8 AM
• A smart security camera system uploading footage to the cloud
• Other browser tabs with video content auto-playing

Before running a test, take 60 seconds to pause cloud sync apps, check that no large downloads are in progress, and ask anyone else in the house to stop streaming for two minutes. This isn't about getting an high number — it's about getting an accurate baseline. If you want to test under normal load, that's a different kind of test and should be labeled as such.

Mistake 3: Running One Test and Treating It as Definitive

A single speed test is a snapshot. It captures what happened on your link for about 15–30 seconds at one specific moment. Network conditions change all the time. Congestion at your ISP's peering point can come and go in minutes. A test server you hit at 10:01 AM might be under heavy load at 10:02 AM. Your router might have had a brief CPU spike during the test. Any of these things can make one test look worse or better than it really was.

Run at least three to five tests back-to-back, then look at the range. If four of five tests show 450–480 Mbps and one shows 200 Mbps, the outlier is interesting — but it doesn't define your link. If all five tests show 200 Mbps when you're paying for 500 Mbps, that's a pattern worth looking into. The average and the consistency tell you far more than a single data point.

For a really accurate picture, spread your tests across different times of day over several days. But at minimum, run three tests in a single session before drawing any conclusions.

Mistake 4: Testing at Peak Hours and Comparing to Your Plan Speed

Cable internet uses shared lines in your neighborhood. The bandwidth on the coaxial cable serving your block is divided among all users on that node. During peak hours — roughly 7 PM to 11 PM on weekdays — everyone gets home, starts streaming, and hammers that shared segment at once. The result is congestion. Speed tests during those windows will show lower numbers than your plan's rating.

This doesn't mean your ISP is cheating you. The "up to" language in ISP contracts exists partly because of this shared model. A plan rated at "up to 500 Mbps" might give 480 Mbps at 2 AM and 220 Mbps at 9 PM on a Tuesday. Both numbers are real. The 2 AM number better shows what the link can do on its own. The 9 PM number shows what you get when your whole neighborhood is online at once.

That said, severe congestion that cuts your speed to 20% of rated capacity every evening is a real complaint. Test at off-peak hours first to set your baseline, then test at peak hours to measure the difference. If your 500 Mbps plan gives 460 Mbps at 3 AM but only 40 Mbps at 9 PM, that's a real problem worth escalating. If it gives 460 Mbps at 3 AM and 350 Mbps at 9 PM, that's fairly normal.

Mistake 5: Using the Wrong Test Server

Most speed test tools auto-pick the server with the lowest ping — usually the closest one. That's a fine default for measuring latency, but it doesn't tell the whole story.

If you always test against your ISP's own speed test server or one your ISP connects to directly, you might get numbers that are higher than what you'd see accessing content on a different network. ISPs sometimes over-provision traffic to speed test servers to make their service look good.

On the flip side, if the auto-selected server happens to be having problems that day, your test will show lower speeds that have nothing to do with your ISP or home setup. Try running tests against two or three different servers. Numbers will be lower to distant servers because of extra routing hops. But comparing results across servers in the same city can help you spot when one server is the outlier — not your link.

For the most neutral picture, use a test that routes through well-known neutral infrastructure. Fast.com uses Netflix's servers, which are spread across major CDN locations. Ookla lets you manually pick servers. Running both and comparing is a reasonable approach.

Mistake 6: Testing From a Slow Device

The device you test from has its own speed ceiling. An old Android phone from 2016 has a Wi-Fi chip that can't process data faster than 80–100 Mbps, even if it's one foot from a gigabit router on a gigabit link. A budget laptop with an older 802.11n adapter will top out around 150 Mbps no matter what your ISP delivers. If you run a speed test on that device and see 90 Mbps, the bottleneck is your device — not your internet plan.

The CPU on the testing device also matters. Speed tests need the device to process a lot of data quickly. On an older or underpowered chip, the CPU can hit its limit before the network does. This is true on phones and tablets where background processes compete for CPU time.

Always use the fastest, most capable device you own for speed testing — ideally a modern desktop or laptop connected via Ethernet. If you only have phones and tablets, use the newest one and connect it as close as possible to the router. Or use a USB Ethernet adapter. The results you get on your best device give the most accurate picture of your ISP link.

Mistake 7: Confusing Mbps With MB/s

This is a math problem that causes a huge amount of frustration. The "b" in Mbps stands for bits. The "B" in MB/s stands for bytes. There are 8 bits in a byte. A 100 Mbps link delivers roughly 12.5 megabytes per second of actual file data — not 100 megabytes per second.

When you open a download manager, a torrent client, or a file transfer dialog, the speed shown is almost always in megabytes per second (MB/s). A customer on a 100 Mbps plan who sees their download manager top out at 11–12 MB/s is getting exactly what they paid for. When they see 12 MB/s and expect 100 MB/s, they call in thinking they're getting 12% of their plan. They're actually getting about 96% of it.

There's also a little overhead from TCP/IP protocol headers that eats a small slice of your bandwidth. In practice, you often see 90–95% of the theoretical maximum in real transfers, so the numbers above are realistic upper bounds rather than exact figures.

When you see slow file downloads, first convert the speed test result to MB/s by dividing by 8. If your download manager is hitting around that number, your link is working correctly. The issue is either the server you're downloading from or the single-thread speed of that particular download.

Mistake 8: Trusting a Single Speed Test Site Without Cross-Referencing

Different speed test services measure different things, use different servers, and apply different testing methods. Ookla's Speedtest.net uses its own global server network and runs multiple parallel TCP streams to saturate your link. Fast.com uses Netflix's CDN servers and focuses on download speed only. Google's built-in speed test uses Measurement Lab setup. Each one can give you a different number — and all of them can be correct given what they're measuring.

A 30% difference between Ookla and Fast.com is not unusual and doesn't mean one is broken. It often means your ISP has a direct, high-capacity link to Ookla's servers but routes through a congested peering point to reach Netflix's CDN. That difference is actually useful info. It tells you that your raw link is fast but that traffic to specific services might be throttled or under-provisioned.

Run tests on at least two different services and note the results. If both show similar numbers, you have a reliable reading. If they differ a lot and always, that tells you something about your ISP's network — how well they connect to different parts of the internet, not just their own setup.

Mistake 9: Not Closing the Browser Tab Between Tests

Speed test sites that run in a browser use HTTP/HTTPS links. Modern browsers are very good at reusing established links. When you run a second test in the same browser tab without refreshing, the browser may reuse a TCP session that was already warmed up from the previous test. Warm TCP links skip the slow-start phase where the protocol gradually ramps up its sending rate. This can make the second and third tests look faster than they really are.

The browser may also cache some test assets, reducing the overhead of setting up the test. Some speed test tools also use the first test run to calibrate later tests, which can push results higher over repeated runs in the same session.

The fix is simple: close the tab and open a fresh one between tests. Or use the desktop app version of Speedtest.net, which doesn't have this browser caching issue. If you run multiple tests in sequence, refresh the full page before each one rather than just clicking "retry" or "run again."

Mistake 10: Drawing Conclusions From One Day of Testing

Your internet link isn't static. ISPs do maintenance, upgrade gear, adjust routing, and deal with hardware failures. Your neighborhood node may be getting rebalanced. A fiber cut upstream might be causing rerouting. A new apartment building down the street might have added 200 users to your cable segment last month.

A single day of testing gives you a snapshot of that day. Your link might test great that day and be mediocre all week. It might test poorly because of a short-term issue that resolves by morning. One bad day doesn't prove your ISP is failing you. One great day doesn't mean you shouldn't look into a complaint.

Seven days of tests at consistent times — a wired test at 8 AM and another at 9 PM every day for a week — gives you a real picture. You'll see the pattern of peak-hour drops, whether mornings are usually better than evenings, and whether the problem shows up on weekdays only or weekends too. That's the data you need when you call your ISP with a real complaint. "I tested once and got a bad number" won't get you far. "Here are 14 data points showing my link drops to 15% of rated capacity every evening between 7 and 11 PM" gets attention.

Summary: How Each Mistake Affects Your Results

Not all mistakes are equally damaging to test accuracy. Some throw off your results by a small margin. Others can make a gigabit link look like a DSL line. The table below shows the estimated impact of each mistake on your final speed test reading.

How Much Each Mistake Can Skew Your Results

The chart below shows the upper-end percentage error from each major mistake. These are realistic maximums — your specific situation may be worse or better if on your setup.

The Correct Testing Setup - A Visual Checklist

Before you run a test you intend to act on, your setup should look like this:

The Correct Testing Protocol: Step by Step

If you want results you can actually act on, follow this sequence. It takes about ten minutes the first time and five minutes after that.

Device Type vs. Expected Maximum Speed

Before assuming your ISP is underdelivering, check what your device is capable of. The table below shows realistic speed ceilings for common device types. If your speed test result is near these maximums, the bottleneck is your device — not your plan.

How to Tell if Your ISP Is Actually at Fault

After running a proper testing protocol, you'll have enough data to make a real judgment. Here's how to read what you find.

Signs Your ISP Has a Problem

Your ISP is likely the source of the issue when these patterns appear often across your testing data:

• Speeds are far below plan at off-peak hours on a wired link from a capable device. Off-peak, wired, capable device — if all three conditions are met and you're still at 30% of rated speed, that points to the ISP's network.
• Speeds drop a lot and reliably every evening. A consistent drop to 15–30% of baseline every day from 7–11 PM is a sign of node congestion. Occasional drops are normal. Daily, severe drops are a known problem they haven't fixed.
• Both Ookla and Fast.com show similar low numbers. When two different test services using different server setups both show poor results, the common factor is your link — not a server issue.
• Packet loss appears during the tests. Speed test results that jump wildly within a single test session are a sign of packet loss or signal issues. This is almost always the ISP's job to fix on a fiber or cable link.
• Speeds are consistently low on all devices. If your phone, laptop, and desktop all show the same poor result on a wired link, no single device is the bottleneck.

Signs the Problem Is Your Local Setup

The issue is on your side of the wall when:

• Wired tests show plan speed but Wi-Fi tests show low numbers. Your ISP is delivering. Your Wi-Fi network isn't spreading it well.
• Only one device tests slowly. That device has a hardware limit or software issue — update its network adapter drivers, check for background apps, or accept that it's an older device with a speed ceiling.
• Off-peak wired tests show plan speed but evening tests are low. This is shared network congestion. It may be your ISP's node being over-subscribed, but it's normal for cable internet. Contact your ISP only if the evening drop is severe (below 25% of baseline) and consistent.
• Speeds improved after you restarted the router. Routers build up memory leaks and connection table buildup over time. A router that hasn't been restarted in three months can slow down throughput. Restart your router monthly.
• Ookla shows plan speed but Fast.com shows much less. Your ISP delivers well to their own setup and to speed test servers, but has a congested link to Netflix's CDN. This is a specific ISP-Netflix relationship issue — not a general speed problem. You can complain about it, but it affects that service only, not your overall link.

Building a Case Before You Call

If you're going to call your ISP with a complaint, gather the following before you pick up the phone. A support tech who gets this data on the first call will treat your ticket very differently from someone who just says "my internet is slow."

• At least five wired test results from off-peak hours showing consistent underperformance, with dates and times
• The same results from two different test services (Ookla and Fast.com)
• Confirmation that you tested from a modern device directly connected via ethernet — this removes the most common customer-side explanations the tech will offer
• A description of what "slow" actually means — is it the speed test numbers, a specific app, or general browsing? Specific is better than vague

If your data is solid, ask the tech to check signal levels on your line and whether your node is over-subscribed. These are specific, answerable questions. If the tech can't explain the gap with a technical reason after checking line checks, escalate to a tier-2 tech or request a field visit. A field tech can measure signal at your modem and at the tap on the street. This shows whether the problem is inside your house or outside it.

The speed test is a starting point, not the whole story. Use it correctly — with a wired link, a capable device, multiple runs, off-peak timing, and a week of data — and it gives you a reliable picture of what your link is actually doing. Use it wrong, and it tells you nothing useful. Get the setup right first, and the numbers will tell you what you need to know.