What is TTFB? SEO Guide for Beginners

Time to First Byte (TTFB) is a performance metric that measures the time between the browser starting to navigate to a page and the moment the first byte of the response begins to arrive. It reflects how quickly your server processes a request and starts delivering content. According to web.dev, a TTFB of 0.8 seconds (800 milliseconds) or less is "good", a value between 0.8 and 1.8 seconds "needs improvement", and anything greater than 1.8 seconds is "poor". Most sites should aim to land in the good band, and truly fast static sites routinely come in well under 200ms.

Why TTFB Matters for SEO

TTFB is the foundation of every other performance metric. Your LCP cannot be fast if your server takes 2 seconds just to start sending data. Your INP suffers if the page takes forever to initially load because JavaScript execution is delayed. Every millisecond of TTFB pushes back the entire loading timeline.

TTFB is not itself a Core Web Vital. web.dev is explicit that because TTFB is not a Core Web Vitals metric, it is not strictly necessary to meet the good threshold, provided your slower TTFB does not stop you scoring well on the metrics that do count. The reason it still matters is that TTFB precedes the user-centric metrics: web.dev recommends your server respond to navigation requests quickly enough that the 75th percentile of users experience a First Contentful Paint within the good FCP threshold. TTFB also affects crawl efficiency. When Googlebot consistently encounters slow responses, it can reduce its crawl rate to avoid overloading your server, which means fewer pages crawled per session and slower discovery of new content.

I have measured the difference firsthand. When I moved my blog from a server-rendered framework to static HTML served from a CDN, TTFB dropped from 400ms to under 50ms. That single change improved my LCP by nearly a full second and pushed several pages from "needs improvement" to "good" in Core Web Vitals.

How TTFB Works

TTFB is the sum of several sequential network phases, not just server processing. Per web.dev, it encompasses redirect time, service worker startup time (where a service worker is in play), the DNS lookup that translates your domain name to an IP address, connection setup and TLS negotiation, and the request phase up to the point the first response byte arrives. The server processing piece (running database queries, executing server-side code, generating HTML) sits inside that final request phase and is often the largest single contributor on dynamic sites.

For static sites, the server processing phase is almost zero because the HTML is pre-built and just needs to be read from disk or cache. For dynamic sites running WordPress, Django, or Rails, the server has to execute code, query databases, and assemble the HTML on every request, which can add hundreds of milliseconds or more.

Geographic distance also plays a major role. If your server is in New York and a user is in Tokyo, the physical distance adds latency to every phase of the connection. This is where CDNs become critical, placing cached copies of your content on servers around the world.

How to Improve TTFB on Your Site

1. Use a CDN - A Content Delivery Network like Cloudflare, Fastly, or AWS CloudFront caches your content on edge servers worldwide. Users connect to the nearest edge server instead of your origin, dramatically reducing TTFB for visitors outside your server's region.

2. Enable server-side caching - For dynamic sites, cache rendered HTML output using Varnish, Redis, or your framework's built-in caching. A cached response can be served in single-digit milliseconds instead of hundreds.

Common Mistakes to Avoid

• Testing TTFB only from your own location: Your TTFB might be 50ms when you are near the server, but 800ms for users across the globe. Use tools like WebPageTest or KeyCDN Performance Test that let you test from multiple locations worldwide.

• Ignoring TTFB for API calls: If your page makes client-side API calls during rendering, those requests have their own TTFB. A fast HTML response does not help if your JavaScript then waits 2 seconds for API data before rendering content.

• Adding too many WordPress plugins: Each PHP plugin adds processing time to every request. Sites with 30+ active plugins routinely see TTFB above 1 second. Audit and remove plugins you do not actively use, and consider replacing heavy plugins with lighter alternatives.

In Practice

You can read the real TTFB a browser experienced straight from the Navigation Timing API. MDN defines responseStart as the timestamp immediately after the browser receives the first byte of the response, and TTFB is the gap between that and fetchStart. Drop this into the console on any page to see your own number:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const ttfb = entry.responseStart - entry.fetchStart;
    console.log(`TTFB: ${Math.round(ttfb)}ms`);
  }
}).observe({ type: 'navigation', buffered: true });

To make that number smaller on the server side, the most direct win is edge caching. web.dev recommends configuring Cache-Control so a CDN can serve a cached copy from the edge instead of round-tripping to your origin on every request. A response that tells the CDN it may serve cached HTML for one hour while keeping it for visitors mid-revalidation looks like this:

Cache-Control: public, max-age=0, s-maxage=3600, stale-while-revalidate=86400

With that header, the origin renders the page once, the CDN holds it for an hour at the edge (s-maxage=3600), and every subsequent visitor in that window gets a first byte in single-digit milliseconds instead of waiting on your origin server. That is the difference between a 400ms TTFB and a sub-50ms one without changing a line of application code.

Related Terms

• What is Largest Contentful Paint (LCP)? - the Core Web Vital that TTFB directly feeds into.
• What is Interaction to Next Paint (INP)? - the responsiveness Core Web Vital that a slow initial load can delay.
• What are Core Web Vitals? - the umbrella metrics TTFB is diagnostic for.
• What is a CDN? - the single most effective lever for cutting TTFB across regions.
• What is Crawl Budget? - how server response speed influences how much Googlebot crawls.

Key Takeaways

• TTFB measures how quickly your server starts responding. web.dev classes 0.8 seconds or less as good, 0.8 to 1.8 seconds as needs improvement, and over 1.8 seconds as poor.
• TTFB is a diagnostic metric, not a Core Web Vital itself, but it precedes and constrains FCP and LCP.
• Use a CDN to serve content from edge locations close to your users and reduce geographic latency.
• Server-side caching and static site generation are the most effective ways to achieve consistently low TTFB.
• Test from multiple geographic locations to understand the real experience for your global audience.

Sources

• Time to First Byte (TTFB), web.dev (checked 2026-05-30)
• Optimize Time to First Byte, web.dev (checked 2026-05-30)
• PerformanceResourceTiming: responseStart property, MDN (checked 2026-05-30)