TTFB is the foundation everything else builds on

Time to First Byte (TTFB) measures how long it takes for the browser to receive the first byte of response after sending the request. It includes DNS lookup, TCP and TLS handshake, redirects, and server processing time. Until TTFB completes, the browser cannot do anything: no rendering, no parsing, no script execution.

High TTFB cascades into every other performance metric. Slow TTFB pushes LCP later, FCP later, TTI later. Cutting 500ms off TTFB often improves Core Web Vitals more than any other single optimization.

What good TTFB looks like

Google's recommended targets: under 800ms TTFB for "good", up to 1800ms for "needs improvement", anything above is "poor". For sites serving global audiences, hitting under 600ms requires edge caching. Origin-only sites, even with fast servers, struggle to beat 800ms for users far from the data center.

TTFB is geographic. A US-hosted server delivering 200ms TTFB to US visitors might deliver 1200ms to Australia. Always test from multiple geographies if your audience is global. This checker runs five samples; for full coverage use a real-user monitoring tool.

The biggest causes of slow TTFB

Database queries on every request. Dashboard pages that hit the DB for every component bottleneck TTFB. Cache aggressively at the application layer (Redis, in-memory caches) and the CDN layer (full-page HTML caching for non-personalized pages).

Slow third-party APIs called server-side during render. If your page server-side fetches inventory data, weather, or analytics at request time, you inherit those APIs' latency in your TTFB. Cache aggressively or move the fetch to client-side.

Server-side rendering (SSR) with heavy computation. SSR is great for SEO but every dynamic component adds work to the request path. Static site generation (SSG) or incremental static regeneration (ISR) eliminates this entirely for content that does not change per user.

Origin distance. Without a CDN, every user hits your origin directly. Adding Cloudflare, Fastly, Cloudflare Pages, Vercel Edge, or similar puts content within a few hundred milliseconds of every user globally.

How to measure TTFB correctly

Single-sample TTFB readings are noisy. Network jitter alone can swing one fetch by 200ms. Take 5 to 10 samples and report the average and the variance. This tool runs 5 samples per click.

TTFB measured from your office is different from TTFB measured from real users. Use Real User Monitoring (RUM) tools like SpeedCurve, Calibre, or even free Cloudflare Analytics to see real-user TTFB across the world. The number Google grades you on is the field-data TTFB from CrUX, not your local test.

TTFB and SEO ranking

TTFB is part of Google's page experience signals as a component of LCP. It is not directly graded as its own metric in Search Console, but slow TTFB blocks LCP from being good, which is a ranking signal.

AI crawlers (GPTBot, ClaudeBot, PerplexityBot) have shorter timeouts than Googlebot. Pages with TTFB above 3 seconds risk partial parsing or being skipped entirely by AI crawlers. AI Overview citations correlate strongly with sub-1-second TTFB because the AI summarizers can fetch and parse the full page in their request budget.

Fixing TTFB systematically

Add a CDN if you do not have one. Cloudflare's free tier alone cuts TTFB by 50% or more for most sites. Cache static and HTML responses at the edge.

Audit slow database queries. Most CMSs have a query log plugin. Find queries over 200ms and optimize: add indexes, denormalize where appropriate, or cache results.

Move heavy server-side work to async or client-side. If a component fetches data not needed for initial render, defer it. If it fetches data that varies by user, render the static shell server-side and hydrate the dynamic parts client-side.