A good time to first byte, by the benchmark Google’s web.dev team publishes, is 0.8 seconds or less. That number gets quoted everywhere. What gets quoted less often is the sentence that follows it in spirit: TTFB is a diagnostic, not a score you are judged on directly.
That distinction changes how much effort it deserves. A slow server response is rarely the only reason a page feels slow, but it is the one problem that delays every other metric, because nothing can render until the first byte arrives.
What TTFB actually measures
The web.dev article on Time to First Byte (TTFB) defines it plainly: “TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.”
That window is wider than “how fast is my server”. It covers several phases, any of which can be the slow one:
| Phase included in TTFB | What can slow it down |
|---|---|
| Redirect time | Each extra hop before the final URL |
| Service worker startup | A service worker that has to boot before handling the request |
| DNS lookup | Slow or distant DNS resolution |
| Connection and TLS negotiation | Physical distance between visitor and server |
| Request, until the first byte arrives | Server processing: application code, database queries, no cache |
The practical consequence: a site can have a fast server and still post a poor TTFB, because a redirect or a long round trip sits in front of it. Before you blame the host, check which phase the time is going into. The timing breakdown in your browser’s developer tools splits the request into these stages.
What is a good time to first byte?
The web.dev guidance is that “Most sites should strive to have a TTFB of 0.8 seconds or less.” Above 1.8 seconds is classed as poor.
| TTFB | Rating |
|---|---|
| 0.8 seconds or less | Good |
| Between 0.8 and 1.8 seconds | Neither good nor poor; worth investigating |
| Over 1.8 seconds | Poor |
Note the word “most”. The threshold is a rough guide for typical server-rendered pages. A site that does a lot of work on the server before sending anything will naturally sit higher, and that can be a sound trade if the HTML that arrives is complete.
It also varies by page type on the same site. A cached article and an uncached search results page can sit on either side of the line, served from the same server. Looking at one average across the whole domain hides that, so break the figure down by template before deciding there is a problem.
TTFB is not a Core Web Vital
This is the part most TTFB guides skip. Google’s Core Web Vitals are LCP, INP and CLS. TTFB is not among them, and web.dev is explicit about what that means: “it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.”
So the question is not “is my TTFB under 0.8 seconds?” but “is my TTFB stopping my LCP from being good?” Because the largest element cannot appear before the HTML starts arriving, server response time is the first slice of every Largest Contentful Paint measurement. If your LCP passes comfortably, a slightly slow TTFB is a low priority.
If you are looking at a failing assessment in Search Console, TTFB is one of the first things to rule in or out. Our guide to a Core Web Vitals assessment that failed walks through that diagnosis in order.
How to improve time to first byte
The fixes follow the phases. Work out which one is slow, then pick the lever that addresses it.
Caching
For most content sites, the biggest win is not generating the same page from scratch on every request. Full-page caching serves stored HTML instead of running the application and database queries each time. Object caching helps where full-page caching is not possible, such as logged-in views.
Watch the cache hit rate, not just whether caching is switched on. A cache that is cleared on every publish, or that varies on cookies and query strings it does not need to, can leave most real visitors hitting the slow path. Crawlers often request less popular pages that are not warm in the cache at all, so their experience can be worse than a quick check of the homepage suggests.
Hosting and server work
If uncached responses are slow, the server is doing too much or has too little to do it with. Slow database queries, heavy plugins and under-provisioned shared hosting all show up here. Upgrading hosting helps, but only after you know the bottleneck is capacity rather than code. A query log or an application profiler will usually show whether a handful of slow queries account for most of the wait.
A CDN
A content delivery network shortens the distance between visitor and response. That cuts connection and TLS time, and if the CDN caches HTML at the edge, it removes the trip to your origin server entirely for cached pages.
Fewer redirects
Every redirect adds a full request before the real one starts, and all of it counts towards TTFB. Internal links that point at old URLs, or http-to-https-to-www chains, are common culprits. Our guide to redirect chains covers finding and flattening them.
How to check time to first byte
Measure it in two ways, because they answer different questions. Lab tools such as the network panel in your browser’s developer tools show the breakdown for a single request from your location, which is ideal for diagnosis. Field data, collected from real visitors, shows what people actually experience across devices, networks and countries.
The two will rarely agree. A test from a fast office connection close to the server will flatter the result; visitors on mobile networks on another continent will see something worse. Check a cached page and an uncached one separately, and test from more than one location if your audience is spread out.
One limitation is worth stating. TTFB tells you that the first byte was late, not why. A single number cannot separate a slow database from a distant visitor or a redirect hop, so treat it as the start of an investigation rather than its conclusion. For the wider picture of how speed fits into rankings, see our guide to page speed and SEO.
Frequently asked questions
What is a good TTFB?
web.dev says most sites should strive for a TTFB of 0.8 seconds or less. Over 1.8 seconds is considered poor.
Is TTFB a Core Web Vital?
No. It is a diagnostic metric. Google’s guidance says meeting the good threshold isn’t strictly necessary, as long as it doesn’t stop you scoring well on the Core Web Vitals.
Does TTFB affect LCP?
Yes. The largest element cannot render before the HTML starts to arrive, so a slow TTFB delays Largest Contentful Paint directly.
What is the fastest way to improve TTFB?
For most sites, page caching and a CDN, then removing unnecessary redirects. Hosting upgrades help once you know the server itself is the bottleneck.
The takeaway Aim for 0.8 seconds or less, but judge TTFB by its effect on LCP. Find the slow phase first, then fix it with caching, a CDN or fewer redirects.
