Time to first byte is how long the browser waits between asking for a page and receiving the first byte of the response. Nothing else can start until it arrives.
That makes it the one number with leverage over everything else. Largest Contentful Paint cannot be faster than TTFB. Neither can First Contentful Paint. Shorten this wait and every downstream metric improves without you touching them.
What counts as good
Two published thresholds, from two different sources, which is why tools disagree about your score.
Google's field threshold is 800 ms. That is the Chrome User Experience Report's cut-off for "good", measured at the 75th percentile of real users. It includes their network latency and their distance from your server.
Lighthouse flags anything over 600 ms. Its server-response-time audit uses the tighter number because it measures a single request from a well-connected machine, where network conditions are not part of the excuse.
Neither is wrong. They are measuring different things:
| Lighthouse / lab | CrUX / field | |
|---|---|---|
| Threshold | 600 ms | 800 ms |
| Measured from | One data centre | Real users, worldwide |
| Includes user latency | No | Yes |
| Reflects your audience | No | Yes |
The Website Speed Test shows both, and states which threshold each figure was judged against.
What the wait is actually made of
TTFB is not one thing. It is five, and they have completely different fixes:
- DNS lookup — resolving your domain to an IP address. Usually 20–120 ms, and zero on repeat visits because it is cached.
- TCP connection — the handshake. One round trip, so it scales with distance.
- TLS negotiation — setting up encryption. One or two more round trips depending on TLS version.
- Request travel time — the request physically crossing the distance to your server.
- Server processing — your application generating the page.
Points 2, 3 and 4 are all distance. Point 5 is your code. Telling them apart is the whole diagnostic, because the fixes are unrelated: distance is solved with a CDN, processing is solved with caching and database work.
Measuring from several locations is what separates them. If TTFB is 180 ms from a nearby region and 900 ms from a distant one, the difference is travel time and your server is fine. If it is 900 ms everywhere, the server is slow and no CDN will rescue it.
Fixes, in order of payoff
1. Page caching — usually the single biggest win
Most slow TTFB on a content-managed site is the application rebuilding an identical page for every visitor. WordPress, for example, will run database queries, execute plugin code and assemble the same HTML thousands of times a day.
A full-page cache stores the finished HTML and serves it directly. It routinely takes TTFB from 800 ms to under 100 ms, and it is usually a plugin install rather than an engineering project.
If you take one thing from this article and your site runs a CMS without full-page caching, this is it.
2. A CDN — fixes the distance component entirely
A CDN serves your pages from locations near your visitors rather than from one origin. For cached content, TTFB stops being a function of distance.
This is the correct fix when response times vary widely by region and are fine nearby. It is not a fix for a server that is uniformly slow — a CDN that has to ask a slow origin still waits for that origin.
3. Find the slow database queries
If the server is slow even for cached and simple responses, the application is doing too much work. In practice this is nearly always the database:
- A query with no index, scanning an entire table
- The N+1 pattern — one query, then one more for every row it returned
- A plugin querying an external API on every page load, so your page waits on someone else's server
Every stack has a query log or a profiler. Turn it on and look at the slowest queries; the answer is rarely a surprise once you can see it.
4. Check the TLS setup
TLS 1.3 completes the handshake in one round trip rather than two, saving a full round trip on every new connection — meaningful over long distances. HTTP/2 or HTTP/3 lets multiple requests share one connection instead of repeating the handshake.
Both are configuration rather than code, and most modern hosts have them on already. Worth confirming rather than assuming — the SSL Checker reports the negotiated protocol version.
5. Then, and only then, consider hosting
Better hosting helps when the server is genuinely underpowered: consistently slow across every region, slow even for static files, and slow after caching is in place.
It does not help when the real problem is an uncached CMS, an unindexed query, or a plugin calling an external API on every request. Moving that workload to a faster machine makes it slightly less slow while costing more — the inefficiency travels with you.
The Website Speed Test will suggest hosting only when the measurement supports it, and it says so on the page.
Things that will not help
Compressing images. They are downloaded after the first byte. Zero effect on TTFB.
Minifying CSS and JavaScript. Same reason.
Reducing the number of plugins, generically. What matters is what they do on each request. Ten dormant plugins cost almost nothing; one plugin calling an external API on every page load costs everything.
Upgrading to more RAM. Unless you are actually running out, this is not the constraint. Slow queries are slow regardless of available memory.
Measuring it properly
Two mistakes to avoid.
Do not measure only from your own machine. You are one location, probably close to your server, on a connection unlike your visitors'. curl gives a precise number for one vantage point:
curl -o /dev/null -s -w 'ttfb: %{time_starttransfer}s\n' https://example.com/
Do not measure a single request. The first request after a deploy or a cache clear is unrepresentative — caches are cold. Run several and look at the pattern, not one number.
Bear in mind too that your homepage is often the best-cached page on the site. A search results page or a filtered product listing frequently bypasses the cache entirely, and that is where real visitors experience the slow path. Test those as well.
Check your current server response time — and the Core Web Vitals sitting on top of it — with the Website Speed Test.