How to Reduce WordPress TTFB: A Server & Database Guide

Short answer: Time to First Byte (TTFB) measures the delay between a client browser requesting a page and receiving the very first byte of response data. In WordPress, high TTFB (> 600ms) is almost always caused by three things: absent page caching, slow MySQL database queries on uncached requests, or saturated PHP-FPM workers. Fix TTFB by implementing edge caching, tuning the OPcache and MySQL buffer pool, and offloading expensive autoloaded database options.

When Google's Chrome User Experience Report (CrUX) scores your site for Core Web Vitals, a sluggish TTFB damages your Largest Contentful Paint (LCP) score before a single stylesheet or hero image even downloads.

Measure TTFB accurately with cURL

Browser extensions and Lighthouse introduce variable local network overhead. To diagnose the true server-side response time, run this cURL breakdown in your terminal:

curl -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" \
  -o /dev/null -s https://example.com/

If time_namelookup is above 0.05s, your DNS provider is slow. If time_starttransfer minus time_appconnect is above 0.20s, the delay is inside your web server, PHP interpreter, or MySQL database.

1. Eliminate server cold-starts with OPcache

Every time PHP runs without opcode caching, it parses and compiles dozens of WordPress core and plugin files from scratch. Open your php.ini and ensure OPcache is actively configured:

zend_extension=opcache
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.save_comments=1

Setting opcache.validate_timestamps=0 on production servers eliminates file-stat system calls on every HTTP request. If you deploy changes through Git or CI/CD, simply trigger systemctl reload php8.3-fpm during your deployment step.

2. Optimize MySQL buffer pool & slow queries

When WordPress queries the database, MySQL should read from memory (RAM), never disk I/O. If your InnoDB buffer pool is smaller than your active database size, queries queue up.

Check your buffer pool hit ratio in MySQL:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'

If disk reads occur frequently, increase your innodb_buffer_pool_size in my.cnf to roughly 70% of available server RAM on a dedicated database instance:

[mysqld]
innodb_buffer_pool_size = 4G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2

3. Tune PHP-FPM process manager

When traffic spikes, default ondemand or poorly sized dynamic PHP-FPM process managers cause requests to wait in the listen backlog, directly increasing TTFB.

On high-traffic servers with sufficient RAM, switch to static process management in /etc/php/8.3/fpm/pool.d/www.conf:

pm = static
pm.max_children = 50
pm.max_requests = 1000

Calculate pm.max_children by dividing available server RAM dedicated to PHP by the average PHP worker memory footprint (typically 40–80 MB for standard WordPress sites).

4. Edge caching and Cloudflare Cache Reserve

Serving HTML from an edge CDN point of presence reduces TTFB to 20–50ms worldwide. Configure your Cloudflare or Fastly rules to cache static HTML for anonymous visitors using the Cache-Control: public, max-age=3600, stale-while-revalidate=86400 header, while bypassing the cache when wordpress_logged_in_* or woocommerce_items_in_cart cookies are detected.

---

Struggling with high TTFB on an enterprise WordPress site? Explore my WordPress Performance Optimization services or request a comprehensive speed audit.