Are latency and bandwidth the same thing?

No. Latency is how long data takes to make a round trip. Bandwidth is how much data fits through per second. A 1 Gbps connection still has 80 ms of latency if the server is far away, and downloading a small file will feel slow.

It depends on the use. Within the same region, a few milliseconds is common. Between continents, a few tens to a couple of hundred ms is normal. For a website, what matters is the sum of all round trips, not a single number.

Are latency and TTFB the same?

No. TTFB (Time to First Byte) is the time until the first byte of the response arrives, and it includes redirects, DNS, connection, TLS and the time the server spends processing. Network latency is only one part of it.

Does a CDN reduce latency?

It does for cacheable content, because the response comes from a point close to the visitor. For dynamic responses that have to reach the origin server, the distance to the origin still counts.

Latency and ping: why server location matters

You click a button and nothing happens for half a second. The connection is not slow in the "too few megabits" sense: the request simply takes time to reach the server and come back. That time is latency, and it is why a bot replies with a lag or a page loads slowly even on a 500 Mbps fiber line.

Latency is not bandwidth. Bandwidth tells you how much fits through the pipe per second; latency tells you how long one drop takes to cross it. Websites, APIs and bots exchange many small messages, so latency usually matters more than bandwidth.

What is latency and what is ping?#

According to MDN, latency is the time it takes for a packet of data to travel from source to destination. In practice it is almost always measured as a round trip (RTT, round-trip time): the time between the request leaving and the response arriving.

Ping is the most common tool to measure it. It sends an ICMP "echo request" message and waits for the "echo reply". The number it prints, in milliseconds (ms), is the RTT to that address.

bash

ping -c 4 example.com

Ping only measures the network up to the server. It does not include TLS or the time your application spends building the response. Some servers also block ICMP, so a ping with no reply does not prove the server is down. On Windows, the option is -n 4 instead of -c 4.

Why does distance set a latency floor?#

No signal travels faster than light. In fiber, light is slower than in a vacuum: with a refractive index around 1.5, the delay is about 5 µs per kilometer, according to Wikipedia (in a vacuum it would be 3.33 µs per km).

That gives a simple floor calculation. London is about 5,570 km from New York in a straight line:

5,570 km x 5 µs = about 28 ms one way
Round trip: about 56 ms, in the theoretical best case

Real cables do not follow a straight line and pass through routers, so the measured value is higher. No code optimization gets you below that floor. That is why the server's location relative to your users is the first decision, and the hardest one to undo later.

What adds up to the latency of a web request?#

A single HTTPS request to a site you have not visited yet goes through several stages, each with at least one round trip:

DNS: finding the domain's IP (see what is DNS).
TCP connection: the handshake that opens the channel.
TLS: negotiating the secure connection.
Request and wait: the server receives, processes and starts to answer.
Download: the response arrives, and the time depends on bandwidth and file size.

MDN points out that latency is higher on the first request precisely because it adds DNS, TCP and TLS, and that later requests are faster because the connection is already open. That is why reusing connections (keep-alive, HTTP/2, HTTP/3) helps so much.

The sum of all this up to the first byte is the TTFB. web.dev treats a TTFB of 0.8 s or less as good and above 1.8 s as poor, as a rough guide, and notes that it includes redirects, DNS, connection, TLS and the wait for the response.

How do you measure each stage with curl?#

curl can split the timings with -w. This command works on Linux, macOS and Git Bash on Windows:

bash

curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nfirst byte: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.com

The values are cumulative from the start. To get the time of each stage, subtract the previous value:

time_connect - time_namelookup is the TCP handshake, roughly one round trip to the server.
time_appconnect - time_connect is TLS.
time_starttransfer - time_appconnect is the request plus the server's processing.

If the TCP connection alone takes tens of ms, the bottleneck is distance. If TCP is fast and the gap until the first byte is large, the bottleneck is in the server's code or database, and moving the server will not fix it.

How do you reduce latency?#

In order of impact, for most projects:

Move the server closer to your users. It is the only way to lower the physical floor.
Keep components close to each other. An app that runs 10 database queries pays 10 round trips. With the database and the app in the same region this barely matters; far apart, it multiplies the delay.
Use a CDN for what can be cached. Images, CSS and JS are served from a point close to the visitor. See what is a CDN.
Cut the number of round trips. Fewer redirects, fewer different domains, reused connections, batched queries.
Spread the load. Several servers behind a load balancer remove the queue, although they do not shorten the distance.
Measure from where your users are. The ping from your own computer is only valid for your computer.

When does latency matter most?#

Applications that exchange messages all the time suffer the most: games, voice calls, Discord bots with interactive commands, real-time dashboards. A cached static site suffers less. A backend that makes several sequential calls to other services feels every round trip added up.

It also helps to separate latency from jitter, which is how much the delay varies from one packet to the next. Low average latency with high jitter still causes stutters in voice and video.

How to do this on Square Cloud#

On Square Cloud, applications run in isolated containers in a partner Tier 3 datacenter in New York (Telehouse). In front of them sits an Anycast CDN with more than 200 points of presence, HTTP/3 and WebSockets.

Two numbers help with planning. A Discord bot hosted on Square Cloud sees an average latency of about 30 ms to the Discord Gateway. Database hosting, available from the Standard plan, provisions the database in the same datacenter as your applications, with about 1 ms of average latency, which makes sequential queries cheap. These are observed averages, not guarantees.

If one server is not enough, load balancing lets you serve the same custom domain from several applications, with round-robin and passive failover. There is no autoscaling: you decide how many applications join and how much RAM each one gets. For users far from New York, the physical floor calculated above still applies, and the CDN helps with cacheable content, following your application's Cache-Control.

See the network details in Square Cloud network and CDN.