Internet speed test: how to actually get the speed you pay for

The short version

You pay for a certain internet speed, but your speed test came back lower. Usually the internet into your home is fine — the slowdown happens between your router and your device, most often over Wi-Fi. A few free changes fix most of it, and you can prove it with another test.

What's actually happening

Think of your internet like water coming into your house. The pipe at the street might be wide and fast. But if the hallway faucet is old, or you're measuring from three rooms away, you'll get a weaker trickle — even though the big pipe is fine.

A speed test measures the trickle that reaches the device you're testing on. So the result depends on where and how you test. Wi-Fi through two walls, an old phone, or five people streaming at once will all show a lower number than the plan you actually pay for.

Why it matters to you

• You may be paying for speed you never actually receive.
• Video and video calls buffer or drop to blurry.
• Big downloads and updates crawl.
• Without a fair test, you can't tell if the problem is your provider or your own setup — so you can't fix the right thing.

How to test it fairly first

Before changing anything, run one clean test so you know your true starting point:

1. Plug a computer straight into the router with a network cable (an Ethernet cable) if you can. This takes Wi-Fi out of the picture.
2. Close other apps, and ask others in the house to pause streaming for two minutes.
3. Run the speed test on this site. Write down the download and upload numbers.
4. Compare them to your plan. A wired result within about 10 percent of your plan means the internet itself is fine, and any slowness is happening over Wi-Fi.

As an Amazon Associate, WhoAmI earns from qualifying purchases.

How to fix it

Step 1: Fix the easy things (free)

1. Restart your router and modem: unplug both, wait 30 seconds, plug the modem in first, then the router.
2. Move the router out in the open — not in a cabinet, not on the floor, not behind the TV. Up high and central is best.
3. Test standing right next to the router. If it's fast there but slow in the bedroom, your problem is Wi-Fi range, not your plan.
4. On your phone or laptop, connect to the 5 GHz network (often named with "5G" in it) when you're close to the router. It's faster than the 2.4 GHz network, though it reaches less far.

Step 2: Make sure your gear can carry the speed

• A very old router (more than 5-6 years) often can't deliver today's plan speeds. A modern Wi-Fi 6 router helps a lot.
• If you rent a modem from your provider, check that it supports your plan's speed — ask them, or look at the sticker.
• An old laptop or phone may top out below your plan no matter what. That's the device, not the internet.

Step 3: Check your router's own speed setting

Some routers let you confirm the connection matches your plan. Here's where to look:

• ASUS: go to router.asus.com or open the ASUS Router app, and check the Network Map home screen for your connection status and speed.
• TP-Link: open the Tether app, tap your router, then look at the main status screen.
• Netgear: go to routerlogin.net or open the Nighthawk app and view the internet status.
• eero and Google Nest Wifi: open their app and run the built-in speed test (eero: Activity; Nest: Test Wi-Fi) to see the speed reaching each room.

Step 4: If Wi-Fi reaches far rooms poorly

If one router can't cover the whole home, a mesh system (several small units that blanket the house) usually beats a single router. For a desktop computer that gets weak Wi-Fi, a cheap plug-in Wi-Fi adapter or a run of Ethernet cable can fix it instantly. See the gear below.

How to check it worked

Run the speed test again from the same spot, the same way, after each change. A wired test should land within about 10 percent of your plan. If wired is good but Wi-Fi is still slow in far rooms, that points to range — mesh or a wired connection is the answer, not a new plan.

If your result was already good

If your speed test matched your plan, nothing is wrong — you're getting what you pay for. You don't need to buy anything. Just keep your router's firmware updated, re-test once a year, and re-test if you upgrade to a faster plan, since older gear can quietly cap a new, faster plan.

Want to go further?

Switch to the Advanced version for how to test correctly (server choice, single vs multi-connection), how to spot an overloaded modem, and how to tell a provider problem from a Wi-Fi problem with real numbers.

Is this your problem?

This guide is for anyone typing one of these:

• "Not getting the speed I pay for" on Xfinity, Spectrum, Cox or Frontier, or "internet slower than advertised." Run the test wired first — if wired is fast and Wi-Fi is slow, the bottleneck is inside your home, not the plan.
• "Is my internet being throttled?" Some ISPs speed up traffic to known speed-test servers so results look better than real life. The Honesty check compares a normal test against an ordinary web download your ISP cannot single out.
• "Is the Cloudflare or PS5 speed test accurate?" We explain exactly how the measurement works, and which Cloudflare data center you are testing against, so you can trust the number.
• "How to test Wi-Fi speed in different rooms," "wifi dead zones in house." The Watch mode's by-location panel grades each room so you can find the weak spot.

Summary

"Not getting my speed" is usually a measurement or last-meter problem, not a provisioning problem. Before escalating to your ISP, isolate the variable: test wired at the gateway, confirm your CPE can carry the plan rate, and only then look at Wi-Fi PHY, channel width, and client capability. Most shortfalls are Wi-Fi, client NIC limits, or a single-stream test method — not the access link.

What's actually happening

A speed test measures throughput between a client and a test server over a short window. The result is bounded by the weakest link in that path: the access link, the CPE (modem/router), the LAN medium (Wi-Fi or Ethernet), the client NIC, the client's CPU/TCP stack, and the test server's own capacity and distance. A "slow" result almost always reflects one of the middle links, not the provisioned downstream rate.

Two measurement artifacts dominate false negatives:

