Time to First Byte (TTFB) is how long a browser waits before receiving the first byte of your page. For WordPress, it’s dominated by server work: PHP executing WordPress and plugins, plus database queries. A slow TTFB delays everything else (CSS, images, LCP). Google considers ≤ 0.8 seconds good for real users, and a well-tuned, cached WordPress page can be served in under 100 ms from the server.

Measure it properly

curl -o /dev/null -s -w 'dns: %{time_namelookup}  connect: %{time_connect}  tls: %{time_appconnect}  ttfb: %{time_starttransfer}  total: %{time_total}\n' https://example.com/
  • Run it several times. The first request may be uncached.
  • Test cached (anonymous) and uncached pages (?nocache=1, a logged-in page, or the cart).
  • ttfb − tls is roughly your server’s processing time.
  • Compare from different regions (online tools such as WebPageTest, or PageSpeed Insights’ field data for real users).

See Core Web Vitals and server performance.

The biggest win: full-page caching

Serving pre-built HTML skips PHP and the database entirely. TTFB drops from hundreds of milliseconds to a few.

Check that caching actually works: look for a cache header (X-Cache: HIT, X-FastCGI-Cache: HIT, cf-cache-status: HIT).

Make uncached requests faster

Logged-in users, carts, search and first visits still hit PHP. Work through these:

Fix Typical effect
PHP 8.2/8.3 instead of 7.x Faster execution across the board
OPcache enabled and sized Avoids recompiling PHP files every request
Redis object cache Fewer repeated database queries
Clean autoloaded options Less data loaded on every request
Fewer and lighter plugins Less code per request
Enough PHP-FPM workers No queueing under load
Tuned InnoDB buffer pool Queries served from memory

Guides: php.ini and OPcache, Redis object cache, WordPress autoloaded options, PHP-FPM tuning, and MySQL performance tuning.

Find what’s slow in PHP

  • Query Monitor (on staging, or for admins): slow queries, HTTP calls to external services, and per-plugin time.
  • External API calls during page generation (licence checks, social counts, remote fonts fetched server-side) can add seconds. Remove them, or cache their results.
  • For deep profiling, use a profiler such as XHProf/Tideways or SPX on a staging copy.

Network and connection setup

TTFB also includes DNS, TCP and TLS time:

  • Server location close to your visitors. Distance adds latency to every round trip. See choosing a VPS location and latency vs bandwidth.
  • Fast DNS (a good DNS provider, sensible TTLs).
  • HTTP/2 or HTTP/3, TLS 1.3, and OCSP stapling reduce connection overhead. See HTTP/2 and HTTP/3 in Nginx.
  • A CDN terminates TLS near the visitor, which helps even for uncached HTML.

Avoid TTFB spikes

  • WP-Cron on page loads can make random requests slow. Use a real cron job. See WordPress real cron.
  • Cache purges after every small change can leave many visitors on uncached pages. Purge selectively, and preload important pages.
  • Undersized VPS: if CPU is maxed or RAM is in swap, everything slows down. Watch load average and memory. See uptime and load average.

Typical targets

Request type Good server TTFB
Cached page (Nginx/edge) < 50–100 ms
Uncached simple page < 300–500 ms
Uncached WooCommerce cart/checkout < 600–800 ms

Quick reference

Step Action
Measure curl -w '%{time_starttransfer}' (cached and uncached)
Biggest win Full-page cache
Uncached speed PHP 8.x, OPcache, Redis, lean plugins
Network Nearby server location, HTTP/2+, CDN
Spikes Real cron, selective purges, enough resources

Related: WordPress slow admin and WordPress VPS performance tuning.

  • WordPress
  • Performance
  • Core Web Vitals