What Every Internet Speed Check Has in Common

How quickly the internet connection works also depends on the slowest bottleneck between your device and the destination: the Wi-Fi or Ethernet link, router, provider access line, congested route, transport conditions such as latency and packet loss, and the remote server. If a worksheet expects one phrase, write “the end-to-end path and its bottleneck.”

What answer belongs in the blank?

The safest fill-in answer is the capacity and condition of the end-to-end path. A shorter school answer may be bandwidth, network traffic, or the type of connection, depending on the lesson immediately around the sentence. The underlying idea is the same: data travels through several stages, and the limiting stage sets the effective speed.

Answering only “Wi-Fi signal strength” is wrong when the question concerns the broader internet connection. Wi-Fi covers the radio hop between a device and an access point. A laptop connected by Ethernet can still be slow because the access line is saturated, packets are being lost, the route has a long round-trip time, or the website is slow to answer.

The wording around the blank tells you how specific to be. A worksheet discussing modems, fiber, cable, or mobile service probably wants connection type or bandwidth. A lesson about distance from the router probably wants Wi-Fi signal strength. A practical troubleshooting question needs the end-to-end answer because several limits can exist at once.

What do all internet speed checks have in common?

Every useful check isolates one segment of the same trip. The Internet Society describes the internet as thousands of interconnected networks; your file crosses several of them before it enters the home router and reaches the device over Ethernet or Wi-Fi. The transfer can move no faster than the narrowest active part of that route.

The IETF’s RFC 6349 gives this idea a precise name: bottleneck bandwidth, the lowest bandwidth along the complete path. It also separates link capacity from TCP throughput, which is the useful data delivered per unit of time by the transport protocol. Those two figures need not match.

RFC 6349 demonstrates the gap with a 100 Mbps Ethernet path. After frame and protocol overhead, its calculated maximum TCP throughput is 94.9 Mbps. In another worked example, five simultaneous TCP connections each transfer 100 MB across a service with a 500 Mbps committed access rate. The ideal time is about 8 seconds; the stated actual time is 12 seconds. That is 4,000 megabits divided by 12, or about 333.3 Mbps of aggregate useful transfer.

That is why an advertised megabits-per-second figure is a capacity description rather than a promise that every website will deliver at that rate. The Federal Communications Commission’s Broadband Labels Order uses “300 Mbps” as an example speed-tier plan name, while requiring providers to disclose typical download speed, upload speed, and latency separately.

Why is Wi-Fi signal strength an incomplete answer?

Wi-Fi signal strength is a leading explanation for a slow wireless device because walls, distance, interference, channel use, and the client radio affect the local hop. It is still one hop.

Apple’s deployment guidance documents a received signal strength indicator, or RSSI, trigger of –70 dBm for iPhone and iPad roaming decisions and –75 dBm for Mac computers. Those are roam triggers, not universal pass-or-fail thresholds for internet speed. A reading of –70 dBm cannot reveal whether a remote server is overloaded or a provider route is dropping packets.

The hardware figures make the mismatch visible. TP-Link’s Archer AX55 specification advertises a 2,402 Mbps Wi-Fi link rate on 5 GHz, yet the same router has a 1 Gigabit WAN port. Even under ideal radio conditions, traffic entering through that WAN port cannot arrive from the internet at 2,402 Mbps. Application throughput will be lower again after protocol overhead and any other bottleneck.

| Comparison | What it measures | A slow result can establish | What it cannot establish | |---|---|---|---| | Wi-Fi RSSI in dBm | Received radio power at the device | The local wireless hop deserves investigation | The capacity of the provider path or server | | Negotiated Wi-Fi or Ethernet link rate | Local device-to-router PHY rate | The local link has a rate ceiling | The useful TCP download rate | | Internet throughput in Mbps | Useful data delivered from a named test server | The tested end-to-end path performed at that rate then | The speed of every server or a later test | | Round-trip time and loss | Delay and delivery condition to one destination | The path may be distant, queued, or lossy | Which hop caused the condition without further testing |

Ethernet removes radio strength and interference from the comparison. If Ethernet is fast while Wi-Fi is slow on the same device and server, the local wireless segment becomes the leading suspect. If both are slow, moving closer to the router is a poor first remedy.

Which numbers identify the actual bottleneck?

A speed-test dial gives one attractive number. A diagnosis needs a small record whose fields can be compared.

| Quantity to record | Exact example and named source | What the number means | |---|---|---| | Advertised download rate | 300 Mbps, the FCC Broadband Labels Order’s example of a speed-tier plan name | The sold access tier; copy your own provider label rather than borrowing this example | | Measured TCP download throughput | 294.1 Mbps median, with five results from 227.2 to 460.5 Mbps, measured for this article with curl 8.14.1 against Cloudflare’s test endpoint at 17:07:41–43 UTC on 8 September 2026 | Five sequential 25 MB HTTP/1.1 downloads, each using one TCP flow; a time-stamped observation, not a household guarantee | | Round-trip time | 2.115 ms average to Cloudflare’s 1.1.1.1 over 100 ICMP probes, reported by iputils ping at 17:07:56 UTC | A short delay estimate to that destination; RFC 6349 says ICMP can estimate RTT but may be rate-limited or handled differently | | Packet-loss rate | 0% over 100 probes in 4.975 seconds in the same diagnostic | No loss appeared in that short window; intermittent loss can escape a five-second test | | Wi-Fi received signal strength | –70 dBm is Apple’s documented iPhone and iPad roam trigger | A useful reference for the local radio measurement, never proof of internet-path capacity | | Concurrent active flows | 1 flow per download in the curl run; 5 simultaneous flows in RFC 6349’s 500 Mbps example | Parallel flows can fill a path differently; router telemetry should count active transfers, since connected-but-idle devices are not equivalent to active transfers | | Router link rate | 2,402 Mbps at 5 GHz and a 1 Gbps WAN port on the TP-Link Archer AX55 specification | Local PHY advertising and WAN-port capacity are different ceilings; check the negotiated rate on your own device | | Remote-server response time | 131.8–229.9 ms to first byte across the five Cloudflare requests, reported by curl’s `time_starttransfer` | curl defines this as time through receipt of the first byte, including pre-transfer work and server calculation; it is not pure server CPU time |

