Latency is the time delay between an action being initiated and its effect being observed, in web infrastructure specifically the time between a browser sending an HTTP request and beginning to receive the server’s response. Measured in milliseconds latency is one of the most fundamental performance metrics in web infrastructure, it determines how quickly users begin to see responses to their requests and directly affects user experience, engagement, conversion rates, and SEO rankings.

Latency is distinct from bandwidth, the two are frequently conflated but measure different things. Bandwidth is the volume of data that can be transferred per unit of time, how much data a connection can carry simultaneously. Latency is the delay before data transfer begins, how long it takes for the first bit of a response to arrive. A high-bandwidth, high-latency connection transfers large files efficiently once transfer begins but feels sluggish for interactive use because every request waits a long time for the response to start. A low-bandwidth, low-latency connection feels responsive, requests receive immediate responses, but transfers large files slowly.

For redirect management latency is particularly important, a redirect adds at least one full request-response cycle before users reach the destination content. Every millisecond of redirect latency is a millisecond added to the total time before users see the destination page. Low-latency redirect infrastructure, redirect rules executed at edge nodes near users rather than at distant origin servers: minimises the performance cost of redirect hops and delivers users to destination content as quickly as possible.

Components of web latency

Web request latency is not a single phenomenon, it is the sum of several distinct components each arising from different aspects of the request-response cycle.

Propagation delay, the speed of light limit: the most fundamental latency component. Data travels through network cables and fibre optic links at approximately two-thirds the speed of light, around 200,000 kilometres per second. The physical distance between a client and a server imposes an absolute minimum latency, data cannot travel faster than the speed of light through the medium.

A request from London to a server in New York, approximately 5,500 kilometres, has a minimum one-way propagation delay of approximately 27 milliseconds, the time for light to travel that distance through fibre. A round trip, request out and response back, has a minimum of approximately 54 milliseconds. In practice the actual round-trip time is higher, network paths are not direct, routing through multiple hops adds distance, and signals travel through multiple types of cable and network equipment.

This physics-based minimum latency cannot be eliminated by faster servers or better software, the only way to reduce propagation delay is to reduce the physical distance between the client and the server. This is the fundamental motivation for edge networks: positioning servers near users to reduce the propagation component of latency.

Transmission delay, serialisation overhead: the time required to push all the bits of a packet onto the network link. Transmission delay equals packet size divided by link bandwidth. For high-bandwidth modern networks transmission delay is negligible for typical web request packets, a 1,500-byte packet on a 1 Gbps link takes about 12 microseconds to transmit. Transmission delay becomes significant for large packets on low-bandwidth connections, mobile networks with limited bandwidth.

Processing delay, server computation time: the time the server spends processing the request and generating a response. For simple static file serving processing delay is minimal, microseconds for reading a file from disk or cache. For dynamic content generation processing delay includes database queries, application logic execution, and template rendering, potentially tens to hundreds of milliseconds.

For redirect management processing delay is the time spent evaluating redirect rules, matching the incoming URL against configured rules and generating the redirect response. Cloudflare Workers execute redirect rule matching in microseconds. Origin-based redirect processing may take milliseconds including application startup and rule database queries.

Queuing delay, congestion overhead: time spent waiting in queues at network nodes. When a router or server is processing more traffic than it can handle immediately incoming packets wait in queues. High-traffic periods and network congestion increase queuing delays, the same request takes longer when the network or server is busy than when it is idle.

TCP and TLS handshake overhead: before any HTTP request can be sent the browser must establish a TCP connection, a three-way handshake requiring 1.5 round trips, and for HTTPS complete a TLS handshake, requiring 1-2 additional round trips depending on the TLS version. These handshake round trips multiply the propagation delay, a London-to-New York connection with 54ms propagation delay spends 54ms on the TCP handshake before any application data is sent.

TLS 1.3 reduced handshake overhead compared to TLS 1.2, requiring only one round trip rather than two for the TLS handshake. HTTP/2 and HTTP/3 reduce the number of connections required, multiplexing multiple requests over a single connection eliminates the handshake overhead for subsequent requests on an established connection.

Measuring latency

Several metrics and tools measure different aspects of web latency, each capturing different aspects of the user experience.

Round-trip time, RTT: the time for a packet to travel from the client to the server and back. RTT is the fundamental network latency metric, it determines the minimum time for a single request-response cycle. Measured with the ping command, which sends ICMP packets and measures the round-trip time, or with network diagnostic tools. RTT includes propagation delay, transmission delay, and minimal processing delay at network nodes.

Time to first byte, TTFB: the time from a browser sending a request to receiving the first byte of the response. TTFB includes the full TCP and TLS handshake overhead, or the connection reuse time for persistent connections, plus server processing time. TTFB is the most operationally relevant latency metric for web performance, it represents the user’s wait before any content begins to arrive.

Google includes TTFB in its assessment of Core Web Vitals: specifically through its contribution to Largest Contentful Paint. High TTFB directly increases LCP, delaying when the browser receives and can render the largest content element. A server-side redirect adds a full TTFB, for the redirect response, before the browser can begin loading the destination page.

DNS lookup time: the time to resolve a domain name to an IP address through DNS. DNS resolution adds latency before the TCP connection can be initiated, the browser must first know the server’s IP address. Cached DNS responses are served in milliseconds from local cache. Uncached lookups require a full DNS resolution chain, potentially 50-200ms for multiple DNS lookups across the resolution hierarchy.

Cloudflare’s 1.1.1.1 and Google’s 8.8.8.8 public DNS resolvers provide faster uncached resolution than many ISP resolvers, located at major internet exchange points with fast connections to authoritative nameservers globally.

