TTFB measures the elapsed time from when the browser sends the HTTP request to when it receives the first byte of the response. It includes DNS lookup, TCP connection, TLS handshake, and server processing time. Google considers TTFB under 800ms "good" — but for landing pages, you should aim for under 200ms. Every millisecond of TTFB delay pushes back FCP, LCP, and every other metric that follows.
Think of TTFB as the starting line for your page load. If your server takes 1.5 seconds to respond, your LCP literally cannot be better than 1.5 seconds — and in practice will be significantly worse because the browser still needs to download, parse, and render after receiving that first byte.
What causes slow TTFB
The common culprits: slow database queries (dynamic pages that hit the database on every request), unoptimized server-side code, shared hosting with resource contention, no server-side caching, and geographic distance between server and visitor. For a WordPress landing page, the difference between no caching and a proper page cache can be TTFB of 2 seconds vs. 50ms.
The fastest path to good TTFB: serve static HTML from a CDN edge node. If your landing page doesn't need per-request server computation, pre-render it at deploy time and serve it as a static file. TTFB drops to 20-50ms globally. If you need dynamic content (personalization, A/B testing), use edge functions that run at CDN nodes rather than a central server — Cloudflare Workers, Vercel Edge Functions, or similar.