PageSpeed Insights shows a red TTFB. The reflex: "we need more CPU" or "we need a VPS". Three weeks later the bill has doubled and server delay moved by 40 ms. The pattern is common: a symptom was treated without finding the link that delays the first byte.
Time To First Byte measures elapsed time between the HTTP request and receiving the first response byte. It compresses DNS, TLS, routing, server queueing, PHP execution, SQL queries and sometimes API calls. Buying CPU does not shorten slow DNS resolution or an unindexed SQL join.
Measure correctly — without cache fooling you
Lab TTFB and real-user TTFB tell different stories. PageSpeed and Lighthouse often run from Google datacenters, sometimes with a warm cache. WebPageTest, curl from your machine, or RUM reports complete the picture.
Minimum procedure:
- Test origin — direct server URL or
Cache-Control: no-cache. - Compare cache ON/OFF — static page (
/favicon.ico) vs dynamic PHP. - Repeat from two regions — network latency ≠ application slowness.
- Note time of day — slow shared hosting at 2 p.m. may be fine at 3 a.m.
| Measurement | What it isolates | Limit |
|---|---|---|
TTFB on static .html | Network + web server | Ignores PHP/SQL |
| TTFB on dynamic page | Full chain | Mixes several causes |
curl -w '%{time_starttransfer}' | Raw server, reproducible | No browser rendering |
PHP-FPM slowlog | Scripts above threshold (e.g. 5 s) | Misses SQL-only issues |
A great TTFB on a CDN-cached page does not prove your WordPress is fast. It mostly proves edge cache works.
Suspects in useful order
Before opening a "slow server" ticket, walk this list. Each link has distinct signals.
DNS. Bad TTL or slow resolver adds 100–300 ms before the server answers. Check with dig or tools like DNSPerf.
TLS and HTTP/2. SSL negotiation on a broken chain or obsolete cipher costs time. Rarely the main bottleneck, but measurable.
PHP-FPM queue. If all workers are busy, the request waits — TTFB rises without a slow script. Signal: variable TTFB, peaks tied to traffic.
Slow PHP script. WordPress plugins, heavy autoload, useless loops. FPM slowlog and Blackfire find the culprit function.
Database. Missing indexes, bloated postmeta, no object cache (Redis). MySQL slow_query_log is your ally.
External calls. Weather APIs, CRM, synchronous payment calls in page render block the entire TTFB.
Typical scenarios: A vs B
| Symptom | Likely cause | Action before upgrade |
|---|---|---|
| Stable ~800 ms TTFB, low traffic | SQL query or plugin | Profile, index, object cache |
| 200 ms morning, 2 s noon TTFB | Saturated FPM workers | Tune pm.max_children, not just CPU |
| OK in France, slow in US | Geography, not server | CDN or closer region |
50 ms on .html, 900 ms on / | Application, not hosting | OPcache, page cache, optimise WP |
The peak: CPU is rarely the first lever
Here is what "Premium 8 vCPU" pages gloss over.
The host can provide a fast server. It will not rewrite your SELECT * FROM wp_postmeta. Confusing the two delays the real fix and inflates budget without proof.
Decide and move forward without blind spots
- Measure origin TTFB, with and without cache, over 24 hours.
- Isolate the link (DNS → FPM → SQL → API).
- Fix the application before comparing hosting offers.
- Retest with the same scenario; only then evaluate a higher plan or our hosting comparator.
For WordPress sites, cross-check with OPcache and PHP-FPM. To filter hosts by network constraints, see the directory.
Frequently asked questions
What TTFB is acceptable for a PHP site?
Under 200 ms server-side for an uncached dynamic page is solid. Between 200 and 600 ms, dig into the chain. Above that, measure before buying resources.
Does TTFB include the CDN?
Yes, if traffic goes through a CDN. Test origin with cache bypass to see real PHP performance.
How do I tell PHP from the database?
Compare static vs dynamic pages, enable MySQL slow query logging, and profile on staging with Blackfire or Xdebug.
Will switching hosts fix high TTFB?
Rarely without fixing the application. An overloaded server adds latency; a slow SQL query stays slow everywhere.
Next time a red TTFB appears, ask before buying CPU: which step in the chain took how long? The answer is usually in a log, not a quote.