TTFB: The Hidden Tax on Your Rankings

Every millisecond before the first byte arrives is a tax paid by every page load and every crawl. It's deducted before a single pixel renders, before the browser knows what to preload, before Googlebot can move on to the next URL in its queue. Most performance work focuses on what happens after the server responds — images, JavaScript, layout shifts. TTFB is what happens before.

That makes it unusually high leverage. A slow server response is a floor that all your other optimizations sit on. You can't paint a page before the first byte arrives.

What TTFB actually measures

Time to First Byte (TTFB) is the time elapsed from the moment a client initiates an HTTP request to the moment it receives the first byte of the server's response.

That window contains four distinct phases:

DNS resolution — translating the hostname to an IP address. Usually fast for repeat visitors whose OS caches the result, but a meaningful cost on the first visit or after TTL expiry.

TCP connection — the three-way handshake that establishes the connection. One round-trip of latency at minimum.

TLS handshake — for HTTPS (which is everything in 2026), an additional negotiation to establish an encrypted session. TLS 1.3 is a single round-trip (1-RTT) for new connections — down from two round-trips with TLS 1.2 — and zero round-trips (0-RTT) for resumed sessions, making it a meaningful improvement over its predecessor.

Server processing time — the time from when the server receives the complete request to when it starts sending back bytes. This is the component you have the most control over: it includes application execution, database queries, cache lookups, template rendering, and any upstream API calls your server makes before it can respond.

TTFB is the sum of all four. The first three are dominated by network physics — geographic distance and round-trip latency. Server processing time is where software choices matter.

One important clarification: TTFB is not a Core Web Vital. It does not appear in the Lighthouse CWV section. But it directly feeds into LCP (Largest Contentful Paint), which is a Core Web Vital. You cannot have a fast LCP on a page with a slow TTFB — the browser is waiting for the first byte before it can even begin to understand what the largest contentful element will be. Improving TTFB is frequently the most direct path to improving LCP. The relationship is covered more thoroughly in the guide to Core Web Vitals.

You can measure TTFB for any URL without a browser using curl:

# Measure TTFB for a URL with curl:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com/

time_starttransfer is curl's name for the time-to-first-byte, measured from the start of the transfer. Run it a few times to account for variance, and test from geographically relevant locations — a server that's fast in your city may be slow for users on the other side of the country.

Why it matters twice

TTFB matters for two distinct reasons, and many SEO practitioners only think about one of them.

Reason one: it's the floor under LCP. LCP measures how quickly the main visible content becomes available. The browser can't fetch subresources, parse CSS, or begin rendering until it has received the first bytes of the HTML response. A 600ms TTFB means LCP cannot be faster than 600ms, regardless of how aggressively you optimize images or preload critical resources. If you're struggling to push LCP below 2.5 seconds and your TTFB is 800ms, the math is working against you — the LCP clock starts before the server even responds.

Reason two: slow responses limit how much Google crawls. Google's crawl rate adapts to server health. A server that consistently responds quickly earns more crawl capacity — Googlebot will attempt more URLs per day. A server that responds slowly or intermittently causes Googlebot to back off to avoid overloading it. For large sites, this is the difference between important pages getting recrawled in hours versus days. The relationship between server response time and crawl capacity is documented in Google's crawl budget guidance, and it's one reason TTFB shows up in the technical SEO checklist alongside indexing and architecture concerns.

The two effects compound. A slow TTFB makes each page slower to load for users, hurts LCP scores, and simultaneously reduces how many pages Googlebot can process per day. Fix TTFB and you improve user experience and crawl efficiency in a single move.

Good vs bad numbers

Google's web.dev guidance sets the "Good" threshold at under 800ms for the full time-to-first-byte including DNS, TCP, and TLS — that's the bar you need to clear to be in the passing range. But many practitioners aim for a tighter target: total TTFB under around 600ms, with server processing time as the key variable to isolate.

Server processing time — the component you control directly — should be well under 200ms for a typical page. Under 100ms is achievable for cached or statically generated responses. If your server takes more than 200ms to begin responding after it receives a complete request, that's where to look first.

Total TTFB (including DNS, TCP, and TLS) under around 600ms is a tighter target many practitioners aim for. For users geographically close to your server, total TTFB well under 600ms is realistic. For users on the other side of the world, the physics of round-trip latency are harder to compress — which is why CDNs matter.

Be measured with these numbers. A global site will have a distribution of TTFB values across geographies. The goal is to pull the median and the 75th percentile into the acceptable range for the users who matter most, not to hit a single number on a synthetic test.

Seven causes of slow TTFB

1. Slow hosting or an underprovisioned server

The most direct cause: the server physically can't process requests quickly enough. Overloaded shared hosting, a single underpowered instance handling more traffic than it was sized for, or a server with insufficient memory that's spending time in swap — all produce high server processing time. This is the foundation. Everything else is optimizing on top of it.

2. No CDN or poor CDN coverage

Without a CDN, every request travels to your origin server regardless of where the user is. A user in Sydney fetching content from a server in Virginia pays the full round-trip latency across the Pacific — potentially 300-400ms in connection overhead alone, before the server has processed anything. Geographic distance is pure physics; the only remedy is to put content closer to users.

