Glossary
Time to first byte (TTFB)
Time to first byte is the wait from the start of a request until the first byte of the response arrives back at the browser.
Also called TTFB.
Time to first byte, or TTFB, measures how long a browser waits before the server's answer starts to arrive. Google's web.dev guide defines it as the sum of several phases: any redirects, service worker startup if the site has one, the DNS lookup, the connection and TLS negotiation, and the request itself, up to the moment the first byte of the response comes back. It stops there, so the size of the page does not affect it.
Because it comes first, a slow TTFB delays everything after it, including the first paint and the largest one. web.dev offers a rough guide: 0.8 seconds or less is good, and over 1.8 seconds is poor. It also says TTFB is not a Core Web Vital, so missing the good mark is not a failure in itself if the page still shows its main content quickly. A single-page app, whose first response still needs JavaScript to fill it in, benefits most from a low TTFB, while a server-rendered page can afford a higher one and still paint sooner.
Most of what lowers TTFB sits in front of your code: serving from a CDN edge near the visitor, caching whole pages so the origin is not asked at all, removing redirect chains, and keeping connections alive so repeat requests skip connection and TLS setup. The rest is the server's own time to build the response, such as slow database queries or work done before anything is sent. Measure before and after any optimization, because a cache hit can make a slow backend look fast.
| Rating | TTFB | What it suggests |
|---|---|---|
| Good | 0.8 seconds or less | The server and the path to it answer promptly. If the page is still slow, look at what happens after the first byte. |
| Needs improvement | Over 0.8 and up to 1.8 seconds | Worth checking redirects, caching and how long the server takes to build the page. |
| Poor | Over 1.8 seconds | Everything the visitor sees starts late. Find which phase is slow before changing anything. |
Questions
What is a good TTFB?
web.dev's rough guide is 0.8 seconds or less. Between 0.8 and 1.8 seconds needs improvement, and over 1.8 seconds is poor. Because TTFB is not a Core Web Vital, a page can miss that mark and still load well, as long as its main content appears quickly.
What is the difference between TTFB and response time?
TTFB has a precise definition: it stops at the first byte of the response and includes redirects, DNS, connection and TLS time. "Response time" has no single definition. Some tools stop the clock when the whole body has arrived, some when the headers have, and many leave out redirects or connection setup. Compare the two only when you know what each tool measured.
What does TTFB include?
Five phases, in order: redirects, service worker startup if the site uses one, the DNS lookup, the TCP connection and TLS negotiation, and the request itself up to the first byte of the response. It does not include downloading the rest of the response, or anything the browser does with it afterwards.
How do you measure TTFB?
In the lab, the network panel in Chrome DevTools shows it for each request, and WebPageTest reports it for a full page load. For real visitors, the Chrome User Experience Report publishes field data, and the web-vitals JavaScript library can measure it in your own pages. Lab numbers show one load from one place; field numbers show what visitors actually got.
Does Uptimely report TTFB?
No. Uptimely does not report a TTFB figure. Its website and API checks record response time, which runs from sending the request until the response headers arrive, before the body is read, with redirects followed. Each check opens a new connection, so connection and TLS setup are counted every time, and every check runs from one server rather than from your visitors' browsers. Treat it as evidence that your site answers, not as a TTFB measurement.
Uptimely does not report TTFB. It checks whether your site answers, as often as every minute on every plan, and records how long each check took.
Start monitoring free →Related terms
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.