Understanding TTFB and Server Response Times

What TTFB Actually Means

Time to First Byte (TTFB) is the time between a browser requesting a page and receiving the first byte of the response. It's measured in milliseconds and includes:

1. DNS lookup time — Resolving the domain name to an IP address 2. TCP connection time — Establishing the TCP handshake 3. SSL/TLS handshake time — Negotiating encryption (for HTTPS) 4. Server processing time — Your server generating the response 5. Network latency — The time data spends in transit

TTFB is like the time between ordering at a restaurant and getting the first item. A long TTFB means something in the chain is slow — but you need to identify which part.

What TTFB Includes (and Doesn't)

TTFB is a server response metric, not a page load metric. A fast TTFB doesn't mean a fast website — you can get a 100ms TTFB but a 5-second full page load if your page includes huge images or slow JavaScript. Conversely, a 500ms TTFB with an optimised page can load faster than the 100ms TTFB site with a bloated frontend.

TTFB measures:

• Server time (how long to generate the HTML)
• Network time (how long to deliver it)

TTFB does NOT measure:

• CSS/JS download and parsing
• Image loading
• Font loading
• JavaScript execution
• Client-side rendering

Core Web Vitals (Google's performance metrics) use TTFB as a signal, but the main metric is LCP (Largest Contentful Paint) — when the main content becomes visible. TTFB contributes to LCP but is not the whole picture.

What's a Good TTFB?

Google's guidance:

• Good: < 800ms
• Needs improvement: 800ms — 1800ms
• Poor: > 1800ms

But these are conservative. For a well-optimised site on decent hosting:

• Excellent: < 200ms
• Good: 200-500ms
• Acceptable: 500-800ms
• Slow: 800-1500ms
• Problematic: > 1500ms

Static pages served from a CDN should be < 50ms. Dynamic WordPress pages on quality hosting should be 100-300ms. A 500ms TTFB suggests something needs attention; 1000ms+ indicates a specific problem.

What Affects TTFB

1. Geographic Distance (Latency)

Light travels about 200km per millisecond in fibre optic cable. Sydney to London is about 16,000km of cable — that's ~80ms minimum one-way, before any processing.

This is why server location matters. A European server serving European visitors will have 5-30ms latency. The same server serving visitors from Australia will have 250-350ms latency.

Fix: Put your server near your users, or use a CDN.

2. DNS Resolution Time

Every domain lookup takes time. The first visit to a domain requires a full DNS lookup (20-120ms depending on the DNS provider). Subsequent requests use cached results.

# Check DNS resolution time
dig yourdomain.com | grep "Query time"
# Query time: 22 msec  <- good
# Query time: 150 msec <- slow

Fix: Use a fast DNS provider (Cloudflare, AWS Route 53, Google Cloud DNS). Avoid your registrar's default DNS if it's slow.

3. SSL/TLS Handshake

The TLS handshake adds 1-2 round trips during connection establishment. With TLS 1.3 (faster than 1.2), this is typically 50-100ms for the first connection.

Fix: Use TLS 1.3, enable OCSP stapling (reduces certificate validation time), and use HTTP/2 or HTTP/3 (connection reuse).

4. Server Processing Time

This is the time your server spends generating the response. For WordPress, this includes:

• PHP execution (themes, plugins, database queries)
• Database query time (how long MySQL/PostgreSQL takes)
• External API calls (if your theme/plugins call external services)
• Template rendering

Server processing is usually the largest TTFB component for dynamic sites.

# Measure PHP execution time
# Add to top of index.php:
$start = microtime(true);
# Add to bottom:
$end = microtime(true);
echo "";

Fix: Optimise your application: reduce database queries, use caching, update slow plugins, use PHP 8.x (faster than 7.x).

5. Caching

A cached page has near-zero server processing time — the server returns pre-generated HTML. This is the single biggest TTFB improvement for dynamic sites.

• Without caching: 300-800ms TTFB (PHP + database queries)
• With page caching: 10-50ms TTFB (serve static HTML file)

Fix: Enable server-side page caching. For WordPress: WP Rocket, W3 Total Cache, or server-level caching (Nginx fastcgi_cache, LiteSpeed LSCache).

How to Measure TTFB Correctly

Method 1: Browser DevTools

Open DevTools → Network tab → reload page → click the document request → look at "Waiting for server response" in the Timing tab.

This measures TTFB from your location. Useful for checking your own experience; doesn't represent all users.

Method 2: cURL

curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nSSL: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://yourdomain.com

Output:

DNS: 0.025s
Connect: 0.042s
SSL: 0.089s
TTFB: 0.245s
Total: 0.312s

This breaks down each phase. The TTFB value (0.245s) minus connection overhead (0.089s) ≈ server processing time (0.156s).

Method 3: WebPageTest.org

WebPageTest measures from multiple global locations with realistic connection speeds. The waterfall view shows exactly when TTFB occurs and what follows.

Method 4: KeyCDN Performance Test

Tests from 10 global locations simultaneously. Shows TTFB variation by geography, which exposes whether server location is the issue.

Method 5: Google PageSpeed Insights

The "Reduce initial server response time" audit flags TTFB > 600ms. It uses lab data, not field data, so it's testing from Google's servers — but it's a useful benchmark.

Common TTFB Problems and Solutions

Problem: TTFB is consistently high everywhere

Likely cause: Server-side processing — slow PHP, too many database queries, no caching. Solution: Enable full-page caching. Investigate slow plugins/themes with Query Monitor (WordPress) or application profiling.

Problem: TTFB is fast from server's country, slow elsewhere

Likely cause: Geographic distance. Your server is in one location; visitors are far away. Solution: Use a CDN for static assets; consider multi-region hosting for dynamic content.

Problem: TTFB varies wildly (100ms → 2000ms → 100ms)

Likely cause: Shared hosting resource contention. Your neighbours on the server are affecting you. Solution: Upgrade to a VPS with dedicated resources.

Problem: TTFB spikes at specific times of day

Likely cause: Traffic spikes or cron job scheduling. Backup jobs, search engine crawls, or traffic peaks. Solution: Schedule heavy tasks during low-traffic hours. Implement rate limiting. Upgrade resources.

Problem: TTFB is fine but page load is slow

Likely cause: Frontend bloat — large images, excessive JavaScript, unoptimised CSS. Solution: Optimise images (WebP, lazy loading, correct sizes). Reduce JavaScript. Use CSS minification. This is not a hosting problem.

TTFB and SEO

Google uses Core Web Vitals as a ranking signal. TTFB is a component of LCP (Largest Contentful Paint) — if TTFB is slow, LCP cannot be fast.

However, Google's ranking impact from TTFB is modest compared to:

• Content quality and relevance
• Backlinks
• Mobile-friendliness
• HTTPS
• Page experience (broader than just speed)

A 200ms TTFB won't rank meaningfully higher than a 500ms TTFB. But a 2000ms TTFB will hurt both rankings and user experience. The goal is "good enough" (<500ms), not "fastest possible."

The TTFB-CDN Relationship

A CDN can dramatically improve TTFB for static content by serving it from a server near the user. But dynamic content (the HTML generated by your server) still requires a round-trip to your origin server unless you're using edge-side rendering.

• Static assets (images, CSS, JS): CDN reduces TTFB from 200ms to 5-20ms
• Dynamic HTML (WordPress page): CDN might add 5-10ms (if proxying through) or no change (if CDN doesn't cache dynamic content)
• Full-page caching at CDN level: Can serve entire pages from edge locations, reducing TTFB to <10ms globally

Cloudflare's APO (Automatic Platform Optimisation) for WordPress caches full pages at Cloudflare's edge. This can reduce TTFB from 300ms to 10ms globally. It costs $5/month for WordPress sites — significant TTFB improvement for minimal cost.

Realistic TTFB Targets

Remember: what's "good" depends on your users' expectations and your competitors. An e-commerce site with 300ms TTFB is excellent; a static blog with 300ms TTFB is underperforming.

Quick Wins for Better TTFB

1. Enable full-page caching — Single biggest improvement for dynamic sites 2. Use PHP 8.x — ~30% faster than PHP 7.x for most workloads 3. Upgrade to NVMe storage — 3-5x faster random I/O than SATA SSD 4. Use a CDN — Especially for static assets and DNS 5. Enable HTTP/2 or HTTP/3 — Connection multiplexing, faster TLS 6. Minimise external API calls — Each external request adds 50-500ms 7. Use object caching — Redis/Memcached for WordPress transients and database query caching 8. Optimise your database — Clean up post revisions, transients, and orphaned data 9. Enable OPcache — PHP opcode caching avoids recompilation on every request 10. Put your server near your users — The single largest geographic factor