Time to First Byte (TTFB) measures how long it takes from a visitor requesting a page to the first byte of the server’s response arriving in their browser. Google considers TTFB under 800 milliseconds good. Slow TTFB usually points to slow hosting, missing CDN, expensive backend logic, or unoptimized database queries — and it cascades into worse Largest Contentful Paint and overall page speed.
What TTFB Is and Why It Matters
Most page speed conversations start with what the visitor sees on screen. Time to First Byte is upstream of that. Before the browser can render anything, it has to receive bytes. TTFB measures the latency between sending a request and getting that first byte back.
The metric covers everything between client and server: DNS lookup, TCP handshake, TLS negotiation, server processing, and the start of the response. A slow TTFB means the server (or the network getting to it) is the bottleneck. No amount of front-end optimization fixes a 2-second TTFB.
Google does not use TTFB as a Core Web Vital, but TTFB is a strong predictor of LCP. If your server takes 1.2 seconds to respond, you have already burned half of LCP’s 2.5-second target before the browser starts downloading any content. The full Core Web Vitals guide covers how the front-end and back-end metrics interact.
What Counts as Good TTFB
Google’s recommendation is under 800ms at the 75th percentile of real users. Inside that headline number, there is a useful breakdown. Under 200ms is excellent — the territory of CDN-cached static pages. 200ms to 500ms is good — typical for well-built dynamic sites. 500ms to 800ms is acceptable but indicates room to improve. Over 800ms means the server, the network, or both are the limiting factor.
The 75th-percentile rule means you have to optimize for the slowest real users, not the average. A site that hits 300ms on a fast laptop in San Francisco might hit 1.2 seconds on a phone in Indonesia. The Indonesian visitor is the one defining your TTFB grade.
Common Causes of Slow TTFB
Slow Hosting
Cheap shared hosting is the single most common cause of bad TTFB. If your $4-per-month plan shares a server with 200 other sites, the CPU contention shows up as response delays. Mid-tier WordPress hosting (Cloudways, Kinsta, WP Engine) typically delivers 200-400ms TTFB on cached pages. Premium platforms like Vercel, Netlify, and Framer’s built-in hosting usually land under 200ms.
No CDN
Without a content delivery network, every visitor reaches your origin server directly. A visitor in Tokyo hitting a server in Virginia incurs hundreds of milliseconds of unavoidable network latency. A CDN caches responses at edge locations close to the visitor and serves them locally. Cloudflare, Fastly, Bunny, and the CDNs built into modern hosting platforms all reduce TTFB dramatically for static and cacheable content.
Heavy Backend Processing
If every page request runs database queries, calls external APIs, processes images on the fly, or executes complex logic, TTFB suffers. The fix is caching at multiple layers: object caching for query results, page caching for full HTML, edge caching for static assets. The website speed optimization guide covers caching architecture in detail.
Slow Database Queries
WordPress sites with bloated plugin databases, ecommerce sites with unoptimized product queries, and applications with missing indexes all spend disproportionate time waiting on the database. Slow queries are often the largest single contributor to back-end TTFB. Use the slow query log, profilers, and tools like Query Monitor for WordPress to find the offenders.
Bad Database Indexing
A query that should hit an index and return in 5ms instead does a full table scan and takes 800ms. Indexes are not free — they cost write performance and storage — but for read-heavy sites, missing indexes are usually responsible for the worst-performing queries.
Synchronous External API Calls
If your homepage waits for a third-party API to return before sending bytes, the third party defines your TTFB. Calls to analytics endpoints, social proof widgets, recommendation engines, and search APIs should always be deferred to the client side or cached aggressively on the server. The website security best practices guide covers some of the third-party integration patterns that often slow down server response.
SSL/TLS Overhead
HTTPS adds round trips for the TLS handshake. Modern protocols (TLS 1.3, HTTP/2, HTTP/3) reduce the cost significantly, but legacy server configurations still pay the price. Make sure your server supports HTTP/2 at a minimum and ideally HTTP/3 for the best handshake performance.
How to Measure TTFB
PageSpeed Insights
The fastest TTFB check. Paste a URL at pagespeed.web.dev. The “Server response time (TTFB)” line in the diagnostics shows the measured value with a green, yellow, or red rating. Lab data only — for field data you need Search Console.
WebPageTest
WebPageTest at webpagetest.org provides the most detailed TTFB breakdown. The waterfall view shows DNS lookup, connect, SSL handshake, and time to first byte as separate slices. This is the most useful tool for diagnosing whether the slow part is network or server.
Chrome DevTools Network Tab
Open DevTools, switch to the Network tab, reload the page, and click the main HTML document. The “Timing” sub-tab shows DNS lookup, initial connection, SSL, request sent, waiting (TTFB), and content download. The “waiting” portion is what TTFB measures.
Real User Monitoring
Lab tools measure synthetic loads from one place at one moment. Real users span every device, network, and region. Tools like SpeedCurve, Calibre, and the Performance API combined with your analytics platform let you collect TTFB from real visits and slice by region, device, or page.
How to Fix TTFB
Upgrade Hosting
The most expensive fix and often the most effective. Moving from shared hosting to managed WordPress hosting cuts TTFB by half or more. Moving to a serverless or edge-native platform (Vercel, Netlify, Framer) often cuts it by another half. The web design pricing guide covers how hosting fits into the broader cost picture.
Add a CDN
For static and cacheable content, a CDN is the single biggest TTFB improvement. Cloudflare’s free tier covers most use cases for content sites. Bunny and Fastly are strong choices for higher-traffic sites that need fine-grained cache control. CDNs do not help dynamic, per-user content unless you cache at the edge with care, but for marketing pages and blog content the impact is dramatic.
Cache Aggressively
Page caching turns a 600ms dynamic response into a 50ms static response. WordPress sites benefit from page-level caches like WP Rocket, FastCGI cache, or LiteSpeed Cache. Headless setups should use ISR (incremental static regeneration) on Next.js or equivalent strategies.
Object caching speeds up the dynamic responses themselves. Redis or Memcached caches database query results so repeat queries return from memory instead of disk. The combination of page caching and object caching often takes TTFB from 800ms to under 200ms without code changes.
Optimize the Database
Add indexes on columns used in WHERE clauses. Use the slow query log to identify the worst offenders. Refactor queries that join too many tables. Archive old data that is rarely queried. For WordPress, plugins like Query Monitor surface the slowest queries on each request.
Switch to Static or Hybrid Rendering
For most marketing sites, full server-side rendering is overkill. Static site generators (Next.js with SSG, Astro, Eleventy, Hugo, Jekyll) produce HTML at build time. The TTFB on a statically generated page served from a CDN is usually under 100ms. For pages that need some dynamic content, hybrid rendering (static shell with dynamic islands) gives you the best of both.
Reduce Backend Latency
If you must render server-side, profile the request lifecycle. Where does the time go? External API calls? Database queries? Template rendering? Profilers like New Relic, Datadog, and (for WordPress) Query Monitor show the call tree with timings. The fix is usually either caching the slow part or moving it off the critical path.
TTFB on Different Platforms
WordPress
Out of the box, WordPress on cheap shared hosting often hits 1-2 seconds TTFB. With managed WordPress hosting (Cloudways, Kinsta, WP Engine), good caching plugins, and a CDN, it drops to 200-400ms. The WordPress alternatives overview covers when WordPress’s TTFB ceiling becomes a reason to migrate.
Framer and Webflow
Both ship with built-in CDNs and edge-cached HTML. TTFB is usually under 200ms without manual configuration. The platforms handle caching, image optimization, and global distribution automatically.
Next.js on Vercel
Static pages serve from the edge with TTFB usually under 100ms. Server-rendered pages with dynamic content land at 200-500ms depending on the work. Edge functions can bring dynamic content TTFB under 100ms when designed well.
Custom Servers
Performance depends entirely on the architecture. A well-built Node.js or Go service with a CDN in front can hit 50ms TTFB. A poorly tuned application stack can hit 3 seconds. The variance is enormous.
Frequently Asked Questions
What is a good TTFB?
Under 800ms is Google’s recommendation. Under 500ms is good. Under 200ms is excellent and typical for static pages served from a CDN. The threshold should be measured at the 75th percentile of real visits, not the average.
Does TTFB affect SEO?
Indirectly. TTFB is not a direct ranking signal, but it strongly affects LCP, which is. A slow TTFB makes good LCP nearly impossible. Improving TTFB usually improves LCP and other metrics that Google does rank on.
How is TTFB different from LCP?
TTFB measures from request to first byte received. LCP measures from request to the largest content element rendered on screen. TTFB is upstream of LCP — a slow TTFB guarantees a slow LCP, but a fast TTFB does not guarantee a fast LCP if other front-end issues exist.
Can a CDN fix slow TTFB?
For static and cacheable content, yes. A CDN caches the response at edge locations close to the visitor, so TTFB drops dramatically. For dynamic, per-user content, a CDN helps less unless combined with edge caching strategies. Most marketing sites are mostly static and benefit enormously from CDN caching.