--- title: "Latency vs Bandwidth: Why Round Trips Matter | Evaluat" description: "Latency vs bandwidth, explained for web pages: what each one measures, why faster broadband rarely makes a slow site fast, and what a site owner can change." url: "https://www.evaluat.com/blog/latency-vs-bandwidth" last_modified: "2026-10-03" --- [Blog](https://www.evaluat.com/blog) [Guides](https://www.evaluat.com/blog/category/guides) # Latency, bandwidth and round trips, explained Faster broadband does not make a slow website fast. Bandwidth is how much data a connection carries each second; latency is how long one trip takes. A web page needs dozens of small trips, so once a connection passes about 20 Mbps, the number and length of those trips decide the wait, not the size of the pipe. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 3 October 2026 [Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 10How a web page loads ![Two comparisons of where a page load's wait goes. Upgrading broadband from 100 Mbps to 1 Gbps cuts the transfer of a 2.6 MB page from 0.21 seconds to 0.02 seconds, saving about 0.19 seconds. Shortening each round trip from 140 milliseconds to 30 milliseconds cuts a page that needs ten round trips in a row from 1.4 seconds of waiting to 0.3 seconds, saving 1.1 seconds.](https://www.evaluat.com/blog/latency-vs-bandwidth-cover.svg) Summary Latency and bandwidth are two different limits on a connection. Bandwidth is how much data can flow each second, measured in megabits per second. Latency is how long a single trip takes, measured in milliseconds, and a round trip is the journey there and back. Web pages are mostly limited by latency, because loading one means many small exchanges, each of which has to wait for a reply before the next can start. That is why extra bandwidth stops helping quite early. A Google study in 2010 found that going from 5 to 10 megabits per second improved page load times by only 5 percent, and more recent research puts the point of diminishing returns at about 20 megabits. Average UK broadband is far beyond that, so for most visitors the pipe is not the problem. Round trips are, and they cannot beat the speed of light: a round trip across the Atlantic takes at least 56 milliseconds in fibre. A site owner cannot change a visitor's broadband, but can change how many round trips a page needs and how far each one travels, with fewer domains, modern protocols and a CDN. One more thing to keep apart: the word latency also describes how long your server takes to answer, and that is the kind that grows when your site gets busy. Listen to this article · 1:32 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/latency-vs-bandwidth.mp3) Key takeaways - Bandwidth is how much data flows per second; latency is how long one trip takes. - Web pages need many small round trips, so latency usually limits them more than bandwidth. - Beyond about 20 Mbps, extra bandwidth barely changes page load time. - Distance sets a floor: light in fibre needs at least 56 ms for a round trip across the Atlantic. - Site owners control round trips and distance through fewer domains, modern protocols and a CDN. - Server latency is a different thing, and it is the latency that grows under load. ## What is the difference between latency and bandwidth? Bandwidth is how much data a connection can carry each second. Latency is how long it takes for data to make one journey across it. Bandwidth is measured in megabits per second (Mbps) and latency in milliseconds (ms). A connection can have plenty of the first and still feel slow because of the second. A motorway is the easiest picture. Bandwidth is the number of lanes. Latency is the length of the road. Adding lanes lets more cars travel at once, but it does not shorten the drive. If your errand needs ten separate trips there and back, the length of the road decides how long your afternoon takes. That is the situation of a web page. A browser does not fetch a page in one long download. It makes a series of short exchanges, and many of them must wait for a reply before the next can begin. Each exchange is a round trip, and the round trips add up. | | Bandwidth | Latency | | --------------------- | ------------------------------------------- | --------------------------------------------- | | What it measures | How much data per second | How long one trip takes | | Unit | Megabits per second (Mbps) | Milliseconds (ms) | | What sets it | The visitor’s broadband or mobile plan | Mostly distance, plus the networks in between | | Helped by | A faster plan | A closer server, fewer trips | | Limits web pages when | The connection is slow or the page is heavy | Almost always on today’s connections | ## What is latency? Latency is the time data takes to travel from one point to another. MDN, the reference documentation for web developers, defines it as [the network time it takes for a requested resource to reach its destination](https://developer.mozilla.org/en-US/docs/Glossary/Latency). Low latency means little delay. It is measured in milliseconds, and for web traffic it is usually quoted as a round trip. A one-way figure is rarely useful on its own, because nothing on the web happens in one direction. The browser asks and the server answers. So the practical unit is the round trip time (RTT), which MDN describes as [the time it takes for a data packet to be sent to a destination plus the time it takes for an acknowledgment to be received back](https://developer.mozilla.org/en-US/docs/Glossary/Round_Trip_Time). When you run a speed test and it shows your ping, that is a round trip time. Several things add up to latency. The signal has to cover the physical distance. Each router along the way spends a little time forwarding it. If any link is busy, the data waits in a queue. Distance is the part nobody can engineer away, which is why where your server sits matters more than most people expect. The word has a second meaning that causes confusion. Engineers also use latency for how long a server takes to answer a request, which has nothing to do with the network. That kind of latency is covered further down, because it behaves very differently when a site is busy. ## What is bandwidth, and how is it different from throughput? Bandwidth is the maximum amount of data a connection can carry each second. Throughput is the amount it actually carries in practice. The gap between them comes from congestion, protocol overhead and, for web pages, all the time spent waiting on round trips instead of transferring data. Bandwidth is what broadband adverts sell, and in the UK it has grown fast. Ofcom’s Connected Nations report for 2025 found that [the average UK maximum download speed rose by almost 30% in a year, from 223 Mbit/s in 2024 to 285 Mbit/s in 2025](https://www.ofcom.org.uk/siteassets/resources/documents/research-and-data/multi-sector/infrastructure-research/connected-nations-2025/connected-nations-uk-report-2025.pdf?v=407947). That is a provider-reported maximum rather than a measured average, but the direction is clear. Pages have grown too, though much more slowly. The HTTP Archive’s 2025 Web Almanac puts [the median mobile page at 2.6 MB](https://almanac.httparchive.org/en/2025/page-weight). The arithmetic is simple. 2.6 megabytes is about 21 megabits, so at 100 Mbps the raw transfer takes about a fifth of a second. At 20 Mbps it takes about one second. Bandwidth still matters at the low end. On a weak mobile signal or a congested connection, a heavy page is slow for exactly the reason the adverts suggest. But for most visitors on most connections, the transfer itself is the short part of the wait. ## What is a round trip, and why do web pages need so many? A round trip is one message going out and its reply coming back. Web pages need many of them because each step of loading a page depends on an answer from the step before, and because a single page pulls files from several different servers. [Part 8 of this guide walked through the waits of a page load](https://www.evaluat.com/blog/how-a-web-page-loads). Before the first byte of a page arrives on a new connection, the browser has already spent one round trip opening the connection, one securing it, and one sending the request and receiving the start of the reply. Every additional domain the page uses costs the same setup again. Google’s guidance on connection hints notes that [the connection setup process might involve up to three round trips, and more in unoptimised cases](https://web.dev/articles/preconnect-and-dns-prefetch). Then the files themselves. [The median mobile page loads 68 requests in total](https://almanac.httparchive.org/en/2025/page-weight): 22 JavaScript files, 12 images, 8 stylesheets and more. Many can travel side by side over one connection, but some can only be requested after another has arrived, such as a font that is named inside a stylesheet. Even small files can cost several round trips. A new connection starts by sending a small amount of data and grows its pace with each acknowledgement, a mechanism called TCP slow start. A 2017 study of popular websites by researchers at institutions including Duke University, ETH Zürich and Akamai found that [with most pages at most tens of kilobytes, bandwidth was not the problem, but slow start meant even small transfers required several round trips](https://pbg.cs.illinois.edu/papers/bozkurt17why.pdf). Fetching just the HTML took, in the median, 37 times as long as light would need for the same round trip. ## Why doesn’t faster broadband make websites load faster? Because most of a page load is spent waiting on round trips, and extra bandwidth does not shorten them. Beyond a fairly modest speed, more megabits barely change page load time, while every millisecond cut from each round trip keeps paying off. The classic evidence is a 2010 study by Mike Belshe, one of the engineers behind the SPDY protocol that became HTTP/2. Loading 25 popular pages under controlled conditions, he found that [an increase from 5 Mbps to 10 Mbps amounted to a 5% improvement in page load times, while each 20 ms cut from the round trip yielded a 7 to 15% reduction](https://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/). Pages and protocols have changed since 2010, and the threshold has moved, but not the shape. Writing in 2023, Cloudflare noted that in more recent research [the point of diminishing returns to more bandwidth has moved higher, to about 20 Mbps, but the overall trend was exactly the same](https://blog.cloudflare.com/making-home-internet-faster/). Its own data showed that for every 200 milliseconds of latency saved, page load time fell by more than a second. Here is what that means in practice. Suppose a page needs ten round trips, one after another, before its main content appears. At 30 ms per round trip that is 300 ms of waiting. At 140 ms per round trip it is 1.4 seconds. Moving the visitor from a 100 Mbps plan to a 1 Gbps plan saves about a fifth of a second of transfer on a 2.6 MB page. Shortening the round trips saves more than a second. ## How fast can a round trip be? No faster than light in glass. Light in optical fibre travels at about 200,000 kilometres per second, roughly two-thirds of its speed in a vacuum, and distance converts directly into a minimum delay that no network upgrade can remove for any visitor. Ilya Grigorik’s reference text High Performance Browser Networking works the numbers through. Using [the rule of thumb that light in fibre travels around 200,000,000 metres per second](https://hpbn.co/primer-on-latency-and-bandwidth/), a round trip between New York and London, 5,585 km apart, takes at least 56 ms. Real routes are longer than straight lines and every router adds a little, so measured round trips are higher. The visitor’s own connection adds its share before the data even reaches the wider internet. Ofcom’s 2025 mobile report found [average 5G response times between 15 ms and 21 ms across the UK’s mobile networks, and 4G between 18 ms and 23 ms](https://www.ofcom.org.uk/siteassets/resources/documents/research-and-data/telecoms-research/mobile-matters/2025/mobile-matters-2025.pdf?v=400314). Those figures are one way, half of a round trip, and measured to the test server nearest the phone. If your website is served from another continent, everything beyond that nearest server comes on top. So where your server sits sets a floor under every round trip. A shopper near your origin pays a little for each one. A shopper an ocean away pays the floor many times over on every page. ## What can a site owner do about latency? You cannot change a visitor’s broadband or the speed of light, but you can change how many round trips your pages need and how far each one travels. Those two levers cover most of the latency a site owner controls. **Make fewer round trips.** - Use fewer domains for critical files, because every new domain pays connection setup again. - Serve over HTTP/2 or HTTP/3, which let many files share one connection, with TLS 1.3, which secures a new connection in one round trip. - Reference important files directly in the HTML, so the browser does not discover them late. - Where a third-party domain is unavoidable, warn the browser early with a preconnect hint. Google’s guidance says early connections to important third-party origins [can speed up load time by 100 to 500 ms](https://web.dev/articles/preconnect-and-dns-prefetch). **Make each round trip shorter.** - Serve from close to your visitors. A content delivery network (CDN) is a network of servers that answer from near the visitor. The Web Almanac measured [median TLS negotiation at 57 ms for CDNs against 177 ms for origin servers](https://almanac.httparchive.org/en/2025/cdn) on desktop, more than three times faster. - Cache what you can at the edge, including HTML for pages that are the same for everyone, so whole requests are answered nearby. Neither lever helps with the time your server spends building a page that cannot be cached, such as a basket or a checkout. That is a different kind of latency. ## Network latency vs server latency: what changes under load? Network latency is the time spent travelling; server latency is the time spent being answered. Network latency barely changes when your site gets busy. Server latency is the one that grows, because requests start queuing for the same servers and databases. Google’s Site Reliability Engineering book defines latency in its server sense as [the time it takes to service a request](https://sre.google/sre-book/monitoring-distributed-systems/), and adds that latency increases are often a leading indicator of saturation. In other words, when a server starts running out of room, its answers slow down before anything fails. The confusion between the two meanings causes real mistakes. A team sees “latency” climb on a dashboard during a sale and blames the network, or buys a CDN for pages it cannot cache. The browser sees both kinds added together, which is why time to first byte, the subject of part 12 of this guide, mixes network travel and server thinking in one number. It is also why [Core Web Vitals measured under load](https://www.evaluat.com/blog/core-web-vitals-load-testing) can differ so much from the same page measured on a quiet afternoon. ## Common mistakes with latency and bandwidth Most of these come from treating speed as one number. Each one sends effort to the wrong place. - **Judging a site from a fast office connection.** Your own fibre line and nearby servers hide the round trips a mobile shopper pays. - **Buying bandwidth for a latency problem.** A bigger hosting plan or a faster connection rarely helps a page that is waiting on round trips. - **Comparing latency numbers from different tools.** Some report one way and some a round trip; some measure to the nearest server and some to yours. Check the method before comparing. - **Assuming a CDN fixes everything.** It shortens trips for the content it can serve. Uncached pages still wait on your origin. - **Testing only when the site is quiet.** Network latency looks the same at midnight and on sale day. Server latency does not. ## How Evaluat measures latency under load Every virtual user is a real browser. That means Evaluat records the same timings a customer’s browser does, broken into the phases listed on [how it works](https://www.evaluat.com/how-it-works): DNS lookup, connection, TLS negotiation and time to first byte, per URL and at any percentile. Tests run from the region closest to your customers, so the network part of each round trip resembles theirs. That makes the two kinds of latency separable. If connection and TLS times hold steady while time to first byte climbs as virtual users ramp up, the network is fine and your server is queuing. You can then open a session from the slow period and watch the moment it stalled, with its network log showing which request waited. The boundary is worth stating. A test from one region shows what this controlled browser saw under the selected test conditions, not every customer’s device and connection. For questions about field conditions across all your visitors, real-user data complements a test rather than being replaced by it. Latency and bandwidth, then, are different limits, and web pages mostly hit the first. Count the round trips on your most important page, find out how far your server is from your customers, and measure how your server’s own latency moves when traffic arrives. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) to see the round trips on your own pages measured under realistic load. [Previous · Part 9How to estimate peak traffic from your analytics](https://www.evaluat.com/blog/sizing-black-friday-load-test) [Next · Part 11What is a code freeze, and should you have one before peak?](https://www.evaluat.com/blog/black-friday-code-freeze) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### What is the difference between latency and bandwidth? Bandwidth is how much data a connection can carry each second, measured in megabits per second. Latency is how long it takes data to travel from one end to the other, measured in milliseconds. A connection can have lots of bandwidth and still feel slow if every trip takes a long time. ### Is latency the same as ping? Close, but not quite. Ping is a tool that sends a small packet to a server and times the reply, so the number it shows is a round trip time. People often call that number their latency, although latency strictly means the one-way delay. ### Does more bandwidth reduce latency? Not in the way most people expect. More bandwidth lets each trip carry more data, but it does not make the trip shorter, so a page that needs many round trips barely speeds up. The exception is a connection that is already full, where a faster plan can cut the time data spends queuing. ### What is a good latency? For most online activity, lower than 100 milliseconds is comfortable. Ofcom says response times under 50 ms are sufficient for demanding activities such as video calling, and under 100 ms for most activities. For websites the total matters more than any one trip, because a page makes many of them. ### What is the difference between bandwidth and throughput? Bandwidth is the maximum a connection can carry. Throughput is the amount of data actually delivered per second in practice, which is usually lower because of congestion, protocol overhead and the time spent waiting on round trips. ### Why is a website slow when my internet is fast? Usually because the delay is not in your connection. The page may need many round trips in sequence, its server may be far away, or the server may be slow to answer. None of those improve with a faster broadband plan. ### Does a CDN reduce latency? Yes, for the content it serves. A content delivery network answers from a server near the visitor, which shortens every round trip and speeds up connection setup. It does not reduce the time your own server spends building a page that cannot be cached. ### Is 5G latency lower than 4G? Yes, though by milliseconds rather than a different order of magnitude. Ofcom's 2025 report found average 5G response times between 15 and 21 ms across UK networks and 4G between 18 and 23 ms, measured one way to a nearby test server. The distance from that server to a website's origin is unchanged. Related reading ## More from the blog [![A page load drawn as a waterfall of seven waits in order: DNS lookup, TCP connection, TLS handshake, the server thinking until the first byte, the HTML download, fetching CSS, scripts and images, then layout and paint. The first byte arrives after the fourth wait and the largest paint after the seventh. The server wait is highlighted because it is the one that grows when the site is busy.](https://www.evaluat.com/blog/how-a-web-page-loads-cover.svg)](https://www.evaluat.com/blog/how-a-web-page-loads) ### [What happens when a web page loads: DNS, TLS, TTFB and render](https://www.evaluat.com/blog/how-a-web-page-loads) [Between the tap and the paint there are seven waits, and most speed problems live in exactly one of them. The browser looks up the address, opens a connection, secures it, waits for the server, downloads the page, fetches everything the page asks for, and paints. Learn the order and you can find the slow one.](https://www.evaluat.com/blog/how-a-web-page-loads) [Ahmad Farzan · 24 September 2026](https://www.evaluat.com/blog/how-a-web-page-loads) [![Time to first byte for the same page on a quiet afternoon and on sale day, drawn as stacked bars against Google's thresholds of 0.8 seconds for good and 1.8 seconds for poor. Network travel takes 435 milliseconds both times. Server time is 200 milliseconds when quiet, giving a good TTFB of 635 milliseconds, and 1,400 milliseconds when requests queue, giving a poor TTFB of 1,835 milliseconds.](https://www.evaluat.com/blog/time-to-first-byte-cover.svg)](https://www.evaluat.com/blog/time-to-first-byte) ### [Time to First Byte (TTFB), explained](https://www.evaluat.com/blog/time-to-first-byte) [Time to First Byte (TTFB) is how long a browser waits between starting to load a page and receiving the first byte of the reply. Good is 0.8 seconds or less. It is not a Core Web Vital, but it is the first slice of every page load and the number that moves first when your server starts to queue.](https://www.evaluat.com/blog/time-to-first-byte) [Ahmad Farzan · 8 October 2026](https://www.evaluat.com/blog/time-to-first-byte) [![Ecommerce conversion rate against page load time, from Portent's 2022 study of over 100 million page views: 3.05 percent of visitors convert on a one-second page, falling to 0.67 percent by four seconds. Every extra second of load time costs sales.](https://www.evaluat.com/blog/what-is-website-performance-cover.svg)](https://www.evaluat.com/blog/what-is-website-performance) ### [What is website performance, and why does speed matter?](https://www.evaluat.com/blog/what-is-website-performance) [Website performance is what your site feels like to the person using it: how fast pages appear, how quickly they respond, and whether that holds when traffic arrives. It matters because the costs are measurable. Slow pages convert visitors at a fraction of the rate of fast ones, and search rankings lean toward sites that feel good to use.](https://www.evaluat.com/blog/what-is-website-performance) [Ahmad Farzan · 3 September 2026](https://www.evaluat.com/blog/what-is-website-performance) See it on your site Test in real browsers.\ Debug in real sessions. ## Start with one real-browser page load. Pulse loads a public URL once, returns LCP and CLS plus FCP and TTFB, grades the page, and keeps a video on a shareable link. [Run a free speed test](https://www.evaluat.com/tools/website-speed-test) [Book a demo](https://www.evaluat.com/demo?intent=performance)