Hosting plans advertise bandwidth (1 Gbps ports, terabytes of transfer), but for most websites, APIs, games and SSH sessions, what users feel is latency: how long each round trip takes. Understanding the difference helps you choose the right server location, and fix the right bottleneck.

Definitions

Term Meaning Unit
Latency Time for data to travel to the destination and back (round-trip time, RTT) Milliseconds (ms)
Bandwidth Maximum capacity of a link Mbps / Gbps
Throughput What you actually achieve Mbps
Jitter Variation in latency between packets ms
Packet loss Share of packets that never arrive %

A water-pipe analogy: bandwidth is the pipe’s width, and latency is its length. A wide but very long pipe still takes a long time to deliver the first drop.

Why latency dominates web performance

Loading a web page isn’t one big transfer. It’s a series of round trips:

  1. DNS lookup: 1 RTT (or more).
  2. TCP handshake: 1 RTT.
  3. TLS handshake: 1 RTT (TLS 1.3), or 2 (TLS 1.2).
  4. HTTP request and response: 1 RTT, plus more for each dependent resource (CSS → fonts, JS → API calls).

With 200 ms RTT, that’s roughly a second before the first content arrives, regardless of whether the link is 100 Mbps or 10 Gbps. A typical HTML page is a few hundred KB, which takes milliseconds to transfer at modern bandwidth. The round trips are the cost.

That’s why HTTP/2 and HTTP/3, TLS 1.3, connection reuse, caching and CDNs (which bring content physically closer) help so much. See website speed optimization and CDN for your website.

When bandwidth matters

  • Large downloads, video streaming, software distribution.
  • Backups and replication between servers.
  • File hosting, image-heavy sites with many visitors at once.
  • Total transfer volume, which is about monthly traffic allowances rather than speed.

Even here, latency matters. TCP throughput on a single connection is limited by window size ÷ RTT, so long-distance transfers are slower unless TCP windows and congestion control are tuned. See TCP BBR.

Physics sets the floor

Light in fibre travels at about 200,000 km/s, roughly 1 ms of RTT per 100 km of fibre path, before any routing detours. Typical round trips:

Route Typical RTT
Same city 1–5 ms
Across Europe or the US East–West 40–80 ms
US West Coast ↔ Japan / Hong Kong 100–160 ms
Europe ↔ East Asia 180–280 ms

Real paths are longer than straight lines, and routing quality matters as much as distance. Two servers in the same city can have very different latency to your users, depending on the carriers and peering. For mainland China in particular, optimised routes (such as CN2 GIA) make a big difference compared with standard international transit.

Jitter and packet loss

  • Jitter hurts real-time traffic: voice, video calls, games, live trading terminals.
  • Packet loss of even 1–2% cuts TCP throughput dramatically and causes stutter in games and calls.

Both come from congested or poor-quality paths, and they vary by time of day, so measure in the evening peak too.

Measure each one

ping -c 20 server-ip                  # latency and loss (min/avg/max/mdev ≈ jitter)
mtr -rwc 100 server-ip                # per-hop latency and loss along the path
iperf3 -c server-ip -t 20             # throughput between two machines you control
curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com

The curl timing breakdown shows where page-load time goes: DNS, TCP connect, TLS, server processing (TTFB minus TLS), and transfer. See ping and mtr, iperf3 and curl.

Test before you buy: VPS.DO publishes test IPs for each data centre on the USA, Hong Kong and Japan VPS pages. Ping them from where your users are.

Choosing a server location

  1. Put the server near most of your users, or near what the server talks to most (a database, an exchange, an API).
  2. For a global audience, a central location plus a CDN for static assets.
  3. For interactive workloads (games, trading, remote desktops), prioritise latency and route quality over raw port speed.
  4. For bulk transfer workloads, look at port speed, traffic allowance and the provider’s upstream capacity.

See choosing a VPS location.

Quick reference

Problem Likely cause Fix
Slow first byte everywhere Server processing Caching, optimisation
Slow first byte far away only Latency Closer location, CDN, HTTP/2–3, TLS 1.3
Big downloads slow Bandwidth, or latency × TCP window BBR, closer server, more bandwidth
Lag spikes in games or calls Jitter, packet loss Better route or location

Related: MTU explained and anycast explained.

  • Networking
  • Performance
  • VPS Guides