What Is Latency in Networking?

Latency is the time it takes for data to travel from one point on a network to another. It is the delay you feel between an action and a response: clicking a link, sending a message, or loading an API. Lower latency means a snappier, more responsive system, and it is often the single biggest factor in how fast an application feels.

What latency actually measures

In networking, latency is usually expressed in milliseconds (ms) and refers to the delay for a piece of data to move between a source and a destination. The most common way to talk about it is round-trip time (RTT): how long a small packet takes to travel to a server and for the reply to come back. One-way latency is half of that in a symmetric path, but real networks are rarely perfectly symmetric, so RTT is what most tools report.

It helps to distinguish a few related terms. Latency is the delay itself. Jitter is the variation in latency from one packet to the next, which matters enormously for voice and video. Packet loss is the percentage of packets that never arrive and have to be re-sent. A connection can have low average latency but high jitter and still feel unstable.

Latency is not bandwidth

These two are constantly confused. Bandwidth is how much data the connection can carry per second; latency is how long each piece takes to get there. The classic analogy: bandwidth is the number of lanes on a highway, latency is how long the drive takes. A wide highway does not make any individual car arrive sooner.

This is why a high-bandwidth satellite link can still feel sluggish. You can download a large file quickly once the transfer is underway, but every request still pays a long delay because the signal has to travel a great distance. For interactive workloads, latency frequently matters more than raw bandwidth.

What causes latency

Latency is the sum of several distinct delays accumulated along the path between two machines.

• Propagation delay is the time for a signal to physically travel the distance. Even at near light speed, signals in fiber move at roughly two-thirds of the speed of light in a vacuum, so geographic distance imposes a hard floor that no upgrade can remove.
• Transmission delay is the time to push all the bits of a packet onto the link, which depends on packet size and the link's bandwidth.
• Processing delay is the time each router, switch, or firewall along the way spends inspecting and forwarding a packet.
• Queuing delay is the time packets wait in buffers when a device is congested. This is the most variable component and the main source of jitter.

On top of the raw network path, software adds its own latency: TLS handshakes, DNS resolution, server processing time, and database queries all contribute to the delay a user perceives.

How latency is measured

The simplest tool is ping, which sends ICMP echo requests and reports RTT. A response like time=24.6 ms tells you the round trip to that host. To see where delay accumulates hop by hop, traceroute (or tracert on Windows) maps each router on the path and its individual latency.

$ ping example.com
64 bytes from 203.0.113.10: icmp_seq=1 ttl=56 time=24.6 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=56 time=23.9 ms

For application-level latency, browser developer tools break down a request into DNS lookup, connection, TLS, time-to-first-byte, and content download. When you care about user experience, measure percentiles (p50, p95, p99) rather than averages. A good average can hide a slow tail that affects a meaningful fraction of requests, and tail latency is often what users complain about.

Why latency matters

For interactive systems, latency is the dominant felt-performance metric. Research on human-computer interaction has long held that responses under roughly 100 ms feel instantaneous, delays up to about a second keep a user's train of thought intact, and beyond a few seconds attention drifts. Web apps that shave tens of milliseconds off response times routinely see measurable gains in engagement.

Latency compounds. A page that makes many sequential requests pays the RTT for each one, so a 50 ms round trip repeated ten times in series becomes half a second of pure waiting. Protocols like HTTP/2 and HTTP/3 exist largely to reduce this by multiplexing many requests over one connection. For real-time use cases, persistent connections such as WebSockets or server-sent events avoid repeated connection setup entirely.

How to reduce latency

Because latency is a sum of components, you reduce it by attacking each one.

• Move closer to the user. A content delivery network serves cached responses from edge locations near each visitor, cutting propagation delay. This is the highest-leverage change for globally distributed audiences.
• Cut round trips. Combine requests, reuse connections, and cache aggressively. Every avoided round trip removes one full RTT.
• Speed up the handshake. Connection reuse, session resumption, and HTTP/3's reduced setup all lower the cost of establishing a secure connection.
• Resolve names faster. DNS lookups add latency before any data flows; caching and low TTL tuning help.
• Choose the right transport. The trade-offs between TCP and UDP matter: TCP guarantees ordered delivery at the cost of retransmission delays, while UDP trades reliability for lower, more predictable latency, which is why it underpins most real-time media.

Common pitfalls

The most frequent mistake is throwing bandwidth at a latency problem. Upgrading a connection does nothing for delay caused by distance or by too many sequential round trips. Another is optimizing for average latency while ignoring the tail; a p99 of two seconds means one in a hundred users has a bad time, which adds up at scale.

Teams also forget that ping measures only the network path, not the full application. A 20 ms ping with a 400 ms server response time still produces a slow page. When you size out infrastructure, related concerns like network segmentation can be checked with a subnet calculator, and when a slow request returns an error, the HTTP status code reference helps separate a network delay from a server fault. Finally, beware comparing latency numbers measured under different conditions: time of day, route, and congestion all shift the result, so consistent methodology matters more than any single reading.

Frequently Asked Questions