What Is TTFB (Time to First Byte)? What It Includes and How to Reduce It

Short answer: Time to First Byte is the time between the browser starting to request a page and receiving the first byte of the response. It includes redirects, DNS lookup, connection setup, and the server's processing time. A common guideline is 0.8 seconds or less at the 75th percentile. TTFB is not a Core Web Vital, but it sets a floor under every other loading metric: nothing can render before the HTML begins to arrive.

Table of Contents

1. What TTFB Includes
2. Thresholds
3. Why It Varies So Much
4. Common Causes
5. Reducing It
6. Key Takeaways

What TTFB Includes

So TTFB is not only "server speed". A fast server far from the visitor, or behind two redirects, still has a slow TTFB.

Thresholds

These are guidelines. What matters in the end is LCP, and a page can have a mediocre TTFB and a good LCP if the rest is efficient. A poor TTFB, though, makes a good LCP nearly impossible (LCP).

Why It Varies So Much

• Distance. A visitor in Mumbai reaching a server in Virginia pays for the round trips. With several needed to connect, distance adds up.
• Network. Mobile networks add latency.
• Cache state. A cached page returns in milliseconds. An uncached one runs the full backend.
• Logged-in pages. Personalised pages often cannot be cached.
• Load. A busy server is slower.
• Cold starts. Serverless functions that have been idle take longer on the first request.

This is why a single test from your own location tells you little. Your visitors' TTFB is a distribution.

Common Causes

1. No caching of HTML for pages that could be cached.
2. Slow database queries on every page view.
3. Server far from the audience with no CDN.
4. Redirect chains. http to https to www to a trailing slash is three round trips before the page starts (a redirect problem we met ourselves).
5. Heavy plugins or middleware running on every request.
6. Calls to slow third-party APIs while rendering the page.
7. Underpowered hosting.
8. Server-side rendering that waits for all data before sending anything.

Reducing It

For content sites and landing pages, static generation plus a CDN solves most of it. For applications, focus on the database and on what is done before the first byte is sent.

Measuring From Real Users

Check your slowest pages and regions, not the average.

1. By page. Templates differ. A product listing with complex queries may be far slower than the homepage.
2. By country or state. Poor TTFB concentrated in one region points to distance or CDN coverage. DeepSync shows visitors by country, and on Pro by state and city, which helps match a slow region to its audience size (demography).
3. By device and network.
4. Over time. A sudden rise after a release points to a new query or a cache that stopped working.

DeepSync's performance report includes TTFB with the other real-user timings, by page.

Then look at what visitors do during the wait. In recordings of slow loads, people tap the link again, go back, or leave before the page appears. A slow TTFB is especially costly on the first page of a visit from an ad, where the visitor has no commitment yet (paid traffic).

Key Takeaways

• TTFB covers redirects, connection, and server processing.
• It varies by region, cache state, and page.
• Caching, a CDN, and fewer redirects are the main fixes.
• Measure the distribution from real visitors.

Conclusion

Everything on a page waits for the first byte. If that is slow, no amount of front-end tuning will make the page feel fast.

Start free with DeepSync.