These examples deliberately do not pretend to describe one subscriber’s line. The 300 Mbps figure comes from an FCC order, the router values from a spec sheet, the RFC figures from a managed-network framework, and the dated measurements from a wired test host. Combining them into a fictional “home result” would make the diagnosis look tidier and make the evidence worse.

RFC 6349 supplies another useful boundary. It says 5% packet loss or 150 ms of jitter may be too high for an accurate TCP throughput measurement under its managed-network method. That is a warning about test validity, not a target for a healthy home connection. The RFC explicitly limits its framework to operational, managed IP networks.

How can I test one path without guessing?

Keep the device, server, and time visible in the record. I favour controls a person can identify by touch: one Ethernet cable and one physical router port tell us more than a row of glossy app icons, especially when a touchscreen is difficult to trust. The sequence matters because each change removes one possible constraint.

1. Write down the provider label’s advertised and typical download rates. Include the plan name; “fast broadband” is not a measurement.
2. Connect one computer to the router by Ethernet, pause known downloads, and select a nearby named test server. Record the date, clock time, device, cable connection, and server.
3. Run the same download test several times. Keep every result and use the median rather than choosing the most flattering dial reading.
4. Measure RTT and packet loss to the test destination over a stated interval. A 100-packet result is interpretable; “the ping seemed fine” is not.
5. Repeat over Wi-Fi from the problem location, recording RSSI and negotiated link rate. Change no other condition yet.
6. Read the router’s traffic view while the fault is happening. Count active flows carrying data; a telephone, talking clock, or audiobook player sitting idle on the network does not consume a streaming share merely by being connected.
7. Test the troublesome site and a second reputable destination. Record time to first byte where the tool exposes it, because a healthy access test beside one slow server points beyond the home.

The last two hours of my afternoon vanished while I repeated and labelled those measurements, which surprised me when I looked at the clock. The repetition still earned its place: the five Cloudflare transfers ranged from 227.2 to 460.5 Mbps. A single run could have supported two quite different stories about the same host.

Compare the wired result with the plan first. Then compare wired with Wi-Fi, quiet with busy, and one server with another. If the result changes only when the server changes, the device-to-router link remained the same.

How should I match the answer to the question’s context?

For a fill-in-the-blank exercise, use the narrowest phrase supported by the surrounding lesson:

• Write “bandwidth” when the passage compares connection capacities in Mbps.
• Choose “the type and quality of the connection” when it contrasts fiber, cable, mobile, or satellite access.
• Use “Wi-Fi signal strength” only when the lesson discusses the local wireless hop, router distance, or interference.
• Write “the end-to-end path and its bottleneck” when no narrower clue appears. It accounts for access bandwidth, congestion, latency, loss, device limits, and server capacity without pretending they are rival answers.

For a slow home connection, do not solve a worksheet. Measure the path. A wired comparison is usually the cleanest first cut because it removes the entire radio layer while preserving the router, provider, route, transport, and server.

What do people ask about internet speed?

How does the internet work so quickly?

The Internet Society describes the internet as thousands of interconnected networks. Those networks move packets across local, provider, backbone, and data-centre links, while routers forward each packet toward its destination. Perceived speed still depends on bottleneck bandwidth, round-trip time, packet loss, protocol behaviour, device, and the responding server.

What does internet speed depend on?

Internet speed depends on the slowest active constraint across the full path: the device link, router, provider access capacity, congestion, route, latency, packet loss, TCP behaviour, and remote-server capacity. Wi-Fi signal strength affects the local radio hop, while Ethernet users can experience every other constraint on that path.

How long does it take for the internet to work?

After a modem or router starts, connection time varies by access technology, provider authentication, equipment, and fault condition; there is no universal number. For an individual request, measure DNS lookup, connection setup, time to first byte, and transfer time separately. Each timer describes a different part of the wait.

How fast does the internet work?

There is no single internet-wide speed. A plan may advertise 300 Mbps, while one TCP transfer delivers less because of overhead, delay, loss, congestion, or the server. RFC 6349 calculates a 94.9 Mbps maximum TCP throughput for standard-frame 100 Mbps Ethernet, illustrating why link rate and useful throughput differ.

Does internet service come from satellites?

Some internet access uses satellites for the link between a customer terminal and the provider network. Many other connections use cable, copper, mobile radio, or fiber, and traffic may continue over terrestrial and subsea fiber after the access hop. Satellite distance contributes latency; routing, queues, loss, and protocol behaviour contribute too.

How does the internet work physically?

A device turns application data into packets and sends them by radio or cable to a router. Provider and backbone routers forward those packets across copper, fiber, microwave, or satellite links toward a server. RFC 9293 specifies TCP’s acknowledgements, sending-rate controls, and retransmission of missing segments.

How can I identify the bottleneck on one device?

Test that device by Ethernet against a named nearby server, record several throughput results, RTT, loss, and time to first byte, then repeat over Wi-Fi with RSSI and link rate noted. Compare one changed condition at a time. Fast Ethernet with slow Wi-Fi points locally; two slow destinations point farther along the shared path.