How to reduce time to first byte

Time to First Byte is how long the browser waits between asking for your page and receiving the first byte of the response. Until that byte lands, nothing else can happen — no images, no CSS, no rendering. It is the one part of a slow page load that no amount of front-end optimization can recover.

What TTFB is actually made of

The single number hides four separate stages, and knowing which one is large is most of the diagnosis:

Redirects. Every redirect is a complete extra round trip before the real request even starts. A chain like http://example.com → https://example.com → https://www.example.com costs two of them, and on a mobile connection that is easily 400ms spent achieving nothing.

DNS lookup. Translating your hostname to an address. Usually tens of milliseconds, occasionally much worse with a slow or distant DNS provider.

Connection and TLS. Opening the TCP connection and negotiating HTTPS. Roughly two to three round trips, which is why physical distance between visitor and server matters so much.

Server processing. The time your application spends actually building the response. This is the one people assume is the problem, and it often is — but not always, which is why it is worth checking the others first.

Chrome DevTools shows the split. Open the Network panel, click the document request, and read the Timing tab: “Waiting for server response” is the processing portion, everything above it is overhead.

Fix the redirects first

This is first because it is the cheapest and the most commonly missed. Every URL should reach its final destination in at most one redirect. Two or more means something is misconfigured.

The usual cause is two separate rules that each do half the job — one forcing HTTPS, another forcing the www prefix — applied in sequence instead of combined. Rewrite them as a single rule that goes straight to the canonical form.

Then check your internal links. If your own navigation points at http:// URLs or the non-canonical hostname, every internal click pays the redirect too. Search your templates for hardcoded absolute URLs.

Cache, and mean it

The fastest server response is one that never reaches your application. Most pages on most sites are identical for every visitor, and serving them from a cache turns hundreds of milliseconds of processing into single digits.

Three layers, from cheapest to most involved. A CDN caches the response at an edge location near the visitor, which also removes the connection-latency cost of distance. Full-page caching on your own server stores the rendered HTML so the application does not run at all. Object or query caching stores the expensive parts — database results, API calls — for pages that genuinely must be dynamic.

The mistake to avoid is caching that never actually hits. A cache with a 60-second lifetime on a page nobody visits twice a minute is doing nothing; a cache invalidated by any cookie will miss for every logged-in visitor and every visitor with an analytics cookie, which is all of them. Check your hit rate before concluding caching is in place.

Then look at the application

If processing time is still the dominant portion, the causes are almost always one of these.

Unindexed or repeated database queries. The classic is a page that runs one query per item in a list — thirty products, thirty-one queries. Enable slow query logging and look at what the page actually issues.

Blocking third-party calls during rendering. Fetching a currency rate, a stock level or a social count synchronously while building the page means your response time now includes somebody else’s. Move these to the client, or cache them aggressively.

Cold starts. On serverless hosting, an idle function has to boot before it can respond. This shows up as a bimodal TTFB — mostly fast, occasionally terrible — which averages into something that looks moderately bad and is actually two different behaviors.

Shared hosting under load. If your TTFB varies wildly at different times of day with no change in your traffic, you are probably competing for resources with other sites on the same machine. No amount of code optimization fixes that.

Move the server closer

Physical distance is real and irreducible: light in fiber crosses the Atlantic in about 30ms one way, and TLS needs several round trips. A server in Frankfurt cannot deliver a 200ms TTFB to Sydney no matter how fast the application is.

If your audience is concentrated in one region, host there. If it is spread, a CDN with edge caching is the practical answer for static responses — and for genuinely dynamic pages, edge rendering, which runs your code at the edge location rather than just caching output.

How much does this matter for SEO?

Directly, TTFB is not a ranking factor and not a Core Web Vital. Indirectly it matters twice over.

First, it is a floor on LCP, which is a Core Web Vital. An 800ms TTFB means LCP cannot be under 800ms, so a target of 2.5s has already lost a third of its budget before the browser has done anything.

Second, response time affects crawling. Google adapts crawl rate to how fast a server responds, so a slow site gets crawled more slowly, which means new and updated pages are discovered later. On a large site that becomes a real constraint — see crawl budget and faceted navigation. And if responses are slow enough to time out, they become genuine crawl errors, which is the territory of DNS and server connectivity errors.

Measure it properly

A single test from your own machine is the least useful measurement available: your DNS is cached, your connection may be to the same continent, and you may be hitting a warm cache your visitors miss. Test from several locations, and test a page nobody has requested recently.

For real numbers, field data is again the authority. The Chrome UX Report includes TTFB, so you can see the distribution across your actual visitors rather than one sample of one.

Our free site check reports the server response time it measured alongside the rest of the load, which tells you quickly whether this page is the one you need or whether your problem is further down the waterfall. If TTFB is fine and the page still feels slow, diagnosing slow page speed covers the front-end phases.