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.

What the breakdown actually tells you

A useful TTFB reading is more than one number, because TTFB is the sum of several phases stacked back to back. DNS resolution finds your server's address. The TCP connection opens the socket. The TLS handshake negotiates encryption. Then the request travels to the server, the server does its work, and the first byte travels back. When TTFB is high, the fix depends entirely on which phase is fat, and they have nothing to do with each other.

If DNS is slow, the problem is your DNS provider or an uncached lookup, not your application code. If the TLS handshake is slow, you may be missing session resumption or running an old protocol version. If connection setup is fine but the wait for the first byte is long, the bottleneck is server processing: database queries, slow templates, or upstream APIs. Reading the phases stops you from optimizing the wrong thing, which is the single most common way TTFB work gets wasted.

Watch for redirects hiding inside your TTFB. If the URL you test quietly issues a 301 to another URL, the browser pays for two full round trips before any content arrives, and a naive measurement blames your server for latency that is really a redirect tax. Always test the final destination URL, and fix redirect chains separately rather than letting them inflate every reading.

Common mistakes when chasing TTFB

The first mistake is testing a warm cache and celebrating. The second request to a page is served from cache and returns in a fraction of the time of the first, uncached request. Real users and crawlers frequently hit cold paths, so test cache-busting URLs or clear the cache between samples if you want the number that actually matters.

The second mistake is reading a single sample as truth. Network jitter, a momentary garbage-collection pause on the server, or a cold serverless function can swing one fetch by hundreds of milliseconds. This tool takes multiple samples on purpose so you can see the spread. A low average with high variance is its own red flag: it usually means cold starts or an overloaded origin that is fast most of the time and terrible occasionally.

The third mistake is treating TTFB as the whole story. A blazing 200ms TTFB does not save a page that then ships three megabytes of render-blocking JavaScript. TTFB is the foundation, but a fast foundation under a heavy house still gives a slow page. Use this checker to confirm the server is not the problem, then move to the Page Speed Test and Core Web Vitals Checker for what happens after the first byte.

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.

How TTFB differs across page types

Not every page on your site should be held to the same TTFB. A fully static marketing page served from the edge can and should return its first byte in under 200ms. A logged-in dashboard that assembles personalized data on every request will always be slower, because there is genuine work to do and little of it can be cached publicly. Knowing which category a URL falls into tells you whether a given TTFB is acceptable or alarming.

This matters for SEO because the pages search engines and AI crawlers care about, your articles, product pages, and landing pages, are almost always cacheable. There is rarely a good reason for a public blog post to have a 1.5-second TTFB. If it does, the page is probably being rendered fresh from a database on every request when it could be served as a pre-built static or incrementally regenerated response. The content does not change per visitor, so the server work is pure waste.

Test the templates that earn organic traffic, not just the homepage. Homepages are usually the most heavily optimized and cached page on the entire site, so a fast homepage TTFB tells you almost nothing about the article and category pages that actually rank. Sample several URLs of each template type to find the slow path before Google does.

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 so the request never has to travel back to a distant origin for content that has not changed.

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. A single missing index on a hot query is one of the most common reasons an otherwise healthy server posts a poor TTFB under real traffic.

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. The goal is to get the first byte of meaningful HTML out the door quickly, then fill in the personalized pieces after.

Finally, watch for cold starts if you run on serverless. A function that has not been invoked recently has to spin up before it can respond, and that startup cost lands squarely in TTFB for the unlucky first visitor. If your variance is high while the average looks fine, cold starts are the likely culprit, and keeping functions warm or moving the route to a always-on edge runtime is the cure.

Once you have made a change, verify it the way you measured the problem: same URL, same number of samples, ideally from the same location. TTFB improvements are easy to imagine and hard to confirm without a clean before-and-after, because the number is so noisy. Record the median and the spread before the fix, ship the change, then re-test and compare. If the median dropped and the variance tightened, the fix is real. If only one lucky sample looks better, you are seeing noise, not progress. Treating TTFB work as a measured experiment rather than a hopeful tweak is the difference between a server that is genuinely faster and one that merely felt faster the moment you happened to look.