What is TTFB, and why does it matter?

Time to first byte is the delay between a browser asking for a page and the first byte of the response arriving. Everything else about page speed happens after it.

It is the most useful single number for diagnosing a slow site, because it isolates the server from everything the browser does afterwards.

What TTFB is made of

Four things happen before that first byte:

1. DNS lookup — resolving your domain to an IP
2. Connection — TCP handshake, plus TLS negotiation for HTTPS
3. Server processing — the interesting part: PHP runs, database is queried, HTML is assembled
4. First byte travels back — network latency between the server and the visitor

Server processing is usually the variable you control. The others are mostly a function of geography and configuration.

What counts as good

Rather than quote a single threshold as gospel, the useful way to read TTFB is comparative:

• Under ~200ms — the server is not your problem, look at the front end
• 200–600ms — normal for uncached dynamic pages; worth improving, rarely urgent
• Over ~600ms — something is wrong: caching is not working, the server is contended, or the application is doing too much work
• Over 1.5s — visitors notice this as a stall before anything appears

Measure it yourself with the speed test rather than trusting a number from a marketing page.

The most valuable test: cached vs uncached

Load your homepage twice — once normally, and once with a random query string appended, such as ?cachebust=12345. The second request bypasses most page caches.

• Both fast — genuinely good hosting and caching
• Cached fast, uncached slow — caching is masking a slow application; fine until something invalidates the cache
• Both slow — the server or the network is the issue, and caching will not save you
• Cached slow — caching is not actually working, or the server is slow at serving a static file, which is a hosting problem

That single comparison tells you more than most performance reports.

What makes TTFB bad

Distance. A UK visitor hitting a US server pays 80–100ms in round trips before anything else happens. For a UK audience, UK or Western European hosting is worth real money — see our UK hosting picks.

Shared hosting contention. Your neighbours are using the CPU. This is why TTFB gets worse at busy times of day and is often the clearest evidence you have outgrown a budget plan.

Unoptimised application work. A WordPress theme running dozens of uncached database queries to build a menu. A plugin calling an external API before rendering.

No object caching. WordPress repeats expensive queries on every request unless Redis or Memcached is available. Many budget hosts do not offer it.

TLS negotiation. Usually minor, but an incorrectly configured certificate chain adds a round trip. Check yours with the SSL checker.

How to improve it

In rough order of effort against reward:

1. Enable page caching so most requests never touch PHP
2. Add object caching (Redis) if your host offers it
3. Host closer to your audience — the single biggest win for a UK site on a US server
4. Put a CDN in front so static assets and, ideally, cached HTML are served from an edge near the visitor
5. Profile the application — find the slow query or the plugin making an external call
6. Upgrade the plan if you are genuinely resource-constrained

Note that a CDN alone does not fix TTFB for dynamic HTML unless it caches HTML at the edge. It fixes asset delivery, which is a different problem.

Where TTFB sits in Core Web Vitals

TTFB is not itself a Core Web Vital, but it is a component of LCP (largest contentful paint), which is. Every millisecond of TTFB is a millisecond LCP cannot avoid — you cannot render the main content before the HTML arrives.

So improving TTFB improves LCP directly, and LCP is the vital most sites fail. That makes it a high-leverage number to work on.

If your TTFB is fine and LCP is still poor, the problem is what happens after the HTML arrives — usually an oversized hero image. That is covered in why is my WordPress site slow.