Round trip time (RTT)

What is round trip time (RTT)?

Round trip time (RTT) is the time it takes for a network request to travel from a client to a destination and for the response signal to return. In web delivery, RTT helps explain why two users can request the same page and see very different load times, even when the server and application code are unchanged.

RTT is usually measured in milliseconds, but it is not just a speed-test number. A web request can require several round trips before useful content is delivered: DNS resolution, TCP connection setup, TLS negotiation, HTTP request and response exchange, redirects, and additional requests for images, scripts, fonts, API data, and analytics. Reducing the number and distance of those round trips is one of the main reasons teams use CDNs, connection reuse, HTTP/2, HTTP/3, and careful page design.

Where RTT shows up in a page load

RTT affects every step that depends on a message crossing the network. A browser may first need to find the address for a hostname, connect to an IP address, negotiate encryption, ask for a document, parse it, then request the subresources referenced by that document. If each step waits on a response before the next one begins, even modest network latency becomes visible to users.

The physical and logical route both matter. A user in Sydney connecting to an origin in North America has a longer baseline RTT than a user close to that origin. A mobile user on a congested network may see high RTT even when geographically close. A request that passes through multiple proxies, security layers, and origin dependencies may also accumulate delay that a simple ping test will not reveal.

For web teams, the practical question is not only "what is the RTT?" It is "how many RTTs does this user journey require before it becomes usable?" Ten sequential API calls, each waiting on the previous one, will feel slow even if the backend is healthy.

How CDNs reduce the effect of RTT

A CDN reduces RTT impact by moving useful work closer to users. Static assets, cacheable pages, redirects, compression, TLS handling, and security checks can be handled at an edge location instead of forcing every request to cross a long route to the origin. When the edge can answer directly from cache, the origin RTT is removed from that request.

The benefit is clearest for public assets that are reused often: images, CSS, JavaScript, fonts, video segments, downloadable files, and stable HTML pages. The CDN can also help dynamic applications by keeping connections warm, terminating TLS near the user, coalescing requests, or routing origin fetches through a more predictable path. Those features reduce delay, but they do not make dynamic application work free.

RTT can also increase when delivery is misconfigured. Extra redirects, avoidable hostname changes, no connection reuse, a far-away origin, or a route that bounces traffic through an unexpected region can add round trips. Poorly placed authentication handoffs may add latency to the most important journeys.

Measuring RTT without fooling yourself

RTT is easy to measure badly. A ping to an origin may be blocked, deprioritized, or routed differently from HTTPS traffic. A single synthetic test location may miss problems seen by real users. Browser developer tools show request timing, but they represent one machine, one network, and one moment. Real user monitoring gives broader coverage, but it must be segmented by region, network type, browser, route, and cache status to be useful.

Good measurement separates client-to-edge latency, edge processing time, edge-to-origin latency, origin application time, and total response time. If a page is slow because every request is a cache miss, RTT to the origin matters. If only authenticated API calls are slow, cache and static-asset metrics will not explain it.

It is also worth distinguishing latency from throughput. RTT is about delay in exchanging messages. Bandwidth is about how much data can be transferred over time. A small HTML document can be delayed by high RTT even on a fast connection. A large video can require high throughput even if RTT is low.

Common causes of high or avoidable RTT

Distance is the obvious cause, but not the only one. Routing choices, peering problems, packet loss, congestion, DNS resolver behavior, mobile radio conditions, overloaded security devices, and cross-region origin dependencies can all raise effective RTT. In application design, chained redirects and sequential API calls often cause more visible damage than the network distance itself.

Cache misses are another common source. If a CDN edge does not have the object, it must fetch from the origin or another cache layer. That origin fetch adds a second path to the request. A low cache hit ratio, very short TTLs, broad cache keys, frequent purges, or unversioned assets can all increase the number of requests that pay origin RTT.

Operations and security implications

RTT is an operations signal as well as a performance metric. A sudden rise in edge-to-origin RTT can indicate an overloaded origin, failing dependency, routing incident, or attack traffic forcing expensive dynamic work. A regional RTT increase may point to a network provider or peering issue. A rise only on cache misses may point to purge activity, deployment changes, or cache-key fragmentation.

Security teams should watch RTT because attackers often create paths that are expensive to serve. Cache-busting query strings, random URLs, credential-stuffing attempts, scraping of dynamic pages, and repeated requests to uncached search endpoints can increase origin trips and expose latency under load. Edge filtering, rate limits, bot controls, and origin shielding reduce the number of hostile requests that can force long round trips to application infrastructure.

Origin protection matters. If attackers can bypass the CDN and connect directly to the origin, they can avoid edge controls and force long-haul requests onto infrastructure that was not sized for public exposure. Restricting origin access to trusted delivery layers, validating hostnames, and monitoring direct-origin traffic are part of managing RTT risk under pressure.

Practical ways to reduce RTT impact

Start with the request path. Remove unnecessary redirects, consolidate hostnames where sensible, enable modern TLS and HTTP versions, and keep critical assets cacheable with versioned URLs. Place origins near the users they serve or use regional origins when dynamic work genuinely needs to be close. Cache public assets at the edge, but keep private and state-changing routes explicit.

Then reduce the number of network waits. Avoid page designs where the browser must fetch one script, then discover another, then wait for an API response before rendering anything useful. Use server-side rendering, static generation, or edge caching where they fit the content model. For APIs, combine calls only when doing so simplifies the user journey without creating oversized responses or weaker cache boundaries.

Finally, monitor by route and region. Track client-to-edge latency, edge-to-origin latency, cache status, origin response time, connection errors, TLS errors, and status codes. Review the slowest journeys, not just the median. RTT is most useful when it helps teams find the avoidable waits that stand between a user action and a reliable response.