Low Latency

Low latency is a short elapsed time between specified events, such as sending data and receiving it, or issuing a request and getting a response. It describes delay, not the amount of data transferred. “Low” is relative to an application's requirements and the points being measured: a delay acceptable for one task may be disruptive for another. It does not mean zero delay.

How Latency Is Measured

Latency is commonly expressed in milliseconds, with finer units, such as microseconds, used for very short delays. One-way latency measures travel time from a source to a destination. Round-trip time measures the journey to a destination and back. The outward and return journeys may take different amounts of time, so halving a round-trip measurement does not necessarily reveal either one-way delay.

Application response time can include network travel, server processing and waiting for other services. A claim of low latency is therefore meaningful only when the measurement boundaries are clear. Timing a single network link and timing a complete application request describe different parts of the experience.

What Causes Delay

Several kinds of delay accumulate along a communication path. Signals take time to travel over physical distance, and transmitting all the bits of a message onto a link also takes time. Network equipment and application servers must process the data. When arriving traffic exceeds what a link or system can immediately handle, data waits in queues; congestion can therefore increase delay even when the physical route stays unchanged.

Bandwidth describes capacity, while throughput describes the rate of data successfully transferred. Neither is a measure of latency. Greater capacity can reduce waiting when congestion is the bottleneck, and a faster link can reduce transmission time for a given message. It does not automatically shorten the physical route or eliminate processing delays elsewhere.

How Delay Can Be Reduced

Achieving low latency starts with identifying which part of the measured path contributes most to delay. Shortening relevant routes can reduce travel time, reducing congestion can limit queueing, and removing processing bottlenecks can shorten the time spent handling a request. An improvement to one component may have little effect if another component dominates the total response time.

Moving suitable content or processing closer to users can shorten some journeys. A content delivery network can serve cached content from a nearby location, while edge computing can perform suitable processing closer to where data originates. Neither approach removes every delay: a request may still depend on a distant service or information that cannot be served locally. Faster hardware or a higher-bandwidth connection likewise needs to address an actual bottleneck to improve the result.

Application Requirements and Limitations

Different applications expose different parts of this delay. In live streaming, end-to-end latency is the gap between an event being captured and shown to a viewer; a shorter gap does not by itself guarantee picture quality or prevent buffering. In online games, delayed exchanges with a server can make shared actions feel less responsive. Virtual and augmented reality also depend on timely updates as users move, while remote-controlled equipment depends on timely commands and feedback. In each case, network delay is only part of the complete path, and a low measurement alone does not establish reliability or safe operation.

Low latency supports responsive interactions, but a typical or average measurement does not describe every request. Occasional long delays can still make an application feel slow. Assessments should therefore consider variation and slower responses as well as the usual delay, under conditions relevant to the application. A measurement taken on an idle network may not represent performance during congestion.

In time-sensitive trading, shorter delays can help market information or orders arrive sooner. They do not guarantee execution quality or profit, because market conditions and other parts of the trading process still matter. More broadly, reducing delay does not by itself ensure reliable delivery or adequate data capacity. Optimization should preserve required security protections rather than treat them as optional obstacles.