Connection time, TCP handshake: the time to complete the TCP three-way handshake and establish a connection. Equals approximately 1.5 × RTT for the connection establishment. For a 100ms RTT connection connection time is approximately 150ms, before any HTTP data is exchanged.

TLS handshake time: the time to complete the TLS handshake after TCP connection establishment. TLS 1.2 handshake requires 2 × RTT, an additional 200ms on a 100ms RTT connection. TLS 1.3 reduces this to 1 × RTT, 100ms, and supports 0-RTT resumption for previously connected servers, zero additional round trips for TLS handshake.

Latency and redirects

Redirects add latency to the user journey, each redirect hop requires at least one additional request-response cycle before the user reaches the destination content.

The redirect latency cost: a single redirect adds the full latency of one request-response cycle to the total page load time. For a browser connecting to a redirect source 200ms RTT from the server a single redirect adds:

TCP handshake, 300ms, 1.5 × RTT for a new connection or 0ms for a reused connection. TLS handshake, 200ms TLS 1.3, or 0ms if TLS session is resumed. Request transmission, negligible. Server processing, 1-10ms. Response transmission, negligible for a small redirect response.

Total additional latency from a single redirect, 200-500ms for a new connection, or 1-10ms for a persistent connection, before the browser can begin loading the destination.

The connection reuse situation is common for HTTP-to-HTTPS redirects on the same domain, the redirect response and the destination request may share a connection. Cross-domain redirects always require new connection establishment.

Redirect chains multiply latency: a redirect chain with N hops multiplies the latency cost by N. A three-hop chain, URL A → URL B → URL C → destination, adds three request-response cycles before the destination loads. On a 200ms RTT connection a three-hop chain adds 600-1500ms of additional latency. Minimising redirect chains, collapsing multi-hop chains to direct single-hop redirects, is one of the most impactful redirect performance optimisations.

Edge redirect execution reduces redirect latency: executing redirect rules at edge nodes near users reduces the RTT component of redirect latency from the client-to-origin distance to the client-to-edge distance. A user 200ms RTT from the origin may be only 20ms RTT from the nearest edge node, reducing redirect response time from 200-500ms to 20-50ms. Edge redirect execution is the primary architectural technique for minimising redirect latency.

Reducing latency in web infrastructure

Multiple techniques address different components of web latency, each appropriate for different aspects of the infrastructure.

Geographic distribution, CDN and edge networks: deploying content and compute closer to users reduces propagation delay, the physics-based latency component. CDN edge servers cache content at locations near users, reducing the distance requests must travel for cached content. Edge computing platforms execute application logic at edge nodes, reducing propagation delay for dynamic content and redirect processing.

Connection reuse, HTTP keep-alive: reusing TCP connections for multiple requests eliminates connection establishment overhead for subsequent requests. HTTP/2 multiplexes multiple requests over a single connection, connection reuse is automatic. HTTP/1.1 supports keep-alive connections but handles only one request at a time on each connection. Connection reuse is particularly beneficial for pages loading many resources from the same server.

TLS session resumption: resuming established TLS sessions for reconnecting clients eliminates the TLS handshake overhead. TLS 1.3 session tickets enable 1-RTT resumption. 0-RTT resumption, TLS 1.3’s most aggressive optimisation, enables data to be sent in the first packet of a resumed connection, eliminating TLS handshake latency entirely for reconnections. 0-RTT has security trade-offs, replay attack vulnerability, that limit its use to safe idempotent requests.

DNS pre-resolution, dns-prefetch: browsers can be instructed to resolve DNS for anticipated domains before users navigate to them. <link rel="dns-prefetch" href="//cdn.example.com"> in HTML instructs the browser to resolve cdn.example.com DNS in the background. When the browser later needs to connect to that domain the DNS lookup is already complete, saving 50-200ms of DNS resolution time.

Preconnect hints: <link rel="preconnect" href="https://cdn.example.com"> instructs browsers to establish TCP connections and TLS handshakes to anticipated origins before they are needed. For redirects that send users to known destinations preconnect hints on the redirect source page can pre-establish connections to redirect destinations, reducing post-redirect connection overhead.

HTTP/3 and QUIC: HTTP/3’s QUIC transport eliminates TCP head-of-line blocking and reduces connection establishment overhead, combining TCP and TLS handshakes into a single round trip. QUIC’s connection migration handles network changes, users switching from Wi-Fi to mobile data, without connection reestablishment. For mobile users on variable networks QUIC’s resilience to connection changes reduces latency spikes during network transitions.

Latency and SEO

Latency directly affects SEO through its impact on Core Web Vitals, Google’s user experience metrics that are direct ranking signals.

Largest Contentful Paint, LCP: measures the time until the largest content element, typically the hero image or main heading, is rendered. LCP is heavily influenced by TTFB, high server latency delays everything downstream. Google’s LCP threshold for a good score is under 2.5 seconds, server latency that consumes most of this budget leaves little room for network transfer and rendering. Edge computing and CDN deployment reduce server latency’s contribution to LCP.

Redirect impact on LCP: each redirect hop adds latency before the destination page begins loading, directly adding to LCP measurement. A 300ms redirect hop on a page that would otherwise achieve 1.8 second LCP pushes LCP to 2.1 seconds, still within the good threshold. Adding a second 300ms redirect hop pushes LCP to 2.4 seconds, approaching the poor threshold. Minimising redirect hops and using edge-executed low-latency redirects preserves LCP scores.

Crawl budget and crawl speed: Googlebot adjusts crawl rate based on server response speed, slower servers receive fewer crawl requests per time period. Lower latency origin servers support higher crawl rates, important for large sites that benefit from frequent crawling. Edge-served content and redirects provide fast responses to Googlebot, supporting higher crawl budget allocation.