What is round trip time?
Round trip time (RTT) is the delay between sending a signal to a server and getting the reply. It depends mostly on the distance between the two and the quality of the network in between, not on how fast your pages are built.
Every new connection a visitor opens pays this delay several times before the first byte of the page arrives, so a high RTT slows down everything else, including TTFB and LCP.
How this test works
Our server opens five connections to yours, one after another, and times how long each takes to be accepted. Opening a connection is one trip there and back, so that time is the round trip time. We look up your server’s address once beforehand, so the lookup isn’t counted. The headline figure is the median of the five.
The report shows the full path of a request step by step: the address lookup, each of the five connections, the TLS handshake and the wait for the first byte of the reply.
The route to your server
A signal doesn’t travel to your server in one jump. It is passed along a chain of routers, and each handover is called a hop. The chart in the report shows that chain in order: every router on the way, and how long its reply took to come back. The last row is the server that answers for your site, and its time is close to the round trip time itself.
If your site is behind a CDN such as Cloudflare, that last server is the CDN’s, and it is usually close by. The route will be short and the round trip time low wherever your own server is, because the test never reaches it: the CDN answers first. That is also what your visitors’ browsers connect to, so the figure is real, but it says nothing about the distance to your own server.
Read down the chart to see where the delay builds up. A big step between two rows usually marks a long stretch of cable, such as a link between countries or across an ocean. Times don’t always rise evenly, because routers answer this kind of question at low priority, so one slow row in the middle with quicker rows after it is not a problem.
Our own server isn’t allowed to trace routes, so a test server from Globalping, an open measurement network, does it, and the chart’s title names the city it ran from. The route from anywhere else will be different. If the chart is missing, that service was unavailable or over its hourly limit when you ran the test.
Testing from our server or from your browser
The choice in the form is where the test runs. From our server you get the round trip between two data centres: a clean measure of the network, but not from where you are.
From your browser, the page you are reading also times the site itself, on your device and over your own internet connection. A browser isn’t able to open a bare connection the way our server does, so it sends five real requests and times how long each reply takes to start. The first one also has to find the server and connect. The other four use the open connection, and the fastest of them is the closest a browser can get to a single round trip. It is still a little more than that, because it includes the time your server takes to reply.
So the two figures answer different questions. Ours is the network alone, from our location. Yours is the delay you actually experience, with your server’s reply time included. The verdict at the top then comes from your browser, and the rest of the report, measured from our server, stays as usual. The browser’s requests go straight from your device to the site you are testing, as they would if you opened it in a tab.
How this compares with RTT in Google’s reports
Google’s Chrome UX Report also has a metric called round trip time, and it is not the same thing. Google describes its RTT as a measure of the people who visit a site, not of the site: Chrome estimates how responsive each visitor’s own internet connection is, from their recent browsing, and the report collects those estimates. A site whose visitors are mostly on mobile networks will have a high RTT there however close its server is.
Our figure from our server is the opposite view: one fixed vantage point, measuring the path to your site. The two can differ a lot and both be right.
When you test from your browser, we also show the figure Chrome’s reports are built from: your browser’s own estimate of the round trip time on your connection. Treat it as background. It describes your connection in general, not the path to the site you are testing, the browser rounds it to the nearest 25 ms, and only Chrome and browsers based on it provide it. In other browsers that tile is left out.
What is a good result?
A round trip of 100 ms or less scores the full 100 points. Above that the score falls in a straight line, one point for every extra millisecond: 150 ms scores 50, and 200 ms or more scores 0. These are our own working marks, not an official standard.
What this test can’t tell you
We measure from a single location: our server. Visitors who are closer to or further from your server will see different numbers, so treat the result as a guide, not as what every visitor experiences. A low RTT also doesn’t mean a fast page. It only rules out the network as the cause.