Network Latency: Causes, Measurement, and CDN Optimization

Beginner

Every click, search query, and video stream you initiate on the internet begins a journey across cables, routers, and switches that spans hundreds or thousands of miles. The time that journey takes is network latency, and it is the single most perceptible factor in how fast the web feels to end users. Understanding latency is essential for anyone building, operating, or optimizing web infrastructure, because even small improvements can measurably reduce bounce rates, increase conversions, and improve user satisfaction.

This article breaks down the four fundamental types of network delay, explains how latency is measured in practice, traces the historical evolution from early internet backbone performance to modern CDN architectures, and shows exactly how content delivery networks eliminate latency at scale.

What Is Network Latency and Why Does It Matter?

Network latency is the time delay between sending a request and receiving the first byte of the response. It is most commonly expressed as Round-Trip Time (RTT) — the total time for a data packet to travel from the sender to the receiver and back again, measured in milliseconds (ms).

Latency matters because human perception is remarkably sensitive to delay. Research by Google (2017) found that as mobile page load time increases from 1 second to 3 seconds, the probability of bounce increases by 32%. At 5 seconds, that probability reaches 90%. Amazon famously calculated that every 100ms of additional latency cost them 1% in sales revenue. For interactive applications — video calls, online gaming, collaborative editing — even 50ms of additional delay degrades the experience noticeably.

Latency is not the same as bandwidth. A connection can have enormous bandwidth (the capacity to carry data) while still suffering from high latency. A fiber optic link between New York and London carries terabits per second, but the one-way propagation delay is still approximately 35ms because light through fiber travels at roughly two-thirds the speed of light in a vacuum. No amount of bandwidth improvement changes the speed of light.

What Are the Four Types of Network Delay?

Total end-to-end latency is the sum of four distinct types of delay. Each has different causes and different solutions.

Propagation delay

Propagation delay is determined by the physical distance between two endpoints and the speed at which signals travel through the transmission medium. In fiber optic cables, light travels at approximately 200,000 km/s (about two-thirds the vacuum speed of light, 299,792 km/s). In copper cables, electrical signals propagate at roughly the same fraction. This means a signal crossing 1,000 km of fiber takes approximately 5ms one way.

Propagation delay is the most fundamental form of latency. It cannot be reduced by faster hardware or better software — only by physically shortening the path between sender and receiver. This is precisely why CDN Points of Presence exist: by placing servers closer to end users, CDNs dramatically cut propagation delay.

Transmission delay

Transmission delay is the time required to push all the bits of a packet onto the transmission link. It depends on the packet size and the link capacity (bandwidth). For a 1,500-byte Ethernet frame on a 1 Gbps link, transmission delay is only 0.012ms. On modern high-speed links, transmission delay is negligible for individual packets but can add up when transferring large objects in many packets.

Processing delay

At each router along the path, incoming packets must be examined: the header is checked for errors, the destination address is looked up in the routing table, and a forwarding decision is made. Modern routers with hardware-accelerated forwarding (ASICs) accomplish this in microseconds. However, packets that require deep packet inspection, NAT translation, or firewall rule evaluation incur higher processing delays.

Queueing delay

Queueing delay is the most variable and unpredictable component. When packets arrive at a router faster than they can be forwarded, they queue in buffers. During periods of congestion, queueing delay can spike from near-zero to hundreds of milliseconds. This variability is called jitter, and it is particularly damaging to real-time applications like VoIP and video streaming.

How Did the Early Internet Handle Latency?

The modern concern with millisecond-level latency would have seemed luxurious to early internet engineers. When the ARPANET launched in 1969, connecting four university nodes, round-trip times were measured in hundreds of milliseconds. The 56 Kbps lines connecting Interface Message Processors (IMPs) introduced substantial transmission delay for even small messages.

The NSFNET backbone, which replaced ARPANET as the primary US internet infrastructure in 1986, initially operated at 56 Kbps before upgrading to T1 (1.544 Mbps) in 1988 and T3 (44.736 Mbps) in 1991. Even at T3 speeds, cross-country RTT on the backbone was approximately 85ms — and that was before packets traversed regional and local networks to reach end users.

The commercialization of the internet in the mid-1990s brought exponentially more users and correspondingly more congestion. By 1996, the web was growing so rapidly that backbone congestion frequently pushed RTTs above 200ms. This congestion crisis directly motivated the development of content delivery networks. Akamai, founded in 1998 by MIT mathematics professor Tom Leighton and graduate student Danny Lewin, proposed a fundamentally different approach: instead of trying to make the core network faster, distribute content to the edge.

How Is Latency Measured in Practice?

Network engineers use several tools to measure and diagnose latency, each providing different levels of detail.

Ping is the simplest latency measurement tool. It sends ICMP Echo Request packets to a destination and measures the time until an Echo Reply returns. The RTT reported by ping includes all four types of delay for the round trip. A typical ping to a well-connected server on the same continent shows 10-50ms; transcontinental pings show 60-120ms; and intercontinental pings routinely exceed 150ms.

Traceroute (or tracert on Windows) maps the path packets take through the network and measures the delay at each hop. It works by sending packets with incrementally increasing Time-to-Live (TTL) values. When a router decrements the TTL to zero, it returns an ICMP Time Exceeded message, revealing its identity and allowing the RTT to that hop to be calculated. Traceroute is invaluable for identifying where latency is being introduced along a path.

Browser developer tools break down the total page load into component delays: DNS lookup time, TCP connection establishment, TLS handshake duration, Time to First Byte (TTFB), and content download time. This granularity helps web engineers identify which stage contributes the most latency.