3. No caching — pages regenerated per request

If every request causes the server to execute application code, query the database, and render a template before sending a response, server processing time is bounded by how fast all of that can run. Caching the rendered HTML at the server or CDN layer means subsequent requests get a prebuilt response, cutting server processing time to near zero. Pages that don't change per user (most marketing pages, blog posts, product listings) are strong candidates for full-page caching.

4. Slow database queries

Application code typically waits for a database before it can render a response. A query that scans a full table, lacks an appropriate index, or runs inside a loop that issues dozens of individual queries can dominate server processing time. Query analysis — examining execution plans and query durations in slow-query logs — is often where the biggest wins are for dynamic applications.

5. TLS and connection overhead

TLS 1.3 significantly reduced handshake latency compared to TLS 1.2, but if your server is still negotiating 1.2 sessions, you're paying extra round-trips on each new connection. Enabling TLS 1.3 and session resumption (which lets returning clients skip part of the handshake) reduces connection overhead without changing your application code. OCSP stapling is another server-level win: it bundles the certificate's validity proof into the TLS handshake, avoiding a separate round-trip to the certificate authority.

6. A redirect before the real response

If a user navigates to http:// and gets redirected to https://, or hits the non-www version and gets redirected to www, they pay a full TTFB for the redirect response — then another full TTFB for the actual page. Each redirect in the chain is a separate round-trip. A single protocol or hostname redirect before a page loads can easily add 200-400ms. Internal links and canonical tags should point at the final URL so the redirect is never triggered in the first place. The mechanics of redirect chains are covered in detail in the 301 redirect audit guide — but from a TTFB perspective, the simple rule is: every redirect adds a full extra TTFB before the real page starts loading.

7. Serverless cold starts

Container-style serverless functions (AWS Lambda, Google Cloud Run) can have excellent steady-state latency, but a "cold start" — the first request to a function that hasn't run recently — incurs initialization overhead as the runtime spins up. On infrequently accessed routes this can add hundreds of milliseconds to TTFB. V8-isolate edge runtimes like Cloudflare Workers largely avoid cold starts because they share a persistent JavaScript engine process rather than spinning up containers; their initialization overhead is measured in microseconds, not hundreds of milliseconds.

Fix each cause

Slow hosting: Upgrade to a dedicated instance or right-size your infrastructure. Profile request handling time with server-side monitoring — if your application processes a request in 30ms but TTFB is 500ms, look at infrastructure; if application time itself is 400ms, optimize the application.

No CDN: Add a CDN. For most sites Cloudflare, Fastly, or a Vercel/Netlify edge network is straightforward to configure. Prioritize regions where your users actually are. CDNs also handle TLS termination closer to the user, compressing the TLS handshake cost.

No caching: Identify your highest-traffic pages that return the same HTML for every user (or every user in a given state). Add full-page caching at the CDN layer with appropriate cache-control headers. Even a 60-second cache lifetime can eliminate most regeneration overhead under realistic traffic patterns.

Slow database queries: Enable slow query logging with a threshold of 50-100ms. Review the top offenders — most slow query issues are resolved by adding appropriate indexes, rewriting N+1 queries, or moving non-essential lookups out of the critical rendering path.

TLS overhead: Verify TLS 1.3 is enabled on your server. Configure session resumption and OCSP stapling — OCSP stapling bundles the certificate's validity proof into the TLS handshake, avoiding a separate round-trip to the certificate authority. These are server configuration changes, not application changes, and take effect immediately.

Redirect before the real page: Update internal links and paid/social campaign URLs to point directly at the canonical final URL. Set up a redirect map and audit it periodically. If protocol and www redirects are triggered by inbound links you don't control, they're unavoidable — but eliminating them from your own internal links removes the overhead for internal navigation and crawls.

Serverless cold starts: Profile your function routes to identify which ones are cold-start-sensitive. Moving to a V8-isolate edge runtime (like Cloudflare Workers) largely eliminates cold starts — these runtimes share a persistent engine process rather than spinning up containers. For Lambda/Cloud Run functions that can't be migrated, provisioned concurrency keeps instances warm and eliminates initialization overhead. Caching responses at the CDN layer is a complementary hedge: cold starts only affect the first request after a cache miss.

Measure across templates

One common mistake is measuring TTFB on the homepage and assuming the rest of the site is similar. In practice, page types often have very different server processing times — a homepage served from a CDN cache may have a 40ms TTFB while a dynamically generated category page with complex filtering logic takes 600ms.

A slow template affects every URL built from it. An e-commerce site with 50,000 product pages on a template with 400ms server processing time has a systemic TTFB problem that won't show up if you only measure the homepage.

This is where a site-wide crawl becomes essential. CrawlX records the response time for every URL in the crawl, which means you can see TTFB distribution across your full page inventory — not just the pages you happen to test manually. Sorting by response time quickly surfaces which templates are running slow, which paths are triggering expensive redirects, and where server processing is dominating total time. A pattern of slow response times on URLs matching /category/* or /search/* is immediately visible and actionable in a way that spot-checking individual URLs never reveals.

Fix the slow templates and the benefit compounds across every page built from them.