Explained: Why Your Internet Speed Is Almost Never What You Pay For.
Your internet plan says 100 Mbps. You start downloading a movie, a game, or a large software update, and the download window shows something like 11 MB/s. It is easy to look at that number and conclude that your internet provider is giving you only a fraction of what you paid for. But the first problem is much simpler: 100 Mbps and 100 MB/s are not the same thing. Internet connections are normally advertised in megabits per second, while operating systems and download applications often display megabytes per second. One byte contains eight bits, so a 100 Mbps connection has a theoretical maximum of 12.5 MB/s, not 100 MB/s. A 500 Mbps connection corresponds to 62.5 MB/s, and a 1 Gbps connection corresponds to 125 MB/s. That means if you have a 100 Mbps plan and a large download settles somewhere around 11–12 MB/s, your connection is actually performing quite close to what you paid for. The difference between 12.5 MB/s and the actual number comes from everything that has to happen around the data itself: network headers, protocol information, acknowledgements, encryption, retransmissions, hardware limitations, and the fact that the connection is almost never operating under perfectly ideal conditions. The first misconception is therefore that your internet plan is promising a certain number of megabytes per second. It isn’t. It is advertising a bandwidth capacity in megabits per second. The FCC itself distinguishes advertised bandwidth from theoretical capacity and notes that the advertised figure is intended to represent the downstream and upstream bandwidth an end user can reasonably expect from the service.
But even after correcting for bits and bytes, there is another important distinction: bandwidth is not the same thing as throughput. Bandwidth describes how much data a network connection can theoretically carry over a given period. Throughput describes how much data actually gets through. Think about a highway. If a road has ten lanes, those ten lanes represent its capacity. But the number of cars actually reaching the other end every minute depends on traffic, accidents, road conditions, merging, speed limits, and bottlenecks. Internet connections work in much the same way. Your ISP may provide a connection capable of 100 Mbps, but that doesn’t mean every application you use will always achieve 100 Mbps. Cloudflare explicitly distinguishes the two: bandwidth is the maximum amount of data that can pass through a network at a given time, while throughput is the average amount that actually passes through over a period. This distinction matters because the internet isn’t one enormous pipe connecting your laptop directly to a website. It is a collection of interconnected networks, routers, switches, physical links, wireless connections, servers, and protocols. Your data might travel from your laptop to your Wi-Fi router, from the router to your ISP, through several networks, across an exchange point, into another network, through a data centre, and finally to the server holding the file. The speed you experience is therefore the result of the entire path, not just the connection your ISP sells you.
The easiest way to see this is to imagine that your 500 Mbps fibre connection is connected to a router that is itself connected to your laptop using Ethernet. Everything looks ideal. Now replace that Ethernet cable with an older Wi-Fi connection and move into another room. Suddenly, the number can change dramatically. Wi-Fi has to deal with radio interference, distance, walls, competing devices, network overhead, and the physical limitations of the wireless standard being used. Intel notes that real-world Wi-Fi throughput can be substantially lower than the raw advertised data rate because of network overhead, environmental factors, interference, distance, obstacles, and congestion. Its documentation gives a broad estimate that the mechanisms needed to maintain reliable and secure wireless communication can reduce raw data rates by roughly 30–50%, even before environmental factors such as walls and distance are considered. This is why a router might advertise a wireless link rate of hundreds of megabits per second while an actual speed test on your phone produces much less. Your ISP may be delivering the bandwidth perfectly to your home; the bottleneck may exist entirely between your router and your device. And Wi-Fi is particularly interesting because the radio spectrum is shared. Your phone, laptop, television, smart speaker, tablet, and other connected devices are all competing for the same wireless resources. So when someone says, “I have a 500 Mbps connection but my laptop only gets 200 Mbps,” the answer isn’t automatically that the ISP is cheating them. The 500 Mbps connection and the 200 Mbps Wi-Fi throughput can both be completely real.
Even a wired connection doesn’t turn the internet into a perfect pipe because some of the data travelling across the network isn’t actually the file you’re trying to download. When you download a 1 GB file, your computer doesn’t send one enormous block of 1 GB through the network. The data is divided into smaller packets, and those packets contain information that allows the network to deliver them correctly. They need addresses, sequencing information, protocol information, and other metadata. You can think of it like shipping a thousand packages. The contents are what you care about, but every package also needs a label telling the delivery system where it came from and where it needs to go. Those labels consume a small amount of capacity, but without them the delivery system wouldn’t work. There can also be acknowledgements, retransmissions when packets are lost, encryption overhead, and other control information. The FCC has specifically recognised that data overhead, frame size, and hardware limitations can reduce measured throughput, noting that even a perfectly engineered gigabit network could ordinarily test somewhere around 940–987 Mbps rather than exactly 1,000 Mbps. This is an important detail because people often treat 1 Gbps as if it means exactly 1,000 Mbps of usable application data. It doesn’t. The network has to spend some of its capacity describing, protecting, transporting, and verifying the data.
Then there is latency, which is one of the most misunderstood concepts in internet performance. Bandwidth tells you how much data can move; latency tells you how long it takes for data to travel between two points. Imagine two roads. One is an enormous ten-lane highway that takes an hour to reach the destination. The other is a narrow two-lane road that reaches the destination in five minutes. If you’re moving a huge amount of cargo, the first road may eventually carry more. But if you need a quick response, the second road might feel much faster. Internet connections behave similarly. A 1 Gbps connection can have high latency, while a 100 Mbps connection can have much lower latency. Cloudflare gives a useful example of how geographical distance alone affects latency: a server roughly 100 miles away might respond in around 5–10 milliseconds, while a server roughly 2,200 miles away could have latency closer to 40–50 milliseconds, even before considering all the other delays introduced by network infrastructure. And those milliseconds matter because many things on the internet involve repeated communication between your device and a server. A webpage doesn’t necessarily consist of one enormous file that your computer downloads in a single uninterrupted stream. Your browser may need to make many requests, receive responses, establish connections, perform encryption handshakes, and wait for information before continuing. A fast connection with high latency can therefore feel slower than a slower connection with low latency, depending on what you’re doing.
This becomes even more interesting when you look at TCP, one of the protocols responsible for reliable communication across the internet. TCP doesn’t simply tell your computer, “You have a 500 Mbps connection, so send everything at 500 Mbps.” It has to constantly react to what is happening on the network. Packets can be delayed. Packets can be lost. Other users can suddenly start transmitting large amounts of data. Routers can become congested. TCP therefore uses congestion-control mechanisms to determine how aggressively it should send data. If the network appears healthy, it can increase the amount of data in flight. If it detects signs of congestion, it can reduce its sending rate. This is a crucial part of making the internet work because millions of independent devices are sharing infrastructure that has finite capacity. If every device simply transmitted as fast as physically possible without considering congestion, the network would quickly become overwhelmed. Cloudflare’s own engineering work illustrates how closely TCP throughput and latency are connected, particularly on high-latency links; its engineers have documented situations where TCP configuration choices can limit throughput as latency increases. The network isn’t merely asking how fast your connection can theoretically move data. It is constantly asking how fast data can be moved without making the communication unreliable or congesting the path.
Get the computer science teacher’s stories in your inbox
Join Medium for free to get updates from this writer.
Distance matters for another reason. Your internet provider does not own the entire path between you and every website you visit. The internet is a network of networks, with different companies and organisations operating different pieces of the infrastructure. When you request something from a server, packets may cross multiple networks before reaching their destination. Every additional network, router, exchange point, and physical link creates another place where delay or congestion can occur. Cloudflare notes that traffic crossing multiple networks has more opportunities to encounter delays and that routers at Internet Exchange Points have to process and route packets as they move between networks. This means that your ISP can be performing perfectly while a particular service still feels slow. Imagine your ISP is a highway that is completely empty, but the road connecting that highway to the destination is congested. From your perspective, the journey is slow, but the problem isn’t necessarily with the first road. The internet connection you buy is only one segment of the route your data takes.
The destination server can also become the bottleneck. Suppose you have a 1 Gbps connection. That gives you a theoretical capacity of 1,000 Mbps, or 125 MB/s before overhead. But imagine the server you’re downloading from can only send your file at 50 Mbps. Your computer can’t force that server to transmit at 1 Gbps. The server, its network interface, its upstream connection, its storage system, or the application itself may have limits. This is one of the reasons large internet services use content delivery networks, or CDNs. Instead of forcing every user to retrieve content from one distant origin server, a CDN can cache content at servers distributed across many locations, allowing users to retrieve it from infrastructure closer to them. Cloudflare explains that CDNs reduce latency by storing content closer to end users, reducing the physical distance data has to travel. This is why the same file can download extremely quickly from one location and much more slowly from another. Your connection may be capable of 1 Gbps, but the server still has to give you the data.
This also explains why two people paying for exactly the same internet plan can experience very different speeds. One person may have a fibre connection, a modern Wi-Fi 6 router, a laptop sitting two metres from the router, a nearby CDN server, and very little congestion. Another person may have the same 500 Mbps plan but use an older Wi-Fi device through several walls, share the connection with six other devices, connect to a distant server, and experience interference from neighbouring networks. Both can truthfully say that they have a 500 Mbps connection. Their actual throughput can still be very different. The FCC’s broadband measurements make this distinction particularly clear. In its Thirteenth Measuring Broadband America report, based on data collected in 2022 and published later, the FCC found that eight of 12 ISP/technology configurations met or exceeded their advertised download speeds, while the remaining four delivered between 86% and 90% of their advertised download speeds. In other words, the assumption that internet providers universally deliver only a small fraction of advertised speeds isn’t supported by those measurements. Under the FCC’s testing conditions, many providers were actually delivering speeds close to or above what they advertised. The bigger issue is that your personal experience is measured at the end of a much larger chain, where Wi-Fi, devices, servers, routing, congestion, and latency all become part of the equation.
And this is why a speed test is not really measuring “the speed of the internet.” It is measuring the performance of a particular connection between your device and a particular test server at a particular moment. A good speed-test provider deliberately designs its infrastructure to generate enough traffic to exercise your connection. It may use multiple simultaneous connections and a nearby server so that the test isn’t accidentally measuring the limitations of one slow server. The FCC’s broadband testing methodology similarly uses controlled measurement infrastructure and multiple concurrent connections when assessing broadband performance. (FCC Docs) So when your speed test says 100 Mbps, the meaningful interpretation isn’t that every website on Earth can now send you data at 100 Mbps. It is closer to saying: under these conditions, this device was able to sustain approximately 100 megabits per second to this test infrastructure. That is useful information, but it isn’t a universal property of your internet experience. A website hosted on another continent, a busy gaming server, a slow download mirror, or a badly configured application can all behave differently.
The difference becomes even clearer when you stop downloading enormous files and start using ordinary websites. Suppose your connection is 1 Gbps. You click on a webpage and it still takes a second or two to become fully usable. That doesn’t mean your 1 Gbps connection is broken. The browser may have to resolve the domain, establish connections, perform TLS encryption, request HTML, download JavaScript, retrieve images, load fonts, execute code, communicate with APIs, and render the page. Some of those resources may be tiny. The problem is therefore not necessarily the amount of data. It can be the number of interactions and the time required for those interactions. Cloudflare’s documentation on TCP connections explains that repeatedly establishing connections introduces overhead and latency, which is why mechanisms such as persistent connections are used to reuse existing connections and improve responsiveness. This is why doubling your bandwidth doesn’t necessarily make a webpage load twice as quickly. If the page is waiting on a series of small requests and responses, giving those responses a larger theoretical pipe doesn’t eliminate the time required for them to travel back and forth. Bandwidth becomes increasingly valuable when you’re moving large amounts of data; latency becomes increasingly important when you’re waiting for many interactions.
There is another subtle point here: more bandwidth eventually stops making much difference. Imagine a video stream that requires 15 Mbps. If your internet connection can reliably provide 20 Mbps, increasing it to 100 Mbps doesn’t make the video itself five times better. The application only needs roughly the bandwidth required to deliver the stream, plus some margin for variation. The extra capacity can still be useful for other devices and simultaneous downloads, but the video doesn’t magically become five times faster. The same is true for ordinary web browsing. Going from 10 Mbps to 100 Mbps can be a dramatic improvement because large downloads complete faster and multiple activities can coexist more comfortably. Going from 500 Mbps to 1 Gbps may be much harder to notice for someone who mostly browses websites, watches streaming video, uses social media, and makes video calls. Internet speed has diminishing practical returns once bandwidth is no longer the main bottleneck. At that point, latency, Wi-Fi quality, device performance, server responsiveness, and network stability may matter more.
This is also why speed and quality are not interchangeable. A connection can have high download bandwidth but still perform badly for gaming or video calls if it has high latency, packet loss, or jitter. Cloudflare’s current internet-quality measurements explicitly consider latency, packet loss, download speed, upload speed, loaded latency, and jitter rather than treating download speed as the complete picture of network quality. Imagine playing an online game on a 1 Gbps connection. The game may only need a tiny amount of bandwidth compared with your available capacity, but it cares enormously about how quickly small packets travel and how consistently they arrive. A 50 Mbps connection with stable 10 ms latency can be far more pleasant for that application than a 1 Gbps connection with unstable latency and packet loss. The number that looks most impressive on your broadband bill isn’t necessarily the number that matters most to the application you’re using.
So when your internet provider sells you 100 Mbps, you aren’t really buying a magical guarantee that every download will show 100 MB/s, nor are you buying a dedicated 100 Mbps tunnel from your laptop to every server on Earth. You’re buying access to a network connection with an advertised capacity of 100 megabits per second. What you actually experience depends on what happens after that connection leaves the ISP’s edge: your router, your Wi-Fi or Ethernet link, your device, the packets and protocols carrying the data, TCP’s behaviour, the distance to the destination, the networks between you and the destination, congestion, the server’s capacity, and the application itself. Even under excellent conditions, protocol overhead means the usable number won’t perfectly equal the theoretical number; at gigabit speeds, the FCC has noted that technical constraints alone can make a perfectly engineered connection test below the headline rate. There is no single “internet speed” hiding somewhere inside your router. There is only the performance of a particular path, carrying a particular kind of traffic, between particular machines, at a particular moment.
That is perhaps the more interesting lesson behind the deceptively simple number on your internet bill. We like to reduce complicated systems to one number because numbers make comparison easy. 100 Mbps sounds like a property of your internet connection, but it is really a statement about capacity at one point in an enormous distributed system. The moment you actually use that connection, the data has to cross wireless links, cables, routers, networks, protocols, servers, and software. Each part introduces its own constraints. A 100 Mbps connection therefore doesn’t guarantee a 100 Mbps download any more than a ten-lane highway guarantees that every car will reach its destination at the maximum possible speed. The internet is not a pipe. It is a chain. And your real-world speed is determined not by the number printed on the first link, but by how efficiently the entire chain works together.