• Single-connection TCP ceiling. One TCP flow is limited by window size and RTT (throughput approximately equals window / RTT). On high-BDP paths a single stream can't fill the pipe; multi-connection tests can. Most browser speed tests use parallel streams by default — know which mode you're in.
• Server choice and distance. A congested or distant server understates throughput. Pick a well-provisioned server geographically near you and repeat on 2-3 servers.

Test correctly first

1. Test wired at the gateway. Connect a capable machine directly to a LAN port on the router (or modem, if bridged) with a known-good Cat5e/Cat6 patch cable. Confirm the link negotiated at the expected rate — on Windows, Get-NetAdapter | Format-Table Name,LinkSpeed; on macOS/Linux, ifconfig/ethtool. A 1 GbE NIC caps you at ~940 Mbit/s of TCP goodput; plans above 1 Gbps require 2.5GbE+ on both the port and the NIC.
2. Quiesce the LAN. Stop other heavy flows, or you're measuring contention, not capacity.
3. Run multi-connection and single-connection and note both. A large gap implies a BDP/windowing limit, not an access-link limit.
4. Repeat across servers and times of day. Evening-only shortfalls suggest access-network congestion (oversubscription) rather than your gear.

Isolate the bottleneck

CPE / access link

• DOCSIS: open the modem status page (commonly 192.168.100.1). Confirm channel bonding (downstream/upstream channel counts), modulation (QAM order / OFDM profile), downstream power (aim roughly -7 to +7 dBmV), downstream SNR/MER (ideally 35 dB+ for 256-QAM), and upstream power (typically under ~50 dBmV). A gateway with too few bonded channels or an under-spec DOCSIS version will cap you below plan.
• Confirm the modem supports the plan. A DOCSIS 3.0 16x4 modem cannot deliver a multi-hundred-Mbit plan the way a DOCSIS 3.1 modem can. Check your ISP's approved-device list.
• Fiber/GPON/XGS-PON and FWA rarely bottleneck at the ONT; suspect the router port speed and Wi-Fi instead.

Wi-Fi PHY

• Band and width: 2.4 GHz is congested and narrow; use 5 GHz (or 6 GHz on Wi-Fi 6E/7). Channel width matters most — 80 MHz on 5 GHz roughly doubles 40 MHz throughput, but needs a clean DFS/UNII range. 160 MHz helps if the client supports it and the spectrum is clean.
• Spatial streams: throughput scales with min(client, AP) streams. A 1x1 phone on an AX router still tops out at 1x1 PHY rates. MCS index and RSSI set the ceiling; thick walls drop you to lower MCS fast.
• Airtime contention: one legacy 802.11n client dragging the BSS down lowers everyone's effective rate. Segregate legacy devices or use band steering.
• Verify actual negotiated PHY rate at the client (macOS Option-click Wi-Fi menu; Windows netsh wlan show interfaces; Linux iw dev). The link rate is the ceiling; real goodput is ~40-60% of it.

Client

Old NICs (802.11ac 2x2, or GbE on a multi-gig plan), thermal throttling, VPNs, background sync, and security software can all cap results. Test from a second, modern, wired client to rule the machine out.

Router QoS / speed confirmation by vendor

• ASUS: router.asus.com → Network Map shows WAN status and negotiated rate; Adaptive QoS / Adaptive QoE for traffic management.
• TP-Link: Tether app or tplinkwifi.net → status page; HomeShield/HomeCare → QoS on supported models.
• Netgear: routerlogin.net or Nighthawk app → internet status; Dynamic QoS is off by default and requires entering/detecting your bandwidth.
• eero / Google Nest Wifi: app-based speed test (eero Activity; Nest "Test Wi-Fi" and "Test mesh") reports gateway and per-node throughput — useful for localizing a weak backhaul link.

Verify

Re-test wired after each change and confirm you land within ~10% of plan (accounting for TCP/IP overhead and the 1 GbE ~940 Mbit/s ceiling). For Wi-Fi, test per-room and record negotiated PHY rate + RSSI alongside throughput, so you're measuring link quality, not just one number. If wired matches plan but evening throughput still sags network-wide, document timestamps and open an ISP ticket citing congestion.

Edge cases & gotchas

• Double NAT from an ISP gateway plus your own router rarely limits raw throughput but complicates testing; bridge the ISP unit when possible.
• Multi-gig mismatch: a 2 Gbps plan needs 2.5GbE end-to-end — modem port, router WAN, switch, and client NIC. One 1 GbE link anywhere caps the chain.
• Powerline/MoCA backhaul can silently halve mesh throughput versus wired Ethernet backhaul.
• Thermal/CPU limits: cheap routers can't route at line rate with NAT + SQM enabled; the CPU, not the link, becomes the ceiling.

Reading the result like an engineer

Don't trust a single number. Record the full shape: parallel-stream throughput, single-stream throughput, idle latency, latency under load, and the test server used. A plan-matching parallel result with a weak single-stream result is a windowing/BDP artifact, not a fault — RWIN and congestion-control choice (CUBIC vs BBR) change the single-stream ceiling more than the link does. A result that's fine midday but collapses 8-11 pm points at access-network oversubscription at your segment or node, which is an ISP capacity problem, not your hardware.

Also sanity-check the units: ISPs sell megabits (Mbps) while file managers show megabytes (MB/s); divide by 8. A "500 Mbps" plan tops out near 62 MB/s of file transfer before overhead, and ~940 Mbit/s is the practical TCP ceiling of a 1 GbE port. If your wired result sits right at ~940 on a faster plan, you've found a 1 GbE bottleneck, not a slow ISP — the fix is 2.5GbE end to end, not a new plan.