13 min read · Technical SEO · Last updated July 2026
Quick answer: TTFB (Time to First Byte) is the time between a browser sending an HTTP request and receiving the first byte of response from the server. Google’s threshold for “good” TTFB is under 800ms. Slow TTFB delays every other page load metric (LCP, FCP, INP) because nothing can render until the server responds. The primary causes are poor hosting, missing caching, no CDN, and unoptimized database queries.
Introduction
TTFB is the starting gun of your page load race. Before the browser can render anything — before images load, scripts execute, or users see content — it must receive the first byte of HTML from your server. Every millisecond of TTFB delay cascades into every subsequent performance metric.
A page that takes 2.5 seconds to reach “good” LCP with a 200ms TTFB will take 3.5+ seconds with a 1,200ms TTFB. Same content, same code, same images — the only difference is server response time. At scale, on thousands of pages, slow TTFB is one of the highest-impact performance problems to fix.
This guide covers TTFB from cause to fix: why servers respond slowly, how hosting quality affects every performance metric, what caching strategies actually matter, how CDNs work, and when database optimization is the bottleneck.
What you’ll learn:
– What TTFB measures and Google’s thresholds
– The most common server-side causes of slow TTFB
– How to evaluate hosting quality and when to migrate
– Caching strategies that cut TTFB by 60–90%
– CDN implementation and configuration
– Database query optimization for dynamic sites
– How to measure and monitor TTFB over time
Table of Contents
- What Is TTFB?
- Why TTFB Matters for SEO
- Server-Side Causes of Slow TTFB
- Hosting Quality: The Most Overlooked Factor
- Caching Strategies That Cut TTFB
- CDN Implementation
- Database Optimization
- Measuring and Monitoring TTFB
- Frequently Asked Questions
- Conclusion
What Is TTFB?
TTFB (Time to First Byte) measures the time from when a browser sends an HTTP GET request to when it receives the first byte of the response from the server. It encompasses three phases:
- DNS lookup time — resolving the domain name to an IP address
- TCP connection time — establishing the network connection (including TLS handshake for HTTPS)
- Server processing time — the actual time your server takes to generate and start sending the response
The last component — server processing time — is what optimization work targets. DNS and TCP connection time can be addressed separately (via faster DNS providers, CDN, and HTTP/2 or HTTP/3 protocols), but they’re typically a smaller contributor to total TTFB than server processing time.
Google’s TTFB thresholds (2026):
– Good: 0–800ms
– Needs Improvement: 800–1,800ms
– Poor: 1,800ms+
These thresholds apply to real-user data as measured by the Chrome User Experience Report (CrUX), which feeds Google’s Core Web Vitals assessment. Your lab-measured TTFB (from tools like WebPageTest or PageSpeed Insights) should comfortably beat these thresholds — real-user conditions are often slower than controlled lab tests.
Why TTFB Matters for SEO
Google confirmed TTFB as a component of the Core Web Vitals assessment in 2023 updates. While TTFB itself isn’t one of the three CWV metrics (LCP, INP, CLS), it directly determines whether you can achieve good scores on all three.
TTFB and LCP: Largest Contentful Paint cannot start until the browser receives HTML from the server. A 1,200ms TTFB means LCP starts 1,200ms late by definition, regardless of how well the rest of the page is optimized. For a target LCP of 2.5 seconds (Google’s “Good” threshold), that leaves only 1.3 seconds for everything else — parsing, rendering, image loading. With a 200ms TTFB, you have 2.3 seconds for the same work. That 1-second difference is the difference between “Good” and “Needs Improvement” LCP on most pages.
TTFB and Crawl Efficiency: Googlebot has a crawl budget allocation per domain. When your server responds slowly, Googlebot crawls fewer pages per crawl session. For large sites, this means important pages are crawled less frequently, and content updates take longer to reflect in rankings. Improving TTFB directly increases effective crawl throughput.
User Experience Impact: A well-documented finding from Google’s research: 53% of mobile users abandon a page that takes more than 3 seconds to load. TTFB is a direct contributor to load time. A site with consistently sub-200ms TTFB delivers a categorically different experience than one with 1,500ms+ TTFB.
Server-Side Causes of Slow TTFB
Unoptimized server software. PHP-based sites (WordPress, Magento) on default PHP configurations run synchronous page generation: for every request, PHP parses the template, executes functions, queries the database, and assembles HTML before sending a single byte. Without caching, this process takes 300ms–2,000ms depending on page complexity and database query count.
Uncached dynamic content. If your CMS generates page HTML fresh on every request, TTFB is limited by how fast your server can generate that HTML. On a shared hosting plan, with database queries taking 100–300ms each and 5–15 queries per page, you’re looking at 500ms–3,000ms TTFB before the browser sees a byte.
Resource-constrained hosting. Shared hosting divides server resources (CPU, RAM, I/O) across hundreds of sites. When a neighboring site spikes in traffic, your server resources are impacted. Entry-level hosting plans frequently deliver 800ms–2,000ms TTFB under normal traffic conditions.
Database bottlenecks. For dynamic sites, database query time is often the single biggest contributor to TTFB. A WordPress site with 15 unoptimized database queries per page load, each taking 50ms, generates 750ms of database latency before any HTML is assembled.
Geographic distance. A server in New York delivering content to a user in Kathmandu adds 200–400ms of network latency to every request. Geographic distance is a TTFB contributor that CDNs specifically solve.
Missing HTTP/2 or HTTP/3. HTTP/1.1 handles one request per connection. HTTP/2 multiplexes multiple requests per connection. HTTP/3 adds QUIC transport for further latency improvements. Sites still on HTTP/1.1 pay a connection overhead cost that HTTP/2 eliminates. Most modern hosting and CDN providers support HTTP/2 or HTTP/3 by default.
Hosting Quality: The Most Overlooked Factor
Hosting is the foundation everything else builds on. No amount of caching or CDN optimization can fully compensate for fundamentally poor hosting infrastructure.
Shared hosting TTFB: 400–2,000ms typical. You’re sharing physical server resources with potentially hundreds of other sites. CPU, RAM, and I/O are all contested. Cheap shared hosting is functionally incompatible with Google’s TTFB targets for high-traffic sites.
VPS hosting TTFB: 200–800ms typical. Dedicated virtual CPU and RAM significantly improve TTFB. A properly configured VPS (with caching) commonly achieves 200–400ms TTFB. Cost: $20–$100/month. This is the minimum viable hosting tier for sites concerned about Core Web Vitals.
Managed WordPress hosting TTFB: 100–400ms typical. Providers like Kinsta, WP Engine, and Cloudways are specifically optimized for WordPress performance. They include server-level caching (Nginx FastCGI cache or Redis), optimized PHP configurations, and global CDN. Kinsta’s Google Cloud infrastructure routinely delivers sub-150ms TTFB for cached pages. Cost: $35–$200/month depending on traffic.
Cloud hosting (AWS, Google Cloud, Azure): 50–200ms typical. Direct cloud infrastructure with properly configured server stack delivers consistently low TTFB. The trade-off is configuration complexity and DevOps requirements. With proper caching configured, cloud hosting can achieve sub-100ms TTFB globally.
When to migrate hosting: If your TTFB consistently exceeds 800ms without a caching layer, hosting migration is the highest-impact fix available. A client migrating from budget shared hosting to managed WordPress hosting reduced TTFB from 1,400ms to 180ms — an improvement that cascaded to LCP going from 4.2s to 1.8s without changing any page content.
Caching Strategies That Cut TTFB
Caching is the single most impactful intervention for TTFB on dynamic sites. Effective caching serves pre-generated HTML responses instead of regenerating them on every request.
Full-page caching (most impactful): The server generates the HTML once, stores it as a static file, and serves that static file for subsequent requests. A cached static file can be served in 10–50ms vs 300–2,000ms for a dynamically generated page. TTFB improvement: 85–95%.
WordPress full-page caching options:
- WP Rocket (paid, $49/year): Easiest setup, excellent defaults, generates static cached pages, handles cache invalidation on publish
- W3 Total Cache (free): More complex configuration but powerful; supports CDN integration, database caching, and object caching
- Server-level cache: Nginx FastCGI cache (for VPS/cloud servers) bypasses PHP entirely for cached pages — fastest possible response. Typically configured by your hosting provider on managed plans.
Object caching with Redis or Memcached: Caches database query results in memory so repeated identical queries return instantly from RAM instead of hitting the database. Particularly effective for WooCommerce and other database-heavy WordPress setups. Redis object caching reduces database load by 50–80% on typical WordPress sites.
OPcache (PHP bytecode caching): PHP parses script files on every request by default. OPcache stores parsed PHP bytecode in memory, eliminating the parsing overhead for subsequent requests. TTFB improvement: 10–30% on PHP-heavy sites. Enable in php.ini: opcache.enable=1.
Browser caching / cache-control headers: Instruct browsers to store static assets (CSS, JS, images) locally. Doesn’t directly improve TTFB for the HTML document, but eliminates repeat requests for assets on subsequent page loads. Set Cache-Control: public, max-age=31536000 for static assets with content hashes in filenames.
CDN Implementation
A Content Delivery Network (CDN) solves geographic latency by distributing your content to servers worldwide. When a user in Sydney requests your page hosted in London, they get it from a CDN node in Sydney instead — reducing network latency from 300ms to 20ms.
CDN options for most sites:
Cloudflare (Free–$200/month): The most widely deployed CDN. Free tier provides CDN, basic caching, and DDoS protection. Pro tier ($20/month) adds image optimization, more cache control, and Web Analytics. For WordPress sites, Cloudflare’s APO (Automatic Platform Optimization) adds edge caching of full HTML pages — reducing TTFB for WordPress sites to 50–150ms globally. APO costs $5/month.
Bunny.net ($10–30/month): Simpler, developer-focused CDN with excellent performance and competitive pricing. Good choice for static assets and bandwidth-heavy sites. Edge scripting available for advanced caching logic.
Cloudfront (AWS): Integrates natively with AWS hosting. Pricing based on usage — typically $5–$50/month for moderate-traffic sites. Good choice if you’re already on AWS infrastructure.
CDN configuration best practices:
- Cache static assets aggressively (CSS, JS, images, fonts): 30-day expiry minimum
- Cache HTML pages at the edge (with correct cache invalidation on publish)
- Enable HTTP/2 or HTTP/3 via CDN (all major CDNs support this)
- Configure CDN to respect Vary: Accept-Encoding headers for Brotli/gzip compression
- Set up monitoring alerts for cache hit rate — a rate below 80% indicates caching configuration issues
Database Optimization
For dynamic CMS sites (WordPress, Magento, Drupal), database query performance is often the primary bottleneck after hosting and caching are addressed.
Identifying slow queries:
- WordPress: Install Query Monitor plugin. It shows every database query executed per page load, query time, and which plugin/theme triggered it
- MySQL: Enable slow query log (slow_query_log=1, long_query_time=1) to capture queries taking over 1 second
- Ahrefs: Site Audit highlights pages with slow TTFB that correlate with database bottlenecks
Common database TTFB culprits:
- WooCommerce product pages with many variations running duplicate queries
- Plugins that query the database on every page load (social proof widgets, stock checkers, analytics plugins)
- Missing database indexes on large tables
- WordPress wp_options table bloat from plugin data accumulation
- Long-running cron jobs executing during user page loads
WordPress-specific database fixes:
- WP-Optimize or Advanced Database Cleaner: Remove post revisions, transients, spam comments, and orphaned data that balloon the wp_posts and wp_options tables
- Transient caching: Replace repeated expensive queries with transients — temporary cached values stored in the database. set_transient('my_query', $results, HOUR_IN_SECONDS) stores query results for 1 hour
- Query deduplication: Use plugins that eliminate duplicate queries (many WordPress sites run the same query 10–20x per page load through multiple plugins)
Key takeaway: Improving TTFB follows a hierarchy: fix hosting first, add caching second, add a CDN third, then optimize the database. Each layer compounds — a well-cached page on a CDN with good hosting can hit sub-100ms TTFB regardless of database query count, because the database is only queried when the cache misses.
Measuring and Monitoring TTFB
Field data (real users):
- Google Search Console > Core Web Vitals report: Shows LCP and CLS field data segmented by “Good/Needs Improvement/Poor.” TTFB is a component of the LCP timeline visible in detail.
- Chrome UX Report (CrUX): Accessible via PageSpeed Insights and Google Data Studio connector. Shows TTFB percentile distribution for real users.
- Real User Monitoring (RUM) tools: Datadog, Sentry Performance, or Cloudflare Analytics provide TTFB monitoring at the page level across real user sessions.
Lab data (controlled tests):
- WebPageTest (webpagetest.org): Most comprehensive. Shows TTFB in the waterfall, broken down by DNS, TCP, and server processing time. Run from multiple geographic locations to identify if geographic distance is a factor.
- PageSpeed Insights: Shows “Server Initial Response Time” audit with a pass/fail against the 600ms lab threshold.
- Lighthouse (in Chrome DevTools): Server response time audit shows exact TTFB for the tested URL under lab conditions.
Monitoring cadence: Run TTFB tests weekly on your 10 highest-traffic pages. Set up uptime monitoring (UptimeRobot, Better Uptime) that alerts on response time exceeding 2,000ms. Check Search Console CWV report monthly for field data trends.
Frequently Asked Questions
My TTFB is good on desktop but slow on mobile. Why?
Lab-measured TTFB doesn’t vary by device — the server response is the same. What varies is the network connection. Mobile TTFB measurements from PageSpeed Insights use simulated “Slow 4G” throttling, which adds artificial latency. Your actual mobile users’ TTFB depends on their network quality. A CDN with edge caching is the best way to minimize TTFB for mobile users on slower connections.
Does TTFB affect ranking directly or only through CWV?
Both pathways exist. Indirectly through Core Web Vitals — slow TTFB leads to slow LCP, which affects the Page Experience ranking signal. Directly through crawl efficiency — slow server response reduces how many pages Googlebot can crawl per session, potentially affecting crawl frequency for important pages. Both matter at scale.
Is 200ms TTFB achievable on WordPress?
Yes, with the right stack. Managed WordPress hosting (Kinsta, WP Engine) with full-page caching enabled consistently achieves 150–250ms TTFB for cached pages. For uncached pages (cache miss, logged-in users, cart pages), TTFB will be higher — 300–800ms is typical on optimized managed hosting.
How does TTFB relate to LCP specifically?
TTFB is the start of the LCP timeline. The browser cannot fetch any sub-resources (images, fonts, CSS) until it receives the initial HTML from the server. Each millisecond of TTFB adds directly to the LCP timestamp. Formula: LCP ≈ TTFB + resource load delay + render time.
My caching plugin is active but TTFB is still slow. What’s wrong?
Check whether caching is actually being applied. Common issues: (1) Cache purge is too aggressive — every minor event (comment posted, plugin update) clears all cache; (2) Pages are excluded from cache — many caching plugins exclude logged-in users, WooCommerce cart/checkout pages, and pages with query strings; (3) Object cache isn’t configured — the page cache works but database queries still run on cache miss; (4) Hosting environment doesn’t support caching (some restrictive shared hosting environments block file-based caching).
Conclusion
TTFB optimization follows a clear hierarchy: hosting first, caching second, CDN third, then database tuning. Each layer builds on the previous one. Good hosting gives your caching layer a solid foundation. Caching reduces the work your hosting needs to do. CDN reduces geographic latency for cached responses.
The target is clear — sub-800ms TTFB for field data, ideally under 400ms for cached pages. Use the gauge and waterfall tools above to identify where your time is being spent. Fix the largest contributor first. Monitor monthly. TTFB improvements compound into LCP improvements, which compound into Core Web Vitals improvements, which compound into the rankings consistency that comes from good Page Experience signals.
Let Ignited Nepal Handle This
→ Request a Free Technical SEO Audit
Written by the Ignited Nepal SEO team. We build organic search systems for businesses across Nepal, Australia, UAE, USA, UK, and beyond. ignitednepal.com