Synthetic monitoring platforms like Catchpoint, ThousandEyes, and Pingdom measure latency from hundreds of globally distributed vantage points, providing a comprehensive view of how users in different regions experience a service. These tools can distinguish between network latency and server processing time, helping operations teams pinpoint whether a performance issue originates in the network or at the application layer.

How Do CDNs Reduce Latency?

Content Delivery Networks address latency through three complementary strategies: edge proximity, connection optimization, and protocol acceleration. Together, these techniques can reduce page load times by 50% or more compared to serving content from a single origin server.

Edge proximity: shortening the physical path

The most impactful technique CDNs use is placing cached copies of content on servers geographically close to users. A major CDN like Cloudflare operates over 310 Points of Presence in more than 120 countries. When a user in Tokyo requests a webpage, the response comes from a server in Tokyo rather than from an origin server in Virginia. This reduces the propagation delay from approximately 75ms each way (150ms RTT) to under 3ms.

CDNs use two primary routing strategies to direct users to the nearest edge server. DNS-based routing resolves the CDN's domain name to the IP address of the geographically closest PoP based on the user's DNS resolver location. Anycast routing advertises the same IP address from multiple locations simultaneously, letting the internet's BGP routing protocol naturally direct packets to the nearest instance.

Connection reuse: eliminating handshake overhead

Establishing a new TCP connection requires a three-way handshake (SYN, SYN-ACK, ACK) that adds one full RTT of latency. Adding TLS encryption requires an additional 1-2 RTTs depending on the TLS version. For a user 150ms away from the origin, this connection setup alone costs 450-600ms before a single byte of content is transferred.

CDNs maintain persistent, pre-established connections between their edge servers and the origin server. When a user connects to the nearby edge, the TCP+TLS handshake covers only the short hop to the PoP (perhaps 5-10ms RTT). If the requested content is not in cache, the edge forwards the request over its already-established connection to the origin, eliminating handshake latency on the long-haul path.

Protocol optimization: reducing round trips

Modern CDNs deploy the latest protocol versions to minimize the number of round trips required. TLS 1.3 reduces the TLS handshake from two round trips to one, and supports 0-RTT resumption for returning connections. HTTP/2 multiplexes multiple requests over a single connection, eliminating the head-of-line blocking that plagued HTTP/1.1. HTTP/3 with QUIC moves transport to UDP, combining the connection handshake and TLS handshake into a single round trip and eliminating head-of-line blocking at the transport layer.

These protocol optimizations compound with edge proximity. When TLS 1.3's single-RTT handshake operates over a 5ms path instead of a 150ms path, the savings are dramatic: 5ms instead of 300ms just for the secure connection setup.

How Does Edge Computing Extend CDN Latency Benefits?

Traditional CDNs cache static content — images, CSS files, JavaScript bundles — at the edge. But dynamic content (personalized pages, API responses, database queries) still requires a round trip to the origin server. Edge computing extends the CDN model by running application logic directly on edge servers.

Platforms like Cloudflare Workers, AWS Lambda@Edge, and Fastly Compute allow developers to execute code at PoPs worldwide. A personalized API response that previously required a 150ms round trip to a centralized server can now be computed at the edge in under 5ms. This approach is particularly valuable for latency-sensitive operations like A/B test bucketing, authentication token validation, geolocation-based content adaptation, and real-time header manipulation.

The trade-off is complexity. Edge computing introduces challenges around data consistency (edge nodes may have stale data), storage limitations (edge environments typically offer limited persistent storage), and debugging (distributed execution across hundreds of locations complicates observability). Engineers must carefully evaluate which workloads benefit from edge execution versus those better suited to centralized processing.

What Practical Steps Reduce Latency for Web Applications?

Beyond deploying a CDN, several practical techniques help minimize latency for web applications:

Minimize DNS lookups. Each unique domain in a page requires a DNS resolution, adding 20-120ms per lookup. Reduce the number of third-party domains, use dns-prefetch and preconnect hints for essential external resources, and consider consolidating assets under fewer domains.

Enable connection prewarming. The preconnect resource hint tells the browser to establish TCP and TLS connections to important origins before they are needed, moving handshake latency off the critical rendering path.

Compress aggressively. While compression does not reduce network latency directly, it reduces the amount of data transferred, which decreases transmission delay and the number of round trips needed to deliver content (especially important given TCP slow start).

Use HTTP/2 or HTTP/3. Multiplexed connections eliminate the latency penalty of opening multiple parallel TCP connections and remove head-of-line blocking. HTTP/3's QUIC transport is especially beneficial on lossy mobile networks where TCP packet loss triggers expensive retransmissions.

Implement stale-while-revalidate. The stale-while-revalidate Cache-Control directive allows CDNs to serve cached content immediately while asynchronously refreshing it in the background. Users always receive a fast response from cache, while content stays fresh.

How Will Latency Evolve in the Future?

Several emerging technologies promise to further reduce network latency. Low Earth Orbit (LEO) satellite constellations like Starlink aim to provide lower latency than traditional geostationary satellites (20-40ms vs. 600ms+) by orbiting at 550 km rather than 35,786 km. 5G networks target 1ms air-interface latency, enabling new classes of latency-sensitive applications. Optical switching research aims to eliminate the optical-electrical-optical conversions at network nodes that currently add processing delay.

For CDN engineers, the frontier is pushing computation closer to users while maintaining consistency and reliability. The trend toward edge computing, combined with faster protocols and denser PoP deployments, continues to shrink the gap between what is physically possible and what users actually experience.