Most performance guides jump straight to image compression and JavaScript minification. Those matter — but they're fixing the wrong end of the waterfall. Before any asset can be optimised, the browser has to wait for the server to respond. A page with a 2,000ms TTFB is unfixable at the frontend; you're working against a 2-second deficit that no amount of lazy-loading can overcome.
Google's Core Web Vitals scoring reflects this. A poor TTFB makes a good LCP score mathematically impossible on most pages. If you're stuck in the "needs improvement" band for LCP despite optimising images and fonts, TTFB is likely the ceiling.
Key Takeaways
- Google's threshold for good TTFB is under 800ms; 800ms–1800ms needs improvement; over 1800ms is poor — this directly affects LCP scores
- TTFB measures only the server's response time — it doesn't include network latency between the user and server (DNS + TCP + TLS come before TTFB in the waterfall)
- The biggest TTFB causes: slow database queries, no server-side caching, expensive server-side rendering, and geographic distance from the server
- A CDN reduces geographic latency and can serve cached responses with sub-100ms TTFB for most users
- Measuring TTFB in field data (real users via CrUX) matters more than lab data — your server's response time from a test machine near the server may look fine while real users in distant regions see 2s+ TTFB
What TTFB Measures
TTFB starts when the browser sends the HTTP request and ends when it receives the first byte of the response. It includes:
- Time for the request to travel to the server (network latency)
- Time for the server to process the request and generate the response
- Time for the first byte of the response to travel back to the browser
Network latency is determined by physical distance and routing — it's constant for a given user-server pair and outside your direct control. Server processing time is controllable. The main lever is reducing what happens on the server between receiving the request and sending the first byte back.
It's worth distinguishing TTFB from the other segments you see in a network waterfall. DNS lookup, TCP handshake, and TLS negotiation all happen before the HTTP request is even sent. TTFB is purely the server's processing time plus the round-trip for that first byte. When you see a long "Waiting (TTFB)" row in Chrome DevTools — that's server time. When you see a long "Initial connection" row — that's network and TLS overhead, a different problem.
TTFB Thresholds and Scoring
Google's Core Web Vitals thresholds for TTFB:
| Rating | TTFB | Effect on LCP |
|---|---|---|
| Good | Under 800ms | LCP can still achieve "good" (<2.5s) with typical page weight |
| Needs improvement | 800ms–1800ms | LCP "good" is difficult — browser hasn't started rendering until ~1s in |
| Poor | Over 1800ms | LCP "good" is effectively impossible — 1.8s TTFB + render time always exceeds 2.5s |
TTFB isn't a Core Web Vitals metric itself (LCP, CLS, and INP are), but slow TTFB makes LCP worse. A page with 1,500ms TTFB cannot achieve a good LCP score — the browser can't even start rendering until after 1.5 seconds. Every millisecond of TTFB reduction directly reduces LCP by the same amount.
Common Causes of Slow TTFB
Slow database queries
The most common cause for dynamic sites. Every page request triggers database queries; if those queries scan unindexed columns or return large result sets, TTFB grows proportionally. A query that takes 800ms on the database adds 800ms to every page load. Fix: add indexes on columns used in WHERE clauses, optimise queries with EXPLAIN ANALYZE, and cache frequent query results in memory rather than re-executing on each request.
No server-side caching
A server that re-renders every page from scratch on every request is slow by design. Server-side caching stores the rendered HTML output and serves it directly on repeat requests, bypassing all database and rendering time. A cached response can be sent in under 5ms; an uncached one may take 300ms–2,000ms depending on page complexity. Fix: add Redis or Memcached caching for frequently requested pages; set appropriate TTLs based on how often content changes.
Expensive server-side rendering
Pages that aggregate data from multiple sources, call external APIs synchronously, or perform heavy computation on each request take longer to generate. If a product page fetches inventory from one API, pricing from another, and review counts from a third — all in series — each external call adds its own latency to your TTFB. Fix: pre-render where possible; use background jobs to prepare aggregated data; parallelise external API calls rather than running them in sequence.
Geographic distance
A server hosted in the US adds 200ms or more of pure network latency for users in Southeast Asia, before any processing begins. This latency is physics — light and electrons travel at finite speed. A CDN with edge nodes globally eliminates most of this by serving requests from a node close to the user. Fix: deploy a CDN in front of your origin server; for high-traffic sites with dynamic content, consider multi-region hosting with a globally distributed database.
Shared hosting resource limits
On overloaded shared hosting, response times can spike unpredictably as neighbouring tenants consume CPU and memory. Your application may respond in 200ms when lightly loaded and 3,000ms during a peak on another tenant's site. This makes TTFB highly variable and hard to diagnose — it looks like an intermittent problem. Fix: move to a VPS or managed hosting tier with dedicated CPU and memory allocation.
Measuring TTFB
Page Speed Inspector
The Page Speed Inspector reports TTFB as a lab measurement from the server running the inspection. It shows DNS, TCP, TLS, TTFB, and download as separate timing segments in the waterfall, so you can see exactly how much time each phase takes. This is useful for baseline measurement and debugging — you can distinguish a long TLS negotiation from a long server processing time, which require different fixes.
Google Search Console Core Web Vitals report
Google Search Console shows real user TTFB from the Chrome User Experience Report (CrUX). This is field data — it reflects what real visitors across diverse geographies and network conditions actually experience. Lab TTFB and field TTFB often differ significantly. A test from a machine in the same data centre as your server will see 50ms TTFB; real users in distant regions may see 2,000ms. Field data is what Google uses for ranking signals, so it's the number that matters.
Chrome DevTools Network tab
Shows TTFB in the Timing panel for any request. Click any request in the Network tab, then open the Timing section — the "Waiting (TTFB)" row shows the server processing time excluding network latency. This is useful for comparing TTFB between pages on the same site, or between authenticated and unauthenticated requests, to isolate what's causing the delay.
Fixes That Make the Biggest Difference
Ordered by typical impact:
1. Add a CDN. Moves responses geographically closer to users and caches HTML at edge nodes. For edge-cached pages, perceived TTFB drops from 1,500ms to under 150ms for most users. This is the single highest-leverage change for sites with a global audience. CDNs like Cloudflare, Fastly, and CloudFront all support HTML caching with configurable TTLs.
2. Cache rendered HTML on the server. Serving pre-rendered HTML from a cache eliminates all database query time and all rendering time. Even a 60-second cache TTL dramatically reduces TTFB for high-traffic pages. Most frameworks support output caching; the pattern is the same across PHP, Node.js, Python, and Ruby.
3. Optimise database queries. Add indexes on columns used in WHERE and JOIN clauses. Use your database's query planner (EXPLAIN ANALYZE in PostgreSQL, EXPLAIN in MySQL) to find full table scans. Convert N+1 query patterns to single joined queries. These changes can reduce TTFB by hundreds of milliseconds without changing application architecture.
4. Enable HTTP/2. HTTP/2 multiplexes requests over a single connection, reducing connection overhead for pages with many sub-resources. It also enables server push for critical assets. Most CDNs enable HTTP/2 by default; check your origin server configuration if you're not behind a CDN.
5. Move to a faster hosting tier. Shared hosting with CPU limits is a hard ceiling on TTFB. When database and caching optimisations are in place but TTFB is still variable and slow, the hosting environment itself is the constraint. Dedicated CPU resources remove unpredictable spikes caused by neighbouring tenants.
TTFB and Ranking — What Google Actually Uses
Google does not use TTFB directly as a ranking factor — it uses Core Web Vitals (LCP, CLS, INP). But TTFB is a prerequisite for good LCP. A page with a 1,500ms TTFB will always have LCP above 2.5s unless the LCP element is already in the browser cache, which is rare for first visits.
The practical consequence: if your Google Search Console shows LCP in the "needs improvement" or "poor" band, and you've already optimised images and render-blocking resources, check your TTFB. It's often the unchecked constraint. Fixing a 1,800ms TTFB to 400ms can move LCP from "poor" to "good" without any other change.
For sites with personalised content (dashboards, logged-in experiences), TTFB from dynamic rendering is often the only variable — caching isn't applicable. In those cases, database optimisation, connection pooling, and moving to faster infrastructure are the relevant levers.
Measure Your Server's TTFB
Free, no signup. The Page Speed Inspector measures TTFB, DNS, TCP, and TLS timing separately — showing exactly where your server response time is going and what's causing the delay.
Try the Page Speed Inspector Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.