What Is Server Response Time? TTFB Numbers That Matter

Jul 27, 2026 · SEO Glossary

Here's a one-liner worth keeping in your shell history:

curl -o /dev/null -s -w "dns %{time_namelookup}s | connect %{time_connect}s | tls %{time_appconnect}s | ttfb %{time_starttransfer}s\n" https://example.com/

Run it against your homepage. The last number — time to first byte — is your server response time as a real client experiences it. If it reads 0.9 seconds, your visitors stare at a blank tab for nearly a second before your beautiful frontend gets a single byte to work with, and no amount of frontend optimization claws that time back.

What is server response time, formally? The elapsed time between a client's request and the arrival of the first byte of the response — DNS lookup, TCP connection, TLS negotiation, then the part you control most: your server actually generating and starting to send the answer.

Benchmarks: What's Good, What's a Problem

The reason to care is arithmetic: TTFB is the floor under everything. Largest Contentful Paint has a 2.5-second "good" threshold, and LCP can't begin until the HTML arrives — a 1.2-second TTFB spends half the budget before the browser renders a pixel. Google's own guidance suggests most sites need TTFB under roughly 800ms to have a realistic shot at good LCP, and comfortable passes usually sit far below that.

The Crawling Angle Everyone Forgets

Googlebot meters itself against your server's responsiveness. Google's documentation on crawl capacity is explicit: if the site responds quickly, the crawl rate limit goes up; if it slows or throws 5xx errors, Googlebot backs off. You can watch this in Search Console's Crawl Stats report — average response time and total crawl requests move in opposite directions. On a large site, cutting average response from 800ms to 200ms reliably shows up as more pages crawled per day, which means faster discovery and fresher indexing. Server speed is crawl budget, expressed in milliseconds.

What Is Server Response Time Made Of?

When TTFB is bad, the milliseconds hide in a predictable set of places:

• Application work. The big one for CMS sites: every request rebuilds the page — dozens of database queries, template rendering, plugin hooks. A WordPress page with a heavy theme and 30 plugins routinely spends 500–1,500ms here.
• Database queries. One missing index or an N+1 query pattern turns a 5ms lookup into a 400ms stall. Slow-query logs find these fast.
• Distance. Every 1,000km of physical distance adds latency, and TLS setup costs multiple round trips. A user (or crawler) far from your origin pays it on every uncached request.
• Cold starts and shared hosting. Serverless functions and cheap shared hosts add wake-up time under low or bursty traffic.
• Redirects before content. Each hop in a redirect chain is a full extra round trip that users experience as TTFB even though your server logs look innocent.

Fixes, in Order of Typical Payoff

1. Full-page caching. The single biggest lever for CMS sites: serve rendered HTML from cache and skip the application entirely. TTFB drops from 800ms+ to 50–150ms for cache hits. Most pages on most sites can be cached with sensible invalidation.
2. A CDN in front of the origin — cuts the distance term for every visitor and absorbs static asset traffic. With edge-cached HTML, global TTFB under 100ms is achievable.
3. Fix the slow queries. Profile before optimizing; one indexed column often beats a hardware upgrade.
4. Right-size hosting. If TTFB degrades under mild concurrency, the fix is capacity, not code.
5. Keep-alive, HTTP/2+, TLS 1.3 — protocol hygiene that shaves connection overhead on every request.

One subtlety after you add caching: your average TTFB becomes a blend of two populations — cache hits at 80ms and cache misses at 900ms — and the average hides the split. Track your cache hit ratio alongside TTFB, and check which pages systematically miss. Common culprits: URLs with query parameters that bust the cache key, pages with session cookies that mark them uncacheable, and long-tail pages evicted before the next visitor arrives. Googlebot's crawl pattern is long-tail by nature, so it hits your cache misses far more often than your median user does.

Measuring It Honestly

Three habits keep the data trustworthy. Measure from where users are, not from your desk to a server ten miles away — the curl one-liner via a few remote locations, or CrUX field data (PageSpeed Insights reports field TTFB), gives the real picture. Measure repeatedly, not once: TTFB has variance, and the 75th percentile matters more than your best run. And measure many URLs, not just the homepage — homepages are usually cached while deeper templates aren't, which is exactly the kind of pattern a whole-site audit exposes when it flags slow-responding pages across the whole URL inventory. A homepage at 150ms with product pages at 1,100ms is a common finding, and it's invisible if you only ever test one URL. Overall page speed work starts here, at byte one — everything else in the waterfall queues behind it.