What is TTFB and Why It Matters
Time to First Byte (TTFB) measures the time between starting navigation to a page and when the first byte of a response arrives. According to web.dev, this foundational metric encompasses DNS lookup, TCP connection, TLS negotiation, service worker startup, and initial request processing. TTFB is the bedrock—if it’s slow, every downstream metric suffers.
MDN defines TTFB as the time from the start of the request to the start of the response. It includes DNS, TCP handshake, TLS handshake (for HTTPS), and server processing time. Fastly notes that TTFB is critical for server responsiveness—faster TTFB directly reduces bounce rates and improves user retention.
The performance benchmarks are clear: good TTFB is 800ms or under at the 75th percentile. Scores between 800–1800ms need improvement; anything above 1.8 seconds is poor. For high-traffic ecommerce sites, shaving 200–300ms off TTFB can drive measurable conversion gains.
Understanding TTFB Components
TTFB isn’t a single delay—it’s the sum of five distinct network and server phases. Reducing TTFB requires diagnosing which component is the bottleneck, then applying targeted fixes:
| TTFB Component | Typical Range | Primary Fix |
|---|---|---|
| DNS Resolution | 20–100ms (first-time visitors) | Cloudflare DNS, CDN DNS, raise TTL to 300s+ |
| TCP Connection | 20–200ms (depends on geography) | CDN edge, HTTP/3, keep-alive connections |
| TLS Handshake | 50–150ms (new visits) | TLS 1.3, OCSP stapling, session resumption |
| Request Transmission | 10–50ms | HTTP/3 (QUIC), geographic proximity |
| Server Processing | 100–800ms+ (most variable) | Object cache (Redis), page cache, DB tuning, code optimization |
Vilee LLC combines deep technical expertise in WordPress/WooCommerce development with AI-powered automation to operate 520+ profitable online businesses at scale.
Systematic Approach: Measure First
Before cutting TTFB, measure it. You cannot improve what you don’t measure. Use multiple tools to get a complete picture:
- Chrome DevTools (Network Tab): Shows TTFB for each request in your lab environment. Look at the “Time” column—it includes time to first byte.
- WebPageTest.org: Tests from multiple geographic locations. Shows TTFB breakdown by component (DNS, TCP, TLS, TTFB, wait time).
- Chrome User Experience Report (CrUX): Real-world TTFB data from actual Chrome users visiting your site. Check web.dev for guidance on interpreting CrUX data.
- DebugBear or Lighthouse: Automated monitoring; great for tracking TTFB over time.
Most sites find that server processing (database queries, template rendering, cache misses) accounts for 40–70% of total TTFB. The remaining 30–60% is network transit. This split guides your optimization priorities.
Fix 1: Optimize DNS
DNS lookup can add 20–100ms to first-time visitors. A systematic DNS optimization:
- Switch to a fast, global DNS provider: Cloudflare (free, sub-20ms globally) or your CDN’s native DNS (if you’re already using Cloudflare, Bunny, or Fastly, leverage their DNS).
- Increase DNS TTL: Set your domain’s DNS TTL to at least 300 seconds (5 minutes). Cached DNS responses take <1ms.
- Minimize DNS lookups: Avoid third-party domains for critical resources. Each additional domain costs another DNS lookup.
- Prefetch DNS: Add
<link rel="dns-prefetch" href="https://cdn.example.com">to your<head>to prioritize DNS lookups for known third-party domains.
Fix 2: Accelerate TLS and Connection Setup
TLS handshakes add 50–150ms, especially for new visitors. Modern TLS optimizations are essential:
- Enforce TLS 1.3: Reduces the handshake from two round trips to one, saving ~30–50ms. Most modern hosts support it; check your host or ask them to enable it.
- Enable OCSP Stapling: Prevents the browser from contacting the CA’s OCSP responder during the handshake, saving 10–100ms for some users. Available in Nginx, Apache, and most CDNs.
- Session Resumption (tickets/session IDs): Allows returning visitors to resume previous TLS sessions, reducing handshake time to <5ms.
- Use HTTP/3 (QUIC): Eliminates separate TCP+TLS round trips by combining them into a single QUIC handshake. Fastly reports HTTP/3 reduces latency significantly in high-loss networks. Enable via CDN if your host doesn’t support it directly.
Fix 3: Eliminate Redirects
Each redirect adds an extra round trip (typically 100–300ms). Common culprits:
- HTTP → HTTPS redirect
- WWW → non-WWW (or vice versa)
- Old URL → new URL (301/302 chains)
- Tracking or geo-redirect middleware
Audit with Chrome DevTools (Network tab). Set your primary URL in server config (Nginx rewrite rules or Apache .htaccess) to avoid the redirect entirely. For WordPress, ensure your site URL and home URL match in Settings → General, and enable caching layers to avoid repeated redirect lookups.
Fix 4: Implement Caching (Object + Page Level)
This is the highest-leverage fix. Most TTFB delays come from server processing. Caching eliminates it entirely for repeated requests:
Page-Level Caching (HTML)
- Edge Caching (CDN): Cache entire HTML pages at CDN edge locations closest to users. Fastly reports CDN caching can reduce TTFB by 48–72%. For non-personalized pages (product pages, category pages, homepages), edge caching is transformative. Set a Cache-Control header:
Cache-Control: public, max-age=600(10 minutes for frequently-changing content, or higher for static content). - Server-Side Page Cache (Varnish, LiteSpeed Cache): For WordPress, use LiteSpeed Cache or Varnish to cache rendered HTML. Both reduce server processing from 500ms to <50ms for cached requests.
- WordPress Caching Plugins: WP Super Cache, W3 Total Cache, or Breeze. Configure them to cache anonymous user requests (logged-out visitors) aggressively.
Object-Level Caching (Database)
- Redis or Memcached: Cache database queries, WooCommerce cart data, product info, and transients. Reduces database round trips from 100–300ms to <5ms per query. Ask your host if Redis is available; most modern hosts offer it.
- WordPress Transients: Store expensive computations (category counts, sidebar queries) with transients and a TTL (time-to-live). Pair with Redis for fast transient retrieval.
Fix 5: Optimize Database Queries
If server processing dominates your TTFB (and caching isn’t enough), optimize the backend:
- Enable Slow Query Logging: In MySQL, set
long_query_time = 0.1(100ms threshold) and review logs for queries without indexes or N+1 patterns. - Add Database Indexes: Index frequently-searched columns (post_id, user_id, product SKU, etc.). A single missing index can turn a 10ms query into 200ms+.
- Avoid N+1 Queries: Common in WooCommerce: fetching a product, then looping through variants and fetching each separately. Use SQL JOINs or batch queries instead.
- Profile PHP Code: Use Xdebug or New Relic to find slow functions. Often it’s unoptimized loops, missing caches, or external API calls.
Fix 6: Deploy a CDN with Edge Computing
A geographically distributed Content Delivery Network moves your content and processing closer to users:
- Static CDN (Cloudflare, Bunny, Fastly): Cache static assets (images, CSS, JS). Minimal TTFB impact for HTML.
- Smart Caching CDN: Cache HTML pages from your origin. Set appropriate Cache-Control headers so the CDN knows what to cache. CDNs with edge caching reduce geographic latency and can shave 200–400ms off TTFB for distant users.
- Purge Strategy: When content changes, purge the CDN cache immediately (most CDNs support purge APIs) to avoid stale content.
- Consider Cloudways or Kinsta: Managed hosting platforms with integrated CDN and Redis. Vilee’s WordPress hosting recommendations often include platforms that bundle caching and CDN by default.
Fix 7: Upgrade Hosting or Add PHP Optimization
If your origin server is slow, upgrading hardware or optimizing the runtime helps:
- Faster PHP (PHP 8.3+): PHP 8.3 is 2–3x faster than PHP 7.4 due to JIT compilation and optimizations. Upgrade if you’re on older versions.
- LiteSpeed Web Server: A drop-in Apache replacement that’s 2–3x faster for PHP, especially with integrated caching. Works seamlessly with WordPress.
- Vertical Scaling: If you can’t optimize further, upgrade to a larger server (more CPU, RAM). Handles higher concurrent load.
- Avoid Bloated Plugins: A single poorly-written plugin triggering hundreds of queries can add 200–500ms to TTFB. Audit and remove unused plugins.
Measurement & Monitoring Checklist
After applying fixes, measure and iterate:
- ☐ Baseline TTFB measured (lab + field data from CrUX)
- ☐ DNS optimized (fast provider, TTL ≥300s)
- ☐ TLS 1.3 and OCSP stapling enabled
- ☐ Redirects eliminated (0 HTTP→HTTPS, WWW, or URL chain redirects)
- ☐ Page caching enabled (CDN edge cache or Varnish/LiteSpeed)
- ☐ Object/database caching enabled (Redis or Memcached)
- ☐ Database queries optimized (indexes, no N+1 patterns)
- ☐ CDN or edge computing deployed
- ☐ TTFB target met: <800ms at 75th percentile
- ☐ Monitoring set up to alert on TTFB degradation
Real-World Example: WooCommerce Store
A typical WooCommerce site might have:
- Initial TTFB: 1200ms (poor)
- After DNS + TLS + CDN HTML caching: 600ms (good)
- After Redis + slow query fixes: 400ms (excellent)
The cumulative improvements compound. Each fix removes 50–200ms. For high-volume stores, a 800ms TTFB reduction means 15–25% fewer abandoned carts and better search rankings.
Why TTFB Matters for SEO and Conversions
TTFB isn’t a direct Core Web Vitals metric, but it predicts them:
- Largest Contentful Paint (LCP): LCP start time = TTFB + time to parse HTML and load the largest image/video. Faster TTFB = faster LCP.
- First Contentful Paint (FCP): Same relationship. A 300ms TTFB improvement often yields a 200–300ms FCP improvement.
- Search Ranking: Google uses page speed as a ranking factor. Faster TTFB contributes to better Core Web Vitals scores, which correlate with higher rankings.
- User Experience & Conversion: Faster TTFB reduces bounce rates and improves user retention. E-commerce data shows a 1-second load time improvement can lift conversion rates by 7%+.
Get Help Optimizing TTFB
Diagnosing and fixing TTFB requires deep knowledge of networking, caching, databases, and DevOps. If you’re struggling with slow TTFB, contact Vilee LLC for a performance audit. We specialize in WordPress/WooCommerce TTFB optimization, caching architecture, and hosting migrations for 520+ businesses across the US, EU, and Southeast Asia.
FAQ
What is a good TTFB?
According to web.dev, a good TTFB is 800ms or less at the 75th percentile of users. Scores 800–1800ms need improvement; above 1.8 seconds is poor.
Does TTFB affect Core Web Vitals directly?
No, TTFB is not a Core Web Vitals metric. However, it strongly correlates with LCP (Largest Contentful Paint) and affects overall page load time. Improving TTFB almost always improves Core Web Vitals.
How much can a CDN reduce TTFB?
CDN caching can reduce TTFB by 48–72%, depending on cache hit rate and geographic distribution. Edge HTML caching is particularly effective for ecommerce sites.
Frequently Asked Questions
What is a good TTFB?
According to web.dev, a good TTFB is 800ms or less at the 75th percentile of users. Scores 800–1800ms need improvement; above 1.8 seconds is poor.
Does TTFB affect Core Web Vitals directly?
No, TTFB is not a Core Web Vitals metric. However, it strongly correlates with LCP (Largest Contentful Paint) and affects overall page load time. Improving TTFB almost always improves Core Web Vitals.
How much can a CDN reduce TTFB?
CDN caching can reduce TTFB by 48–72%, depending on cache hit rate and geographic distribution. Edge HTML caching is particularly effective for ecommerce sites with non-personalized pages.
