What Is Network Round Trip Time?#
Network round trip time (RTT) is how long a small piece of data takes to travel from one machine to a server and back. It is mostly set by distance and by the route between the two, and it is paid again on every round trip a connection needs, so a long RTT delays everything that loads from that server.
Key Facts (TL;DR)
- No official pass mark. Lighthouse reports RTT as an informative diagnostic and always scores it 1, so there is no Lighthouse "good" or "poor" RTT.
- Greadme's warning threshold is 100 ms per origin. It is a product guideline derived from published latency research, not an official rule, and it applies to a lab-test measurement taken from the test environment, not necessarily what your visitors experience.
- Distance sets a floor. Light in optical fiber covers about 200,000 km per second, so New York to London cannot take less than about 56 ms there and back.
- Every new connection pays it several times. TCP needs one round trip and a full TLS 1.2 handshake two more; TLS 1.3 needs one, and a resumed session can need none.
- The fixes move content closer or cut round trips: a CDN, a hosting region near your audience, HTTP/3, fewer origins, and preconnect hints.
Is There an Official "Good" RTT?#
No. It's worth being precise here, because RTT bands are often quoted as if they were a standard. They aren't, and the sources below say different kinds of things.
| Source | What it says | What kind of number it is |
|---|---|---|
| Lighthouse's Network Round Trip Times audit | Lists the RTT to each origin the page connected to and always scores 1 | An informative diagnostic: no pass or fail |
| High Performance Browser Networking | People report perceptible lag once a delay passes 100 to 200 ms, and an interaction past 300 ms is often called sluggish | A summary of how people perceive any delay, not an RTT standard |
| Greadme Page Audit | Flags an origin whose RTT is above 100 ms, and marks it poor above 300 ms | Greadme's own warning threshold, derived from the two rows above |
| web.dev, Time to First Byte | "As a rough guide", most sites should aim for a TTFB of 0.8 seconds or less | A target for TTFB, which RTT is one part of, measured from real visits |
Lighthouse's network-rtt audit describes high RTT as "an indication that servers closer to the user could improve performance", but sets no level for "high". Greadme had to choose one to decide when to offer an AI fix prompt, and chose 100 ms. That is the bottom of the 100 to 200 ms range in which people start to notice a delay, and a new HTTPS connection pays several round trips before its first byte, so a single round trip of 100 ms already adds a noticeable wait. It is also roughly twice the fiber round trip from New York to London, which points to a server a long way from the test environment. Above 300 ms, the point at which an interaction is often called sluggish, Greadme marks the origin poor.
Treat both numbers as a prompt to look, not as a verdict. An origin above the threshold can be harmless if nothing important waits for it, and an origin below it can still matter if the page connects to it many times in sequence.
Why RTT Matters Even for Fast Servers#
- Each new connection multiplies it. Before any HTML, CSS or image can be requested, the browser has to open a connection, and that takes one to three round trips depending on the protocol (see the table below).
- It is part of TTFB. web.dev defines Time to First Byte as the sum of redirect time, service worker startup, DNS lookup, connection and TLS negotiation, and the request up to its first byte. The DNS, connection, TLS and request phases are all made of round trips, so a long RTT raises TTFB before your server has done any work. See our guide to server response time.
- Third-party origins pay it separately. Fonts, analytics, chat widgets and embeds on other domains each need their own connection, and each of those servers can be at a different distance.
- It feeds the metrics Google uses. A longer TTFB delays First Contentful Paint and Largest Contentful Paint. LCP is a Core Web Vital, and Google's page experience documentation says Core Web Vitals are used by its ranking systems, while also saying relevance comes first.
Why Distance Sets a Floor#
High Performance Browser Networking uses about 200,000 km per second as the rule of thumb for light in optical fiber (a refractive index of about 1.5). That gives the shortest possible RTT for a route:
| Route | Distance | RTT in fiber, theoretical minimum |
|---|---|---|
| New York to San Francisco | 4,148 km | 42 ms |
| New York to London | 5,585 km | 56 ms |
| New York to Sydney | 15,993 km | 160 ms |
These are best cases. Real packets rarely travel in a straight line, and every hop adds routing, processing and queuing time: the same book puts the actual RTT between New York and Sydney at 200 to 300 ms. The last few miles add their own delay too. Citing the FCC's Measuring Broadband America reports, it gives typical last-mile latency in the United States as 10 to 20 ms on fiber, 15 to 40 ms on cable and 30 to 65 ms on DSL.
You Can't Beat Physics, Only Shorten the Distance
A CDN doesn't make data travel faster; it serves it from somewhere closer. As High Performance Browser Networking puts it, serving content "from a nearby location to the client" lets you "significantly reduce the propagation time" of every packet.
How RTT Multiplies in Connection Setup#
A new HTTPS connection needs several round trips before the browser can send its request:
| Transport and TLS | Round trips before the request | At 100 ms RTT |
|---|---|---|
| TCP + TLS 1.2, full handshake | 3 (1 for TCP, 2 for TLS) | 300 ms |
| TCP + TLS 1.3 (HTTP/1.1 or HTTP/2) | 2 (1 for TCP, 1 for TLS) | 200 ms |
| QUIC (HTTP/3) | 1 (transport and encryption together) | 100 ms |
| Resumed session with 0-RTT | 0 | 0 ms |
High Performance Browser Networking describes the TCP three-way handshake as "one full roundtrip" and says a full TLS 1.2 handshake needs two more, while TLS 1.3 was designed for "1-RTT for new, and 0-RTT for resumed sessions". QUIC, the transport HTTP/3 runs on, combines the transport and cryptographic handshakes "to minimize connection establishment latency" (RFC 9000): the client sends its first request after the server's first reply. 0-RTT has a cost, though: the TLS 1.3 specification (RFC 8446) warns that its security properties are weaker and that "there are no guarantees of non-replay between connections".
View the data as a table
| Protocol | Setup time at 100 ms RTT |
|---|---|
| TCP + TLS 1.2 (3 round trips) | 300 ms |
| TCP + TLS 1.3 (2 round trips) | 200 ms |
| QUIC / HTTP/3 (1 round trip) | 100 ms |
| Resumed with 0-RTT (0 round trips) | 0 ms |
Source: worked example from this article (100 ms × the round trips in the table above).
How to Check RTT#
- Greadme Page Audit shows a Network Round Trip Times card that lists the RTT to every origin the page connected to, measured in one lab test from the test environment. Origins above 100 ms are highlighted, and the card then offers a Copy as Prompt button with the slow origins and what to check. Its Server Backend Latencies card shows the other half: how long each server took to start answering.
- Chrome DevTools, Network panel, Timing tab: for a single request, the Initial connection phase (TCP handshakes and TLS negotiation) shows what connection setup cost on your own connection.
- The Chrome UX Report: its Round Trip Time metric estimates real visitors' RTT, and Google notes it is "a measure of the users to your site (based on their recent internet activity), and not of the site itself". Use it to see what your audience's connections are like, and its TTFB data to see the effect on your pages.
- Google Search Console, Performance report: its Countries tab shows where your search visitors come from, which tells you which regions a CDN or a second hosting region should cover. It contains no speed data.
- Greadme Site Audit crawls up to 1,000 pages of your site, so you can pick one page per template to test with a Page Audit. The crawl itself checks SEO, images and page structure, not speed.
7 Ways to Reduce the Impact of RTT#
1. Serve Content from a CDN
The most direct fix: a CDN answers from a location near each visitor, so the distance, and with it the RTT, is shorter. It helps most for content that is the same for everyone and can be cached at the edge; uncached, personalized responses still travel to your origin.
2. Host Close to Your Audience
If most of your visitors are on one continent and your origin is on another, every uncached request crosses that distance. Use Google Search Console's Countries tab or your analytics to see where visitors are, and host, or add a region, accordingly.
3. Enable HTTP/3 and TLS 1.3
Moving from TCP with TLS 1.2 to QUIC removes two round trips from every new connection, which is 200 ms at a 100 ms RTT in the worked example above. Most CDNs and modern web servers support both; in Chrome DevTools, the Network panel's Protocol column shows h3 when HTTP/3 is in use.
4. Preconnect to Critical Third-Party Origins
A preconnect hint tells the browser to open the connection to an origin before it finds the first request for it, so the handshake overlaps with other work instead of delaying the resource. Use it for the one or two origins the page needs early, such as a font or image host. See our guide to preconnect.
<link rel="preconnect" href="https://fonts.example.com" crossorigin>
<link rel="dns-prefetch" href="https://analytics.example.com">5. Load From Fewer Origins
Each additional domain needs its own DNS lookup and connection setup. Self-hosting fonts and small libraries keeps them on a connection the browser already has, and removing third-party scripts the page doesn't need removes their connections entirely.
6. Reuse Connections
HTTP/1.1 "defaults to the use of persistent connections" (RFC 9112), and HTTP/2 and HTTP/3 carry many requests over one connection, so the setup cost is paid once per origin rather than once per file. Check that nothing in your server or proxy configuration closes connections after each response.
7. Allow TLS Session Resumption
For returning visitors, resuming an earlier TLS session skips part of the handshake: High Performance Browser Networking notes that the abbreviated handshake "eliminates a full roundtrip of latency" in TLS 1.2, and TLS 1.3 can resume with 0-RTT, with the replay caveat above. Modern servers and CDNs support resumption; it is mostly a matter of not disabling it.
Common RTT Problems and Fixes#
Problem: One Origin Serving a Worldwide Audience
What's happening: the server is in one region, so visitors on other continents pay the long-distance RTT on every uncached request.
Fix: put a CDN in front of the origin, and for dynamic pages consider rendering closer to visitors, for example in an edge runtime or a second region.
Problem: Many Third-Party Origins
What's happening: analytics, ads, chat, fonts and embeds each add a connection, and some of their servers may be far from your visitors.
Fix: remove what the page doesn't need, load the rest after the main content, self-host what you can, and preconnect to the few origins that are needed early.
Problem: An Old Protocol Stack
What's happening: the server still negotiates TLS 1.2 over TCP, so every new connection costs three round trips.
Fix: enable TLS 1.3 and HTTP/3 (keeping HTTP/2 as the fallback). On most CDNs this is a setting.
How RTT Affects Other Metrics#
| Metric | Good, at the 75th percentile of visits | How RTT affects it |
|---|---|---|
| Time to First Byte (TTFB) | 800 ms or less | DNS, connection, TLS and the request itself each take at least one round trip. |
| First Contentful Paint (FCP) | 1.8 s or less | Nothing can paint before the HTML arrives, so TTFB comes first. |
| Largest Contentful Paint (LCP) | 2.5 s or less | An LCP image on another origin waits for that origin's connection too. |
These are web.dev's field thresholds, measured on real visits. A lab test such as a Page Audit reports one run from one location, so use it to find causes and the field data to judge the result.
FAQ#
What is a good network RTT?
There is no official threshold: Lighthouse reports RTT without a pass mark. Greadme Page Audit flags an origin above 100 ms as a product-defined warning, because 100 ms is where the range of delays people start to notice begins, and a new connection pays the RTT several times. Distance sets what is achievable: about 56 ms is the theoretical minimum in fiber between New York and London, so an RTT under that between those cities isn't possible.
How is RTT different from server latency?
RTT is the time the network takes to carry data there and back. Server latency is the time the server spends before it starts answering. Both are part of TTFB, and the fixes differ: distance and round trips for RTT, caching and back-end work for server latency. See our guide to network server latency.
Will a CDN always reduce my RTT?
For visitors near one of its locations and for content it can cache, yes. Requests it has to pass to your origin, such as uncached or personalized pages, still travel the full distance from the CDN to your server.
Why does HTTP/3 help visitors far from my server?
Because it needs fewer round trips to set up a connection: one for QUIC, against two for TCP with TLS 1.3 and three for TCP with TLS 1.2. The longer each round trip, the more those savings are worth.
How can I measure RTT from my visitors' side?
The Chrome UX Report's Round Trip Time metric estimates the RTT of real Chrome users' connections, which describes your audience's networks rather than your site. In the browser, navigator.connection.rtt returns an estimate rounded to the nearest 25 ms, but MDN lists it as limited availability: it doesn't work in some widely used browsers.
Why does Greadme's RTT differ from what I see?
Greadme Page Audit reports the RTT measured to each origin in one lab test, from the test environment. Your own connection, and your visitors', start from somewhere else, so their RTT to the same server can be much shorter or much longer.
Conclusion#
RTT is set mostly by distance, and every new connection pays it more than once. There is no official pass mark for it; Greadme flags origins above 100 ms as a guideline, not a rule. To reduce its cost, serve content from closer to your visitors, cut the round trips each connection needs with TLS 1.3 and HTTP/3, and connect to fewer origins.
Run Greadme Page Audit on your key pages to see the RTT to every origin they load from, with a copy-ready prompt for any origin above the threshold.