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 drops
1. What Does TTFB Measure? (Real Breakdown)
TTFB = DNS + TCP + SSL + Server Processing
The 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 ms
3. 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 β Response
With cache:
Request β Cache β Response
5. 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 increases
6. 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 increases
If CPU is low:
Execution is slow β Response delayed β TTFB increases
7. 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.com
Alternative 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
+
CDN
With this setup, typically:
TTFB: 70 β 200 ms
is 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