Latency vs Bandwidth: Why Speed Tests Look Fast but Web Pages Load Slowly

A speed test measures how thick the pipe is; loading a web page depends far more on how long the water takes to arrive and how much leaks along the way. Bandwidth decides how much data can flow at once, latency decides how long each round trip takes, and packet loss decides how much has to be sent again. Opening a page means waiting through ten or so round trips one after another, each costing a full latency, while the page itself is only a few MB — so extra bandwidth saves very little. When a speed test shows hundreds of Mbps but pages spin, the culprit is usually high latency or packet loss, not bandwidth.

1. ① How thick the pipe isBandwidth: how much flows at once
2. ② How long the water takesLatency: the wait per round trip
3. ③ How much leaksPacket loss: leaked data is resent
4. ④ Filling a poolDownloads and video: mostly bandwidth
5. ⑤ Cups passed back and forthWeb pages: mostly latency
6. ⑥ Many taps by the doorSpeed tests: nearby, many connections

Three numbers, explained with a water pipe

Think of your connection as a pipe running from a distant water tower to your home:

Pipe	Network metric	Unit	What it affects
How thick the pipe is	Bandwidth	Mbps	How much data at once: big downloads, HD video
How long the water takes to arrive	Latency	Milliseconds (ms), usually a round trip	How long each request–response takes: web pages, games, video calls
Whether the flow is steady	Jitter	ms	How stable latency is: games, calls, live streams
How much leaks on the way	Packet loss	Percent	How much must be resent; loss also makes TCP slow down

These are independent: a pipe can be thick but very long (high bandwidth, high latency), or short but leaky (low latency, lots of loss). No single number tells you whether things will feel fast.

How many round trips does one page take?

Loading a page isn’t “ask for the whole page once”. It’s a chain of round trips that have to happen in order. The sequence diagram below walks through the first steps of opening an HTTPS page:

Round trip	What happens	Why it has to wait
① Look up the address	The browser asks a DNS server for the domain’s IP	Can’t connect without the IP
② Connect	TCP handshake to start talking to the site	Data can only flow once the site agrees
③ Encryption handshake	TLS agrees on encryption and checks the certificate	Nothing can be sent until encryption is set up
④ Fetch the page	Request the page and receive the HTML	Only the HTML says what else is needed
⑤ onward More resources	Fetch the styles, scripts and images the HTML points to; styles in turn reference fonts…	Each resource is only discovered once the previous one arrives

Just getting the first bytes of HTML takes 4 round trips, and styles, scripts and images often live on other domains, each needing its own lookup and handshakes. All told, an ordinary page often waits through ten or so round trips in sequence. HTTP/2 and HTTP/3 (QUIC) reuse connections and combine handshakes to save some of them, but not all (protocol details in Common network protocols).

Why bandwidth doesn’t help: a quick estimate

You can roughly split page load time into two parts:

load time ≈ number of round trips × latency + page size ÷ bandwidth

For a 3 MB page and 10 round trips:

Latency per round trip	10 Mbps	100 Mbps	1000 Mbps
20 ms (local site)	about 2.6 s	about 0.44 s	about 0.22 s
200 ms (other region)	about 4.4 s	about 2.2 s	about 2.0 s

Look at the second row: at 200 ms, going from 100 Mbps to 1 Gbps saves only 0.2 seconds, because most of the time (2 seconds) is spent waiting on round trips. With the same 100 Mbps, cutting latency from 200 ms to 20 ms takes the page from 2.2 seconds to 0.44. Bandwidth is the bottleneck only when it’s really low (first column); once it’s enough, more bandwidth barely helps page loads — lower latency does.

Packet loss makes it worse: every lost packet costs at least one extra round trip to recover, and TCP slows down in response — more so the higher the latency (see Why is my internet slow at night?).

Why speed tests always look good

A few reasons speed test results flatter your connection:

• The test server is close: speed tests pick the nearest server by default, a few milliseconds away, so they mostly measure the stretch from your home to your ISP — not the long-distance links.
• Many connections at once: tests usually download over 8 to 16 parallel connections, so when some slow down because of loss, others make up for it and the effect of loss is averaged out.
• They measure bandwidth: the headline number is “how thick is the pipe”; latency is shown on the side, and only to that nearby test server.

Opening a page in another region goes over long-distance links with higher latency and, at peak hours, some loss — and every connection starts slow. So “hundreds of Mbps on the speed test, pages won’t load” isn’t a contradiction: they measure different things.

Different activities care about different numbers

Activity	Matters most	Why
Browsing, social apps	Latency	Lots of small requests, each waiting on the last
On-demand video	Bandwidth	Players buffer ahead; high latency just means a slower start
Video calls, voice, live interaction	Latency, jitter, loss	Real-time media can’t buffer; lost data means freezes or glitches
Online games	Latency, jitter	Tiny amounts of data, but every action must arrive fast
Big downloads, system updates	Bandwidth, then loss	Time goes into transfer; loss makes TCP slow down
Remote desktop, remote development	Latency	Every keystroke and click waits a round trip

How Pangolin measures “latency”

The app shows latency in two places, and they measure different things:

• In the server list: the app does a few connection handshakes directly with each server and keeps the fastest, which reflects the round trip from your device to the server. It’s for comparing which server is closest with the best route, and Smart select uses it to pick the lowest-latency server (see Connecting and switching servers).
• On the Connect screen, once connected: the app sends a real request through the encrypted tunnel to a test URL that returns an empty response, and times it from request to reply. That covers the full path you → server → website, so it’s usually higher than the list number but closer to what you actually wait for when loading a page.

Neither number is simply “closer to zero is better”: a server physically farther away naturally has higher latency, but if the sites you want are in that region, the rest of the trip from there is shorter.

Test it yourself

• Latency and loss: run ping -c 20 example.com in a terminal (Windows: ping -n 20 example.com). Look at each line’s time (latency), how much the lines differ (jitter), and the packet loss summary at the end. Many servers block ping, so a failed ping doesn’t mean the site is down.
• See what a page is waiting for: press F12 for developer tools, open the Network tab and reload. If most of each bar is “waiting for server response”, latency is the problem; if it’s “content download”, then bandwidth is.
• Measure long-distance bandwidth: in a speed test, manually choose a server in another region instead of the nearest one. The result is much closer to what you get when using sites there.
• Test at different times: run the same tests in the afternoon and the evening. If latency and loss jump at night, it’s peak-hour congestion (see Why is my internet slow at night?).

Related reading

• Previous: Why is my internet slow at night?
• What happens when you open a website?
• Common network protocols: IP, TCP, UDP, DNS, HTTP, TLS, QUIC