Time to First Byte (TTFB)

TTFB sits at the very beginning of the browser's page load sequence. Every millisecond you add to TTFB delays First Contentful Paint, Largest Contentful Paint, and every other user-experience metric. Google considers TTFB a foundational element of page experience — not a Core Web Vital itself, but the upstream bottleneck that determines whether you can pass the ones that are.

What is TTFB?

When a user or a search bot navigates to a URL, the browser follows this sequence:

1. DNS lookup — resolves the domain name to an IP address.
2. TCP connection — establishes a connection to the server.
3. TLS handshake — negotiates encryption for HTTPS (adds latency on first request).
4. HTTP request sent — browser asks for the resource.
5. Server processing — server receives the request, processes it, and begins sending a response.
6. First byte received — the browser receives the opening bytes of the server's response.

TTFB measures the total elapsed time across steps 1-6. In Chrome DevTools, you can see this broken into sub-components: "Queued", "Stalled", "DNS Lookup", "Initial connection", "SSL", and "Waiting (TTFB)".

The "Waiting" figure in DevTools is the pure server response time — excluding DNS and connection setup. Google's Core Web Vitals documentation uses a broader definition that includes DNS + connection + server response in the TTFB total.

Why TTFB matters for SEO

TTFB is not a direct ranking signal, but it determines whether your other performance metrics can succeed. The relationship is causal:

• TTFB delays FCP and LCP. Nothing can paint on screen until the server has started responding. A 2-second TTFB means your LCP cannot occur before 2 seconds — making a passing LCP score (under 2.5 seconds) essentially impossible unless your LCP element loads instantly from cache.
• Googlebot speed matters. Google crawls millions of pages daily. Slow server responses reduce how many of your pages Googlebot can crawl per day — a crawl budget problem for large sites.
• User experience and bounce rate. Every 100ms of additional TTFB increases bounce rate. Google uses real user metrics from Chrome (the Chrome User Experience Report / CrUX) as field data for Core Web Vitals scoring. High bounce from slow TTFB indirectly influences the signals Google measures.

What causes a slow TTFB?

TTFB is a composite metric — multiple independent factors can inflate it. Diagnosing which factor is responsible is the first step to fixing it.

1. Slow server-side processing

If your CMS, application server, or API backend takes time to compute a response — running database queries, calling third-party APIs, executing rendering logic — that processing time adds directly to TTFB. WordPress sites doing full-page rendering on every request without caching are the most common offender.

2. Insufficient server resources

An underpowered server (too little RAM, slow CPU, single-threaded app server) that is handling concurrent traffic will queue requests and inflate TTFB. Shared hosting with resource contention is a frequent cause.

3. No caching layer

A dynamically generated page that executes database queries on every request will always be slower than a cached static HTML file. Full-page caching (at the server, CDN, or application layer) eliminates the processing time component for repeat requests entirely.

4. Geographic distance (network latency)

If your server is in Frankfurt and your user is in Singapore, raw network latency alone adds 150-200ms before the server even receives the request. Without a CDN, every user far from your origin server experiences this penalty.

5. DNS resolution delays

Slow DNS response times add to the TTFB total on first connection. Using a fast DNS provider (Cloudflare 1.1.1.1, Google 8.8.8.8) and configuring appropriate DNS TTLs reduces this component.

How to reduce TTFB

Ranked by impact for most sites:

CDN edge caching (highest impact)

A CDN stores a cached copy of your HTML at dozens of edge nodes around the world. When a user requests your page, the CDN serves it from the nearest node rather than routing the request to your origin server. The network round-trip drops from hundreds of milliseconds to single-digit milliseconds. For static or semi-static pages, this is the single highest-impact TTFB optimisation available.

Full-page caching for dynamic sites

For WordPress and similar dynamic CMS platforms: install a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache) that generates static HTML files for pages and serves them directly without executing PHP or querying the database. This transforms a 500-1,500ms dynamic TTFB into a 50-200ms cached response.

How to measure TTFB

Multiple tools measure TTFB — using at least two gives a clearer picture:

• Chrome DevTools: Open DevTools (F12) > Network tab > reload the page > click the HTML document request > look at "Waiting (TTFB)" in the Timing tab. This is lab data measured from your location.
• PageSpeed Insights: Shows TTFB in the "Server response times are low" diagnostic — both lab and field data if CrUX data exists for the URL.
• WebPageTest.org: The most detailed tool. Shows TTFB for every request, broken into all sub-components, from multiple global test locations. Use this to verify that CDN caching is working.
• Google Search Console: The Core Web Vitals report shows field LCP data. If LCP is poor across many pages, TTFB is often the upstream cause.
• Real User Monitoring (RUM): Tools like Cloudflare Web Analytics, Sentry, or SpeedCurve capture actual user TTFB from real sessions — the most accurate representation of what users experience.

TTFB optimisation best practices

1. Fix TTFB before optimising other performance metrics. There is no point compressing images or deferring JavaScript if the server takes 3 seconds to respond. TTFB is always the first bottleneck to address.
2. Use a CDN with cache-control headers that permit HTML caching. Many developers set Cache-Control: no-store on HTML responses to avoid stale content, accidentally disabling CDN caching. Use stale-while-revalidate instead for the best balance of freshness and speed.
3. Test TTFB from multiple geographic locations. WebPageTest lets you run from the US, Europe, and Asia simultaneously. A fast TTFB in your home country can mask a terrible experience in other markets.
4. Monitor TTFB after every infrastructure change. Server upgrades, plugin installations, or code deployments can inadvertently degrade TTFB. Continuous monitoring via a synthetic monitoring tool catches regressions before they affect rankings.
5. Pre-warm your cache after deployments. When you deploy new code or flush your cache, TTFB spikes until the cache is repopulated. Run a crawl or warming script against your most critical URLs immediately after cache clears.

Common TTFB mistakes

• Measuring TTFB only from your local machine. Your office or home is likely close to your server, giving you a false best-case reading. Always test from representative geographic locations.
• Caching HTML with too-long TTLs. A 24-hour CDN cache TTL means content updates take 24 hours to propagate. Use cache invalidation on deployment rather than relying on TTL expiry for content freshness.
• Ignoring TTFB on API endpoints. For single-page applications, TTFB on API calls matters as much as TTFB on the HTML document. A fast HTML TTFB with slow API responses still produces a poor user experience.
• Conflating TTFB with full page load time. TTFB measures only when the first byte arrives, not when the page is fully rendered. Improving TTFB will improve all downstream metrics, but TTFB alone does not guarantee a fast user experience.

Frequently asked questions

Related glossary terms

Sources

Akshay VR

Marketing Head · theStacc · ex-Sr Marketing Specialist, ARKA 360 · Malappuram, Kerala

Akshay leads editorial and content operations at theStacc. He writes about technical SEO, site performance, and the infrastructure decisions that quietly determine whether a site grows or stagnates — including the TTFB fixes that unlock Core Web Vitals improvements.

LinkedIn Author page More terms by Akshay