Time to First Byte (TTFB)
Time to First Byte (TTFB) measures how long it takes for the browser to receive the first byte after requesting a page. Because every other metric starts after the HTML begins arriving, TTFB is a common root cause behind slow FCP/LCP on WordPress sites.
If TTFB is 2.5 seconds, the absolute fastest possible LCP score is 2.5 seconds—even with zero images and perfect CSS. TTFB represents the combined sum of DNS resolution, TLS handshaking, PHP execution, and MySQL database querying.
The Metric Baseline
| Rating Constraint | Authorized TTFB Target | Diagnostic Meaning |
|---|---|---|
| Good | ≤ 200ms | Typically requires effective page caching and/or edge delivery. |
| Needs Improvement | 200–600ms | Often indicates latency or uncached server work. |
| Poor | > 600ms | Commonly caused by slow backend execution, I/O limits, or overloaded hosting. |
Dissecting the Request Lifecycle
Understanding TTFB requires mapping the microscopic events that occur before a single byte of HTML is transmitted.
| Stage Progression | Typical Duration | Technical Description |
|---|---|---|
| 1. DNS Resolution | 10–50ms | Translating the human domain (example.com) to a physical IP boundary. |
| 2. TCP Handshake | 20–100ms | The network physically establishing a synchronized connection routing. |
| 3. TLS Negotiation | 50–150ms | Evaluating encryption certificates (SSL) and securing the channel. |
| 4. Server Execution | 50–2,000ms+ | PHP parsing the WordPress core, executing plugins, and querying MySQL. |
| 5. First Byte Transit | ~1ms | The origin hardware transmits the initial HTML headers down the pipe. |
Practical takeaway: Stage 4 (server execution) is often the largest and most controllable component for WordPress sites.
Step-by-Step Diagnostic Examples
Calculate TTFB via Terminal
Bypass browser variables entirely and interrogate the server hardware directly:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://yourdomain.com
Expected Return Output:
TTFB: 0.183
0.183 seconds (183ms) represents a perfectly functioning caching layer.
Assess TTFB inside Google Chrome
- Press
F12to open DevTools, and shift to the Network tab. - Execute a Hard Reload (
Ctrl + Shift + R). - Click the absolute first document row (typically your root
/). - Select the Timing tab and locate the Waiting for server response metric.
Demonstrate the Value of HTML Caching
# Request 1: Bypassed Cache (Forces MySQL and PHP generation)
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://yourdomain.com
# Output: TTFB: 1.250
# Request 2: Engaging LSCache (Reading flat HTML from origin disk)
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://yourdomain.com
# Output: TTFB: 0.085
Practical Scenarios
Shared Hosting Resource Starvation
Problem: Baseline TTFB is ~2.1s on a busy shared host. Fix: Move to a dedicated VPS with better CPU isolation, NVMe storage, and OPcache configured. Result: TTFB improves from ~2.1s to ~250ms.
WooCommerce Administration Bloat
Problem: Uncached visitor TTFB hits 1.2s because rendering the homepage triggers 85 heavy, redundant MySQL product queries simultaneously. Fix: Add Redis object caching and reduce repeated database work. Result: TTFB improves from ~1.2s to ~78ms.
Oceanic Geographic Distance
Problem: An EU-based customer requesting data from a Dallas, Texas origin server faces a harsh 670ms TTFB delay simply due to physical transatlantic cable latency. Fix: Use a CDN (for example Cloudflare APO) to cache and serve HTML closer to users. Result: EU TTFB improves from ~670ms to ~95ms.
Common Mistakes & Troubleshooting
| Mistake | Explanation | Solution |
|---|---|---|
| Optimizing images before touching TTFB | Smashing a JPEG achieves nothing if the server requires 3 seconds to deliver the DOM. | Secure TTFB < 500ms before touching a single frontend asset. |
| Testing only from the origin server | Running curl from the VPS shell hides network latency. | Test from multiple locations (WebPageTest, or remote curl). |
| Forgetting logged-in users | Page caching often bypasses authenticated/cart sessions. | Add object caching and optimize backend code paths for dynamic sessions. |
| Cold Cache Syndrome | Purging the cache deletes the HTML; the immediate next visitor suffers the 2.0s PHP rebuild penalty. | Configure a cache crawler to proactively rebuild purged assets. |
| Redirect Chains | Bouncing from http to https to www physically triples the TTFB sequence. | Force a single rigid redirect straight to the finalized canonical URL. |
Target Quick Reference
TTFB Core Engineering Directives
Target Matrix:
- Pass Goal:
≤ 200ms
Immediate Optimization Priorities:
- Enable heavy full-page caching via LSCache or similar architecture.
- Initialize persistent Redis Object Cache for dynamic database shielding.
- Configure PHP-FPM workers accurately and enable OPcache deeply.
- Delegate global routing to Cloudflare APO Edge networking.
- Upgrade to NVMe-backed dedicated or VPS hosting clusters.