Introduction
TTFB (Time To First Byte) is the time that elapses between a user's browser sending a request to the server and receiving the first byte back. This metric directly measures server processing, network, and backend stack performance.
The critical chain from a Core Web Vitals perspective:
TTFB ↑ → HTML arrives late → Render is delayed → LCP ↑ → CWV FAIL → Ranking drops1. What Does TTFB Measure? (Real Breakdown)
TTFB = DNS + TCP + SSL + Server ProcessingThe largest share is generally the Server Processing portion (60–80%).
This phase includes:
- PHP execution
- WordPress bootstrap
- Plugin execution
- Database query
- Cache lookup
2. Good TTFB Values
| TTFB | Status |
|---|---|
| <100 ms | Excellent |
| 100–300 ms | Good |
| 300–600 ms | Average |
| 600–1000 ms | Poor |
| >1000 ms | Critical |
SEO target:
TTFB < 300 ms3. Benchmark Test Environment (Context)
The numerical examples in this article are taken from the following environment:
Test Environment:
- 2 vCPU
- 4 GB RAM
- NVMe disk
- Ubuntu + Nginx
- PHP 8.2
- MariaDB
Load:
- 20 concurrent users
- 1,000 requests
Test Tool:
ab -n 1000 -c 20 https://site.com/4. Cache Impact (Real Benchmark)
Scenario: Cache vs No Cache
| Setup | TTFB | Description |
|---|---|---|
| No cache | 920 ms | PHP + DB on every request |
| Nginx FastCGI | 280 ms | HTML cache |
| LiteSpeed + LSCache | 120 ms | Full-page cache |
Why the difference?
Without cache:
Request → PHP → Plugin → DB → Render → ResponseWith cache:
Request → Cache → Response5. Disk Type (I/O → DB latency → TTFB)
| Disk | Avg Query Latency | TTFB |
|---|---|---|
| HDD | 10–20 ms | 900+ ms |
| SATA SSD | 2–5 ms | 300–500 ms |
| NVMe | <1 ms | 120–250 ms |
Technical explanation
WordPress typically runs 100–300 database queries when loading a page. If the disk is slow, every query waits:
Slow disk → Query wait ↑ → PHP waits → Response delayed → TTFB increases6. PHP Worker & CPU Impact
Benchmark
| PHP Workers | Queue | TTFB |
|---|---|---|
| 2 | Yes | 880 ms |
| 4 | Low | 420 ms |
| 8 | None | 180 ms |
Why?
Workers full → Request queue → Wait time → TTFB increasesIf CPU is low:
Execution is slow → Response delayed → TTFB increases7. CDN Impact (Edge Response)
| Setup | TTFB |
|---|---|
| No CDN | 620 ms |
| CDN (cache off) | 280 ms |
| CDN (cache on) | 110 ms |
Why?
- Edge server is closer to the user
- TCP connection time decreases
- With cache, the origin server is not contacted
8. Server Stack Comparison
| Stack | TTFB | Reason |
|---|---|---|
| Apache (no cache) | 900 ms | Process-based, no cache |
| Nginx + FastCGI | 320 ms | Event-driven |
| LiteSpeed + LSCache | 120 ms | Built-in cache |
Commentary
- Apache → process-based → slow
- Nginx → event-driven → fast
- LiteSpeed → integrated cache → fastest
9. How Is TTFB Measured?
Via command line:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://site.comAlternative tools:
| Tool | Feature |
|---|---|
| PageSpeed Insights | Lab + real user data |
| WebPageTest | Waterfall |
| GTmetrix | Performance analysis |
| Pingdom | Location-based testing |
10. Ideal Server Architecture
Recommended stack for a good TTFB:
Nginx / LiteSpeed
+
FastCGI Cache
+
Redis Object Cache
+
PHP 8.2+
+
MariaDB
+
NVMe Disk
+
CDNWith this setup, typically:
TTFB: 70 – 200 msis achieved.
11. Real Impact Distribution
| Factor | Impact |
|---|---|
| Cache | 35% |
| Disk | 20% |
| CPU | 15% |
| PHP Worker | 15% |
| CDN | 10% |
| Network | 5% |
CONCLUSION
TTFB is not a frontend problem. It is largely a server and hosting issue.
Without a lower TTFB:
- LCP cannot improve
- Core Web Vitals cannot improve
- PageSpeed cannot increase
- SEO performance cannot increase
That is why the order for performance optimization is:
1. Server
2. Cache
3. CDN
4. Database
5. Frontend