Time to First Byte (TTFB) is how long it takes from a request being sent to the very first byte of the response arriving — it measures your server and network, not your front-end. A good target is under 200 milliseconds; anything past 600 milliseconds is a real problem. TTFB matters because it is the floor for everything else: it directly delays Largest Contentful Paint, and slow-responding pages get abandoned by both users and the AI crawlers that fetch your content on demand. The fixes fall into four buckets: get physically closer to the user, do less work per request, cache aggressively, and speed up the backend that remains.
What TTFB includes and what "good" looks like
TTFB is the sum of several stages: DNS lookup, the TCP and TLS handshake, the request traveling to your server, the server generating the response, and the first byte traveling back. When people say "the site feels slow before anything even appears," they are usually describing high TTFB. As a rule of thumb, aim for under 200 ms, treat 200–500 ms as acceptable, and treat anything above 600 ms as something to fix. Because TTFB is upstream of rendering, shaving it improves your Core Web Vitals — especially LCP — without touching a single image or script.
One clarification that saves confusion: TTFB is a server-and-network metric, while most page-speed advice targets the browser. Both matter, but they have different fixes. This article is about the server side; for the front-end half, see our Performance Optimization Guide.
Get physically closer with a CDN and edge caching
Distance is latency. If your server sits in one country and your visitor is on another continent, every round trip pays that tax. A content delivery network puts copies of your content in data centers near users, so requests are answered from a nearby edge instead of your origin. For static assets this is straightforward; the bigger win is caching full HTML responses at the edge for pages that do not change per user, which can collapse TTFB from hundreds of milliseconds to tens. Pair the CDN with HTTP/2 or HTTP/3 and modern TLS so the handshake itself is cheap.
- Serve through a CDN with edge locations near your real audience.
- Cache full-page HTML at the edge wherever the page is not user-specific.
- Enable HTTP/3 and keep-alive connections to cut handshake overhead.
- Set sensible Cache-Control headers so caches can actually store responses.
Cache the expensive work instead of repeating it
Most high TTFB on dynamic sites comes from rebuilding the same page on every request — querying the database, rendering templates, calling APIs. Caching breaks that loop. Use full-page caching for pages that are identical across visitors, and object caching (Redis or Memcached) for the database queries and computed fragments that repeat. On a typical CMS, adding a page cache is often the single biggest TTFB improvement available, turning a 700 ms server render into a near-instant cache hit. The discipline is simple: identify what does not change per user, compute it once, and serve the stored copy until it needs refreshing.
Speed up the backend that is left
After caching, whatever still has to run should run fast. The usual culprits are slow database queries (add indexes, kill N+1 patterns), an underpowered or oversubscribed host, an outdated language runtime, and blocking third-party calls made during the request. Profile a slow page to see where the milliseconds actually go rather than guessing. Upgrading to a current PHP, Node, or Python runtime alone can meaningfully cut render time. Move any non-essential work — analytics pings, email sends, webhook calls — out of the request path and into a background job so the user's first byte is not waiting on it.
Keep an eye on TTFB for bots specifically, not just humans. AI fetchers like ChatGPT-User and Perplexity's crawler will abandon a slow response, and a page that times out never gets read or cited. If AI visibility is a goal, treat crawler-facing speed as a ranking factor in its own right — the context is in How to Optimize Your Website for ChatGPT, Gemini, and AI Search.
A fast path to a faster first byte
Measure your current TTFB from a few global locations, then work top-down: add full-page and object caching first, put a CDN in front with edge caching for static and cacheable HTML, then fix the slowest remaining queries and move blocking work off the request path. Most sites can get comfortably under 200 ms with caching and a CDN alone. To see your real TTFB, spot pages that respond slowly to crawlers, and get a prioritized fix list, run the CheckMy.site scanner.