What Is TTFB and Why Is It High?

TTFB stands for Time to First Byte.

In plain English, it measures how long it takes from the start of a page request until the first byte of the response starts to arrive.

That sounds small, but it matters a lot. If the first byte shows up late, everything behind it starts late too.

What TTFB actually includes

TTFB is not just "server thinking time."

It can include:

• redirects
• DNS lookup
• TCP connection setup
• TLS negotiation
• the request reaching the server
• the server doing enough work to begin sending a response

That is why a high TTFB does not automatically mean "the app is slow." Sometimes the delay is in routing, TLS, caching, or the edge layer before the origin server even gets involved.

What counts as a good TTFB?

As a rough rule, many sites should try to stay around 0.8 seconds or less for the 75th percentile experience. That is a useful guide, not a law of physics.

Some pages can tolerate a slightly higher TTFB if they still deliver good real user outcomes. Others, especially pages that depend heavily on client-side rendering, need that first response to arrive quickly or the whole experience feels sluggish.

Why TTFB gets high

1. Redirect chains

This is the easy one to miss.

If the request bounces from one hostname to another, then to HTTPS, then to a trailing-slash variant, you pay for each hop.

2. Slow DNS or connection setup

Sometimes the server is fine, but getting to it is not.

That can happen because of:

• slow DNS resolution
• long round-trip distance
• inefficient TLS handshakes
• overloaded or badly chosen edge paths

3. Cache misses

This one shows up all the time on dynamic sites.

The cached response may be fast, but the uncached request can still be painful if it has to go all the way back to the origin and rebuild the page from scratch.

4. Slow backend work

Classic causes:

• slow database queries
• too much server-side rendering work
• expensive API fan-out
• waiting on third-party services

5. CDN or reverse-proxy masking

A CDN can make the fast cases look great while the slow origin still exists underneath.

That is useful for users, but it can also hide the real bottleneck if you only test warm-cache paths.

A practical way to read TTFB

Do not treat it as a score in isolation.

Look at it alongside:

• redirect count
• cache headers
• CDN context
• HTML size
• Core Web Vitals or PageSpeed data

That is exactly why Website Performance shows TTFB next to delivery-path context instead of as a standalone number.

TTFB vs Core Web Vitals

TTFB is important, but it is not the whole performance story.

A page can have:

• decent TTFB
• terrible client-side rendering
• poor interaction responsiveness

Or the reverse:

• mediocre TTFB
• still acceptable user-perceived experience because the rest of the path is efficient

TTFB comes before the big user-facing metrics, but it does not replace them.

If you want the wider view, keep Core Web Vitals & Site Performance open beside your TTFB check.

What to do when TTFB is high

Start with the delivery path

Ask:

• are there redirects?
• is the page cached at the edge?
• is the response coming from a CDN or the origin?
• is the DNS or TLS setup adding overhead?

Then check origin behavior

Ask:

• is the backend rendering too much?
• are there slow database reads?
• are third-party APIs delaying response generation?
• is the first byte slow only on some routes?

Then check whether the number is globally consistent

This matters if you have users in different regions.

A page can have acceptable TTFB near the origin and much worse TTFB across the world. That usually points to geography, CDN placement, or cache hit rates rather than one broken line of app code.

Common TTFB mistakes

"We use a CDN, so TTFB cannot be the problem"

Not true.

A CDN helps, but cache misses, edge misconfiguration, or an overloaded origin can still push TTFB up.

"TTFB is bad, so the backend must be bad"

Also not always true.

DNS, TLS, routing, and redirect waste all show up before the first byte arrives.

"We fixed TTFB, so the page is fast"

Maybe. Maybe not.

If the browser still spends ages on JavaScript, layout work, or late-loading assets, users will still feel the page is slow.

A simple TTFB troubleshooting order

1. Check redirect count
2. Check DNS and connection overhead
3. Check cache headers and CDN behavior
4. Check origin response time
5. Compare with PageSpeed or field data

That order saves time because it rules out the cheap explanations before you dive into backend surgery.

The short version

TTFB is the time it takes to start getting the response back.

It can be high because of redirects, DNS, TLS, cache misses, CDN behavior, or backend work. Sometimes it is the app. Sometimes it is the path to the app.

That is why the right question is not just "is TTFB high?"

It is:

which part of the path is making it high?