What is TTFB and why it matters

You've probably seen it in a Lighthouse report or a performance dashboard. TTFB. Time to First Byte. It's usually a number in milliseconds, sometimes green, sometimes red, and it's easy to gloss over it in favor of metrics that feel more tangible, like Largest Contentful Paint or Total Blocking Time.

But TTFB is the one number I look at first when something feels slow. It tells you how long the browser waited before it got anything back from the server. Not the full page. Not the images. Just the first byte of the response.

If TTFB is slow, everything else is slow too. The browser can't start rendering until it gets that first byte. It can't parse HTML, fetch CSS, or load scripts. It's just sitting there, waiting.

What's actually happening during TTFB

TTFB isn't one thing. It's the sum of several things happening in sequence, and knowing what those things are is the key to figuring out what's slow.

Here's the breakdown:

DNS lookup     →  find the server's IP address
TCP connection →  establish a connection to the server
TLS handshake  →  negotiate encryption (HTTPS)
Server processing → the server receives the request, does its work, starts sending the response

The time from the browser sending the request to receiving the first byte of the response is your TTFB. If any of these steps is slow, TTFB suffers.

What good and bad values look like

Google considers a TTFB under 800ms to be acceptable, and under 200ms to be good. But those are pretty generous numbers. For a well-configured site behind a CDN, you should be seeing TTFB under 100ms for cached content.

Some rough benchmarks:

• Under 100ms: Excellent. Probably cached at a CDN edge.
• 100-300ms: Good. Server is responding quickly, maybe a bit of distance involved.
• 300-800ms: Okay, but worth investigating. Something is slower than it should be.
• Over 800ms: Slow. Your users are noticing.

Keep in mind that TTFB varies by location. A server in Europe will have great TTFB for European users and mediocre TTFB for users in Asia. That's physics, not a bug. This is why measuring from a single location doesn't tell the whole story.

Figuring out what's slow

This is where it gets useful. A high TTFB number by itself doesn't tell you much. You need to see the breakdown to know where the time is going.

Slow DNS lookup (>50ms): Your DNS provider is slow, or you're not using a provider with global anycast. Consider switching to Cloudflare DNS, Bunny DNS, or similar. DNS should be nearly instant.

Slow TCP connection (>100ms): The server is physically far from the user, or there's network congestion. A CDN fixes this by putting servers closer to users.

Slow TLS handshake (>100ms): TLS 1.2 requires two round trips to negotiate. TLS 1.3 does it in one. Make sure your server supports TLS 1.3. Also check if your certificate chain is unnecessarily long.

Slow server processing (everything else): This is the big one. If DNS, TCP, and TLS are all fast but TTFB is still slow, the server itself is the bottleneck. Slow database queries, missing caches, heavy computation, cold starts on serverless platforms. This is where you need to look at your application, not your infrastructure.

The request waterfall

The most useful way to debug TTFB is a request waterfall. It shows you each phase of the connection visually, with timing for each step. Instead of just seeing "TTFB: 450ms", you see that DNS took 5ms, TCP took 15ms, TLS took 30ms, and server processing took 400ms. Now you know exactly where to look.

You can see this in your browser's DevTools (Network tab, click a request, look at the Timing section). But that only shows you the connection from your machine.

If you want to see how your site looks from different locations around the world, we built a free response time checker that runs checks from multiple global locations and shows the full waterfall from each one. No signup needed.

A few things that actually help

If you're looking to improve TTFB, here's what I'd focus on, in order of impact:

1. Put a CDN in front of your site. This is the single biggest improvement for most sites. Cached responses from edge servers have near-zero server processing time.

2. Cache aggressively. Set proper Cache-Control headers. If a page doesn't change often, there's no reason for the server to regenerate it on every request.

3. Check your server-side performance. Slow database queries are the most common culprit. Add indexes, reduce query count, cache expensive computations.

4. Use TLS 1.3. One fewer round trip on every new connection.

5. Use a fast DNS provider. This matters less than the others, but it's also the easiest to fix.

TTFB isn't glamorous, but it's the foundation everything else sits on. If you want to keep an eye on it over time, Larm tracks the full request waterfall on every check, from multiple locations, so you can spot regressions before your users do.