What is TTFB?
Time to First Byte (TTFB) is the wait between asking for a page and receiving the very first piece of it. Nothing can appear on screen before that moment, so a slow TTFB delays everything else on the page.
The wait has two parts: the network (finding your server, connecting, setting up encryption) and your server’s own thinking time while it builds the page. This test shows both, so you know which one to fix.
How this test works
Our server requests your page three times and keeps the middle result. We time each stage separately: the address lookup, the connection, the TLS handshake and the wait for the first byte. At the same time we ask independent test servers in Frankfurt, New York, São Paulo, Johannesburg, New Delhi, Singapore, Tokyo and Sydney to load the same page and report their own timings. Those servers belong to Globalping, an open measurement network. If it has no free server in one of those cities at that moment, that city is left out of the report.
The map shows each place we measured from as a dot: green for a first byte within 0.8 seconds, amber up to 1.8 seconds, red beyond that. Hover over a dot, or tap it, to see the city and its time; the table under the map has the same figures. The outlines come from Natural Earth, a public-domain map dataset.
The coloured ribbon in the report, “What the wait is made of”, lays that request out as one line, in the order things happen. Each colour is a stage, and its width is its share of the time:
- Redirect: being sent on from the address you entered to another one. It appears only if that happened;
- DNS: finding your server’s address;
- Connect: opening a connection to it;
- TLS: setting up encryption, on https pages;
- Request: sending the request for the page;
- Waiting: your server preparing the reply;
- Download: receiving the page itself.
The bracket above the ribbon marks TTFB. It runs from the very start to the end of Waiting, so it includes any redirects, as a browser’s own measurement does. Download comes after the first byte and is drawn in grey: it is shown so you can see the whole request, but it is not part of TTFB.
We follow up to five redirects, timing each one, and measure the page they lead to. If your server sends Early Hints, a dashed line on the ribbon shows when they arrived. Most servers send them only over the newer HTTP/2 or HTTP/3, so our test asks for the page over HTTP/2, the way browsers do. If a site doesn’t support HTTP/2, or our own server can’t use it, the test falls back to HTTP/1.1, and then “Not sent” doesn’t prove your visitors don’t get them. In the report, the first “Server” tile shows which one was used.
A browser’s own timeline has two more stages that we can’t show, because they happen inside the visitor’s browser and not on the network: starting a service worker, and checking the browser’s cache.
The report adds the details of that request: the HTTP code your server answered with, the size of the request we sent, the size of the reply’s headers and of the page as it was transferred, and the download speed. We don’t show an upload speed, because loading a page sends only a few hundred bytes, far too little to measure one.
The report also shows the route to your server: every router (“hop”) a request passes through on the way, and how long each one took to answer. Our own server isn’t allowed to trace routes, so a Globalping test server does it, and the table names the city it ran from. The route from other places will be different. A hop marked “no reply” is a router that is set up not to answer; that is normal and doesn’t mean a fault.
What the network setting does
We can’t put a real phone on a real 3G or Wi-Fi network, so this number is an estimate. We take the request we measured and add a typical delay to every trip to your server and back: 300 ms on 3G, 170 ms on 4G, 20 ms on 5G and 10 ms on Wi-Fi. These delays are our working assumptions. Real networks vary a lot with signal strength and how busy the network is.
A browser makes several of these trips before the first byte can arrive: one to find your server’s address, one to open a connection, one or two to set up encryption, and one to ask for the page. The report lists each trip with the time we measured and the time we estimate on the network you chose.
What the phone setting does
A phone’s processor has almost no effect on TTFB, because the waiting happens on the network and on your server. What can change is the page itself: some sites send different pages to different devices. So we make the request the way that phone’s browser would, with the name of our bot, SeoklaBot, added so that site owners can see where the request came from. You see the wait your server gives that phone. A site that treats unfamiliar bots differently from real visitors may answer our request differently too. On most sites all five phones will get the same result, and that is the correct answer. The phone setting applies to our own server’s measurement only; the Globalping cities are measured without it.
What is a good result?
Google suggests a TTFB of 0.8 seconds or less and treats anything over 1.8 seconds as poor. Our score follows those two marks. Google itself calls 0.8 seconds a rough guide, not a rule, and applies it to real visits: three out of four should be that fast. Our figure is a single test from one place, so read it as an indication.
TTFB is not one of Google’s Core Web Vitals. It matters because of what comes after it: the page can’t start to appear until the first byte has arrived, so a slow TTFB holds back the metrics that are Core Web Vitals, such as LCP.
How much it matters depends on how the site is built. A site that sends a nearly empty page and builds the content in the browser with JavaScript needs a very quick first byte, because the real work only starts after it. A site that prepares the whole page on the server can have a slower first byte and still show its content sooner. So a high TTFB is a reason to look closer, not proof that the page is slow.
The report also shows the round trip time (RTT): how long one trip to your server and back takes from our server. We take it from the time it took to open the connection, which is exactly one such trip. Every stage before the first byte costs at least one of these trips, so a high RTT raises TTFB whatever your server does. For a closer look, with more samples, use our Round Trip Time test.
Testing from our server or from your browser
The first choice in the form is where the test runs. From our server you get the full report described on this page, including the map and the other locations.
From your browser, the page you are reading also measures the site itself, on your device and over your own internet connection. It asks for the address five times and times how long each reply takes to start. The first request has to find the server and open a connection, so it is the closest to what a new visitor in your place would wait. The other four reuse that connection and show the wait once it is open. The verdict at the top of the report then comes from your browser.
This answers a question our server can’t: how long do you, where you are, wait for this site? A browser isn’t allowed to see the separate stages or the headers of another site’s reply, so our server still measures those, and the rest of the report is the same as usual. Only the map and the list of locations are left out, since the point of this mode is your own location. 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.
What the reply itself tells us
Along with the page, a server sends headers, and some of them explain the wait. We read three things from them.
- Whether the page came from a cache. CDNs and caching plugins label each reply as a stored copy or as freshly built. A stored copy is the fastest answer a server can give; a page built from scratch for every visitor is the most common reason for a slow first byte.
- What the server says about its own time. Some servers add a Server-Timing header that breaks their work into parts, such as the database or the page template. If yours does, we show it as a table. If the table is missing, your server doesn’t send this header.
- Whether HTTP/3 is on offer. A server announces it in a header, and browsers then use it on later visits to connect in fewer trips. We don’t suggest turning it on if it already is.
Early Hints and what counts as the first byte
There is one case where our TTFB and a browser’s differ. If a server sends Early Hints, Chrome treats that early reply as the first byte, so its TTFB stops there. Ours runs to the first byte of the page itself, which comes later. When we see Early Hints, the report shows both figures. Keep this in mind when comparing numbers from different tools: check which moment each one measures to.
What this test can’t tell you
It checks one page at one moment. A page that is cached will answer faster than one that isn’t, so results can differ between runs. For what your real visitors experience over time, look at field data such as the Core Web Vitals report in Google Search Console.