When someone opens your website, there is a brief moment where nothing seems to happen. The browser has asked your server for the page, and it is waiting for a reply. The time it takes for that first piece of data to arrive is called Time to First Byte, or TTFB. It is one of the simplest performance metrics you can measure, and it tells you a lot about how responsive your server really is.
In this guide, we will break down what TTFB means, how it is measured, what a good value looks like, and the practical steps you can take to bring yours down.
TTFB stands for Time to First Byte. It measures the time between the moment a browser sends a request to your server and the moment the very first byte of the response comes back. Everything else on the page, images, stylesheets, scripts, still has to download after that, but TTFB captures how quickly your server starts working on the request.
Think of it like calling a restaurant. TTFB is not how long the food takes to arrive; it is how long it takes for someone to pick up the phone and say hello. If nobody answers for ten seconds, the whole experience feels slow no matter how good the kitchen is.
TTFB is usually measured in milliseconds (ms). It is influenced by three things:
A slow TTFB means your server is the bottleneck. A fast TTFB means your server answers quickly, and any remaining slowness comes from how the page itself is built. Knowing which one is the problem saves you from fixing the wrong thing.
Every browser's developer tools show TTFB in the network tab: it is the waiting time for the initial document request. But your own connection only tells part of the story. Your visitors come from different cities and different networks, so it helps to check your response time from multiple angles.
A quick way to get a first impression of your server's responsiveness is to run an online ping website tool against your domain. It tells you whether your server is up and how fast it answers, which is a useful sanity check before you dig into deeper page-level analysis.
For a fuller picture, combine that with a full page audit. A page speed checker measures how the entire page loads in a real browser, while the PageSpeed Insights checker pulls in Google's field data and lab scores, including TTFB context alongside metrics like Largest Contentful Paint. If the full-page scores look bad but TTFB is fine, your server is off the hook and the page itself needs work.
Google has never published a hard TTFB target, but the widely accepted guideline is:
A couple of caveats. First, TTFB depends on where you measure from. A visitor next door to your data center will see a much lower number than someone on the other side of the planet. Second, TTFB is not a Core Web Vital itself, but it feeds directly into them. If your server takes a full second to answer, your Core Web Vitals scores, especially Largest Contentful Paint, will suffer because everything else waits in line behind that first byte.
Most slow TTFB values come down to a handful of usual suspects:
The good news is that TTFB problems usually have clear fixes. Here is a practical checklist, ordered from highest impact to lowest:
A typical example of what these steps look like in practice:
# Enable gzip compression (Apache .htaccess example)
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript
</IfModule>
# A single direct redirect instead of a chain
Redirect 301 /old-page https://example.com/new-pageAfter making changes, re-test. TTFB improvements should be visible immediately, since you are measuring the server's raw response rather than a cached browser result. Run the check a few times and look at the median, not a single lucky run.
TTFB is only one part of the loading story. It is worth knowing how it relates to the other numbers you will see in speed reports:
If TTFB is low but FCP and LCP are high, your server is fine and the problem is on the page: too many images, render-blocking scripts, or heavy CSS. If TTFB itself is high, start at the server, because nothing downstream can load before that first byte arrives.
TTFB is a small metric with an outsized message. It isolates your server's performance from everything else on the page, so a high value tells you exactly where to look first. Get your server answering in well under half a second with good hosting, caching, and a CDN, and you give every other optimization on your page a much better starting line.
Curious how fast your server actually answers? Run your domain through our online ping website tool to check your site's response time in seconds, then follow up with a full page speed audit to see the complete picture.
TTFB stands for Time to First Byte. It is the time between a browser requesting a web page and receiving the first byte of the server's response, measured in milliseconds.
No, TTFB is not one of Google's Core Web Vitals. However, it directly affects Largest Contentful Paint, which is a Core Web Vital, because no content can load before the first byte arrives.
Under 200 milliseconds is excellent, 200 to 500 ms is good, 500 to 1000 ms needs attention, and anything over 1000 ms is poor and points to a server-side bottleneck.
Repeat visits benefit from browser cache, which can hide a slow server. Test in an incognito window or with a fresh audit to see the true server response time.
A CDN helps a lot with the network distance part of TTFB by serving cached pages from locations near your visitors. It cannot fix a slow origin server for uncached, dynamic requests, so caching and hosting still matter.
