TTFB & Server Response Time
What it does
The Server Timing tool is part of the SEO Suite. It measures Time-To-First-Byte (TTFB) for a URL across a configurable number of samples and reports the median, minimum, maximum, and average. The median is the headline number: single requests are too noisy to be useful, but the median across five or ten samples is a stable signal you can compare against benchmarks.
Common situations
A page is slow but you’re not sure whether the slowness is server-side or in the browser rendering. TTFB isolates the server portion. If TTFB is 800ms and total page load is 3 seconds, server response is the dominant cost; if TTFB is 100ms and total is 3 seconds, the browser-side rendering is the issue.
You have just enabled a CDN and want to verify cached responses are actually being served. Run TTFB checks; cached responses should be 50-150ms. If they’re 400ms+, the CDN isn’t caching, or every request is missing the cache.
A WordPress site has been migrated to a faster host and you want to measure the improvement. Run TTFB before and after; the change in median TTFB is the headline number. Marketing claims about “10x faster” usually refer to TTFB-style metrics.
You are debugging why Core Web Vitals scores are low. LCP (Largest Contentful Paint) includes server response time as one component. If TTFB is over 600ms, LCP is structurally limited, and bringing TTFB down is the first lever.
A specific page is slower than the rest of the site. Run TTFB on the slow page and a fast page; if both are similar, server-side is fine and the slow page has page-level issues (heavy plugins, complex queries, large response). If the slow page TTFB is much higher, it’s a per-page server issue.
What you need to know
TTFB measures the time from sending a request to receiving the first byte of the response. It includes DNS lookup, TCP connection, TLS handshake, request processing on the server, and the start of the response stream. It does NOT include the time to download the full response, render the HTML, execute JavaScript, or anything client-side.
Google’s published threshold for “good” TTFB is under 200ms. Above 600ms is “needs improvement”; above 1000ms is “poor” and structurally limits Core Web Vitals scores. Most production sites land between 200ms and 600ms.
Why median, not average:
A single TTFB measurement is too noisy to be useful. Background processes on your machine, network jitter, server load, cold caches all introduce variance. Five samples typically span a 2-3x range; the median is what’s representative. The arithmetic mean is sensitive to outliers; the median isn’t.
What contributes to TTFB:
DNS lookup (10-50ms typically): time to resolve hostname to IP. Repeat requests use cached DNS.
TCP connect (10-100ms typically): three-way handshake. HTTP/2 connection reuse means subsequent requests skip this.
TLS handshake (50-200ms typically): for HTTPS. HTTP/2 + TLS 1.3 minimises this.
Server processing (variable): the actual cost of generating the response. For static files served by nginx, single-digit milliseconds. For dynamic pages with database queries, 100-500ms is common; for unoptimised CMS pages, can be 2-5 seconds.
Time to first byte (1-50ms typically): the start of the response stream.
Most TTFB cost is in server processing. The fix is usually one of: better caching (CDN edge cache, application page cache, database query cache), simpler queries (fewer database hits per page), or faster hosting (more capable origin).
The tool reports the headline TTFB but also flags the specific contributors when the server returns Server-Timing headers, a standardised mechanism for servers to report their own timing breakdown. Most CMSes don’t use Server-Timing yet; modern hosting platforms (Cloudflare, Vercel, Netlify) often do.
Frequently asked questions
What’s a good TTFB?
Under 200ms is good per Google. 200-600ms is acceptable. Over 600ms structurally limits Core Web Vitals. Sites running on serverless or static-site platforms typically hit 100-150ms; sites on shared hosting with heavy dynamic generation often sit at 500-1500ms.
Why is TTFB so different across samples?
Network jitter, DNS caching state, server warm/cold state, and concurrent traffic all introduce variance. Single samples are unreliable; five-sample median is the working number.
Does TTFB include rendering time?
No. TTFB is server-side only. It measures the time from the request starting to the first byte of the response arriving. Rendering, JavaScript execution, and resource loading happen after TTFB.
Will the tool give the same TTFB Google measures?
Approximately, but not exactly. Google measures TTFB from real users (Real User Metrics, or RUM data) across all geographic locations, while this tool measures from a single server in our infrastructure. Use it to track relative change; for absolute comparisons, use Search Console’s Core Web Vitals report which uses real user data.
Why is the first sample always slower?
Cold caches. The first request has no cached DNS, no warm TLS session, possibly no warm origin connection. Subsequent requests reuse those. The median across five samples discards the cold start.
What does Server-Timing show?
A standardised header where the server reports its own timing breakdown: database time, render time, cache hit/miss, etc. Modern frameworks (Next.js, Vercel) often emit it; older CMSes typically don’t.
Does TTFB affect SEO directly?
Indirectly. TTFB feeds into LCP (Largest Contentful Paint), one of the Core Web Vitals. Sites with poor LCP rank worse on mobile-first searches. So TTFB → LCP → Core Web Vitals → ranking.
Will hosting on a CDN definitely lower TTFB?
For cached responses, yes. CDNs typically serve from edge locations within 100ms of the user. For uncached or per-user dynamic responses, the CDN doesn’t help and may add a small overhead. The win comes from cache hit rate, not from CDN presence alone.
Common problems
Problem: TTFB is high but only on the homepage.
Common when the homepage runs more dynamic queries than other pages: featured products, latest posts, personalisation. Most CMSes have a homepage cache; if the cache is missing or short-lived, every visit pays the full query cost. Cache the homepage aggressively.
Problem: TTFB has improved on test runs but Search Console still reports it as poor.
Search Console uses real-user data over a 28-day window. Improvements take weeks to show up there. Run the tool to confirm improvement; trust Search Console for the long-term real-world measurement.
Problem: TTFB is consistent in the tool but users report slowness.
The tool measures server response from our infrastructure. Users on slower networks (mobile, distant geographies) experience higher TTFB. The bottleneck for those users is network, not server. Look at the HTTP Headers Inspector for cache headers; caching closer to the user (edge CDN) is the fix.
Problem: Median TTFB is good but max is 5x worse.
Outliers usually mean cold-start states (database connection from cold pool, asset cache miss, plugin initialisation). Track down whichever cold path is producing the spike. Usually it’s warming up via scheduled requests or persistent processes.
Problem: TTFB on staging is fine but production is slow.
Staging environments usually have less traffic and less data. Production runs with real concurrency and real data volumes. The fix isn’t on the staging side; it’s diagnosing what changes between low-load test conditions and real-load production.
Tips
- Take five samples minimum. Single samples are too noisy for any meaningful conclusion.
- Compare same-page TTFB before and after changes, not absolute numbers across different pages or different sites.
- TTFB is the easiest Core Web Vitals lever. If LCP is poor, TTFB is usually the first thing to improve.
- CDN caching is the highest-ROI optimisation. Most other improvements are second-order.
- Don’t optimise TTFB at the cost of correctness. A 50ms TTFB that returns stale data is worse than a 300ms TTFB that returns fresh data.
Related tools in this suite
The HTTP Headers Inspector is useful for verifying cache headers (Cache-Control, X-Cache, CF-Cache-Status) that affect TTFB. The Page SEO Audit reports TTFB as part of its overall page report.
What this looks like at scale
For a single page, the tool is fine. For a site, TTFB should be tracked over time across representative URLs (homepage, category page, product page, blog post) to spot regressions. The WP Beacon Plugin tracks TTFB and other performance metrics across an entire site over time.
Take it further
If a site has chronic TTFB issues, the fix is rarely a single tweak. It’s an architecture review covering hosting, caching, and database query patterns. Talk through the architecture and we can scope what improvement looks like.