What Is Network Round Trip Time (RTT)? Complete Guide (2026)

Why RTT Matters Even for Fast Servers

• Every connection multiplies it. Each new origin requires TCP setup (1 RTT) plus TLS handshake (1–2 RTTs). At 100 ms RTT, every cold third-party origin adds 200–300 ms before the first request even leaves.
• It bounds TTFB from below. If RTT is 200 ms, your TTFB is at least 200 ms beforeserver processing — which means you've already burned 25% of Google's 800 ms TTFB budget on physics alone.
• It compounds across the load. A typical page makes 30–50 connections (HTML, CSS, JS, fonts, images, ads, analytics). Many resolve in parallel via connection coalescing, but cold third-party origins add full RTT each.
• It's the largest gap between regions. A user 50 km from your origin might see 5 ms RTT; a user 8,000 km away sees 130+ ms. That's a 26× spread in just the network — independent of any code you write.
• Indirect ranking impact. RTT directly affects TTFB, FCP, and LCP. LCP is a Core Web Vital, so users in high-RTT regions see degraded ranking-relevant metrics — and Google measures these per-region in real-user data.

Why Distance Sets a Hard Floor

Light travels through fiber at roughly two-thirds of its vacuum speed — about 200,000 km/s. That number is the unbreakable floor. The actual best-case RTT between two points is:

Theoretical minimum RTT = (2 × distance) / 200,000 km/s

  London ↔ New York   (~5,500 km):   ~55 ms minimum
  New York ↔ Sydney   (~16,000 km):  ~160 ms minimum
  Tokyo ↔ Frankfurt   (~9,500 km):   ~95 ms minimum
  Same city           (~50 km):      ~0.5 ms minimum

Real-world RTT is typically 1.5× to 2.5× the theoretical floordue to routing, congestion, peering, and last-mile networks (especially mobile and rural connections). London ↔ New York "in real life" is usually 80–120 ms.

How RTT Multiplies in HTTPS Connection Setup

A single HTTPS connection requires several round trips before any application data flows:

Bottom line: Upgrading from HTTP/1.1 + TLS 1.2 to HTTP/3 with TLS 1.3 saves 2 round-trips on every cold connection — a 200 ms latency gift for users at 100 ms RTT, paid for every visit and every new origin.

How to Check RTT

• Greadme's deep scan — surfaces TTFB along with its network and server-processing components, identifying which routes have the worst RTT-driven latency. Pairs every issue with an AI-generated fix or one-click GitHub PR. Recommended starting point.
• Greadme's crawler scan — measures origin response across every indexable URL on your site so you can see which regions or origins have the worst RTT footprint.
• Chrome DevTools → Network tab → Timing panel — for any request, the "Connection Start" segment (DNS + initial connection + TLS) is essentially RTT × number of handshake round-trips.
• Command-line ping — ping example.com from different locations gives you a quick RTT baseline. Use a service like a global ping checker to measure from multiple regions at once.
• Google Search Console → Core Web Vitals report — slow LCP issues that vary by country are usually RTT-driven. Use the per-country breakdown to spot regional gaps.
• web.dev articles — Google's reference docs on TTFB, HTTP/3, and CDN strategy are the primary sources for the techniques below.

8 Proven Ways to Reduce the Impact of RTT

<link rel="preconnect" href="https://fonts.example.com">
<link rel="preconnect" href="https://api.example.com">
<link rel="dns-prefetch" href="https://analytics.example.com">

Common RTT Problems and Fixes

How RTT Cascades Into Other Metrics

Bottom line:RTT sets a hard floor for every other metric. No amount of code optimization can rescue a page where the user is 200 ms away from a single origin and there's no CDN.

FAQ

What is a good network RTT?

For users near your origin, target ≤ 50 ms. Globally, with a properly configured CDN, you should see < 100 ms for the vast majority of users. Anything over 150 ms means the user is intercontinental from your nearest edge node — usually fixable by adding more PoPs.

How is RTT different from server latency?

RTT is the network travel time — bounded by physics. Server latency is the time your server spends processing the request after it arrives — bounded by your code and infrastructure. Both add into TTFB; the fix for each is different (CDN for RTT; caching/queries for server latency).

Will a CDN always reduce my RTT?

Almost always yes — for users near a CDN edge node. A CDN's edge nodes are deployed in major data-center hubs worldwide, so most users are within 200 km of one (~5 ms RTT). Users in remote regions with no nearby PoP see less benefit.

Why is HTTP/3 better than HTTP/2 for high-RTT users?

HTTP/3 combines TCP and TLS handshakes into a single 1-RTT setup, vs. HTTP/2's 2 RTTs (TCP + TLS 1.3) or 3 RTTs (TCP + TLS 1.2). At 100 ms RTT, that's a 100–200 ms savings on every cold connection. HTTP/3 also handles packet loss more gracefully on lossy networks (mobile, satellite).

Does RTT affect AI search engines like ChatGPT and Perplexity?

Indirectly. High RTT inflates TTFB, which inflates LCP, which lowers Core Web Vitals scores, which lowers Google rankings — and AI search systems preferentially cite well-ranked pages. High RTT can also slow AI crawler bots, reducing how often they re-index your content.

How can I measure RTT from a user's perspective?

The Chrome User Experience Report (CrUX) doesn't directly expose RTT, but Google Search Console's Core Web Vitals report shows TTFB by country — high TTFB in regions far from your origin is almost always RTT-driven. For real-time data, the Network Information API exposes navigator.connection.rtt in supporting browsers.

What's the absolute minimum RTT possible?

Two times distance divided by the speed of light in fiber (~200,000 km/s). For a user 1,000 km from the nearest server, that's 10 ms minimum. Real-world RTT is typically 1.5–2.5× the theoretical floor due to routing and infrastructure overhead.