TTFB Optimization: How to Reduce Time to First Byte
What TTFB Measures and Why It Matters
Time to First Byte (TTFB) measures the duration from when a browser makes an HTTP request to when it receives the first byte of the server's response. It captures the combined latency of: redirect time (if any redirects occur before reaching the final URL), service worker startup time (if a service worker intercepts the request), and server response time (the actual time your server takes to process the request and begin sending the response).
Google's threshold for a "good" TTFB is under 800ms. Between 800ms and 1800ms is "needs improvement." Above 1800ms is "poor." TTFB directly affects Largest Contentful Paint (LCP) — your LCP element cannot start loading until after the HTML document begins arriving. A slow TTFB pushes every subsequent metric later and is one of the most impactful fixes you can make for Core Web Vitals.
How to Measure TTFB
There are several accurate ways to measure TTFB:
PageSpeed Insights: Run your URL at pagespeed.web.dev. In the "Diagnose performance issues" section, look for "Time to First Byte" under the Diagnostics section. PSI shows both lab data (Lighthouse) and real-world field data (CrUX). Field TTFB across real users over 28 days is the most meaningful number.
Chrome DevTools Network Tab: Open DevTools (F12), go to Network, reload the page, click the first HTML document request, then look at the "Timing" tab. The "Waiting (TTFB)" row shows the server response time. This is the raw server response time without redirect time.
WebPageTest: webpagetest.org gives you detailed waterfall charts with TTFB clearly marked. It also lets you test from different geographic locations, which reveals CDN issues — your TTFB may be excellent in the US but terrible in Europe if you don't have a CDN.
Server-Side Causes of Slow TTFB
The most common causes of high TTFB are server-side problems: slow database queries that run on every page request, no full-page caching (so every request regenerates the page from scratch), shared hosting with insufficient resources, and slow origin server locations far from your users.
Slow database queries: Use query profiling tools (MySQL slow query log, Datadog APM, New Relic) to identify queries taking more than 100ms. Add database indexes on columns used in WHERE clauses, use query caching, and avoid N+1 query patterns in your application code.
No page caching: If your CMS or application regenerates HTML on every request, even simple pages can take 500ms+ to generate. Full-page caching serves pre-generated HTML directly from memory — reducing TTFB from 500ms to under 50ms. This is the single highest-impact TTFB optimization for most websites.
CDN and Connection-Level Improvements
A CDN (Content Delivery Network) reduces TTFB for global users by serving cached responses from edge servers physically close to the user. Without a CDN, a user in Tokyo accessing a server in London will have a minimum 150ms TTFB just from the speed of light (round-trip latency) — before any server processing. A CDN with an edge node in Tokyo can serve that same request in under 20ms.
Connection-level improvements that reduce TTFB: enable HTTP/2 or HTTP/3 on your server (eliminates connection overhead on subsequent requests), enable TLS session resumption (reduces TLS handshake time for returning visitors), and use keep-alive connections to avoid TCP handshake overhead on every request. Most modern web servers (Nginx, Apache 2.4+) support all of these — they just need to be configured correctly.
WordPress-Specific TTFB Fixes
WordPress is particularly prone to high TTFB because every page request hits PHP and MySQL by default. The fix stack, in order of impact:
Full-page caching: WP Rocket, W3 Total Cache, or LiteSpeed Cache (if on LiteSpeed server). WP Rocket is the easiest to configure correctly. LiteSpeed Cache is the best-performing if your host runs LiteSpeed.
Object caching (Redis or Memcached): Caches database query results in memory. Add Redis to your server and configure WordPress to use it via the Redis Object Cache plugin. This dramatically reduces database load and improves TTFB even for uncached page variants (e.g., logged-in users who bypass full-page cache).
PHP opcode caching: OPcache (built into PHP 7+) caches compiled PHP bytecode. Verify it's enabled with php -m | grep OPcache. If not enabled, add opcache.enable=1 to your php.ini.
Hosting upgrade: Shared hosting on an overloaded server will always have poor TTFB regardless of caching. If your uncached TTFB is over 3 seconds, your hosting is the problem. Move to a managed WordPress host (Kinsta, WP Engine, Cloudways) or a VPS with proper configuration.
Next.js and Vercel TTFB Considerations
Next.js on Vercel has excellent TTFB for statically generated pages (ISR and SSG routes serve from Vercel's CDN edge with sub-50ms TTFB globally). Server-side rendered (SSR) pages on the Node.js runtime can have 200-500ms TTFB depending on data fetching. Switching SSR routes to Vercel's Edge Runtime reduces cold start time and often halves TTFB — but Edge Runtime doesn't support all Node.js APIs, so verify compatibility.
Cold starts are a key issue for serverless Next.js deployments. The first request after a period of inactivity pays a cold start penalty of 200-800ms. Subsequent requests are fast. For production sites with consistent traffic, cold starts are rarely an issue. For low-traffic pages, use ISR with a reasonable revalidation period instead of pure SSR to serve from CDN.