Time to first byte gets blamed for slow sites constantly, yet most guides treat it as a single knob to turn. It is not. TTFB is the sum of at least five distinct stages: DNS resolution, TCP connection, TLS handshake, server processing time (PHP plus database), and the raw network distance between your origin server and the visitor. Fix the wrong stage and you will see no improvement. Fix them in order and the results compound quickly.
This guide walks through each stage, explains what you can measure, and lists the specific levers available to a WordPress site owner in 2024. No invented benchmarks, no vague advice. Just the stages and the tools.
How to Actually Measure TTFB Before You Change Anything
Before touching a single setting, get a baseline you can trust. Two reliable sources exist for TTFB data.
- PageSpeed Insights shows both lab data (a single Lighthouse run from Google’s servers) and field data (real user measurements from the Chrome User Experience Report). Always note which you are looking at. Lab data is reproducible; field data reflects actual visitor conditions across locations and devices.
- WebPageTest lets you choose a test location, connection speed, and browser, and it breaks the waterfall into DNS, connect, TLS, and wait (which is server processing time) columns. Run tests from multiple geographic regions to see whether distance is your primary problem.
Record your baseline TTFB from at least two locations. You need that number to know whether any change you make actually helped.
Stage 1: DNS Resolution
DNS is often the first unexpected time sink. When a visitor’s browser has not cached your domain, it has to query a resolver before it can even open a connection to your server. A slow or overloaded DNS provider can add 50 to 300 milliseconds before a single packet reaches your origin.
The fix here is simple: use a fast, well-distributed authoritative DNS provider. Cloudflare’s DNS, for example, is widely regarded as fast because of its edge network footprint. Once you move to a reputable provider, DNS is rarely the bottleneck again. Check TTL values too. Extremely short TTLs (under 300 seconds) force re-resolution more often than necessary.
Stage 2: TLS Handshake
HTTPS is non-negotiable in 2024. The TLS handshake, however, adds round trips between client and server. On the first connection, TLS 1.3 requires one round trip; older TLS 1.2 required two. Modern servers and CDNs default to TLS 1.3 now, so this stage is mostly about confirming your stack is not running something old.
HTTP/3 (which runs over QUIC rather than TCP) eliminates the separate TCP handshake entirely, combining connection establishment and TLS negotiation. If your server or CDN supports HTTP/3, enabling it removes a round trip on initial connections. Cloudflare enables HTTP/3 by default on proxied domains, which is one of the quieter wins you get from routing traffic through the edge.
TLS session resumption also matters. When a returning visitor reconnects, the server can resume a previously negotiated session instead of doing a full handshake. Most modern web servers handle this automatically if they are configured correctly.
Stage 3: Network Distance (Latency to Origin)
Speed of light is a hard limit. A visitor in Sydney connecting to an origin server in New Jersey will experience at minimum 150 to 200 ms of round-trip latency regardless of how fast your PHP is. This is the stage that caching at the edge solves most completely.
For uncacheable, dynamic responses, the answer is geographic proximity: host your origin in the region where most of your visitors are. Check your analytics before assuming. Many site owners host in US-East because that is a default, not because their audience is there.
For cacheable content, moving the response to a CDN edge node near the visitor collapses this distance to tens of milliseconds. That is covered in the final section.
Stage 4: PHP Processing Time
This is the stage most people mean when they say their server is slow. PHP processing time is the interval between the server receiving the request and beginning to send the response. A WordPress page load without caching involves bootstrapping the WordPress core, loading plugins, running theme code, and querying the database. On an unoptimized site this can easily exceed one second.
Use PHP 8.x with OPcache Enabled
PHP 8.3 with OPcache is the current solid default recommendation. OPcache compiles your PHP files to bytecode and stores them in memory, skipping the parse-and-compile step on every request. Without it, PHP re-reads and recompiles your plugin and theme files on every page load. Verify OPcache is active by checking phpinfo() or running:
php -r "echo ini_get('opcache.enable') . PHP_EOL;"A return value of 1 means it is on. If it is not, OPcache is enabled in php.ini via opcache.enable=1. Confirm reasonable values for opcache.memory_consumption (128 MB or more on a site with many plugins) and opcache.max_accelerated_files (at least 10000 for a typical WordPress install).
Add Object Caching with Redis
WordPress makes repeated database queries for the same data within a single request. The built-in object cache lives only for the duration of the request. A persistent object cache backed by Redis or Memcached survives across requests, so subsequent page loads retrieve frequently accessed objects from memory rather than hitting the database again.
To enable Redis object caching, install the Redis Object Cache plugin (or a compatible alternative), then copy the drop-in file to wp-content/object-cache.php. Verify it is working:
wp cache get test-key --debugYou should see cache hits being served from Redis in the debug output.
Reduce Plugin Overhead
Each active plugin adds to PHP bootstrap time. Audit your plugins with Query Monitor (install it temporarily) to find which ones generate the most database queries or take the most execution time. Deactivate and delete anything that is not earning its overhead. Twenty plugins doing small things can collectively cost several hundred milliseconds.
Stage 5: Database Query Time
Slow database queries are often the single biggest contributor to high TTFB on established WordPress sites. The most common culprits are unindexed queries, the autoloaded options table bloat, and poorly written plugin queries.
Check Autoloaded Options
WordPress loads all autoloaded rows from wp_options on every request. If plugins have stored large blobs there, every page load carries that weight. Audit it with:
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload = 'yes' ORDER BY size DESC LIMIT 20;"Large entries from inactive or removed plugins are safe to delete. Be cautious with anything you do not recognize: look it up before removing it.
Enable the Slow Query Log
On servers you control, enable MySQL’s slow query log (set long_query_time to 0.5 or 1 second) to identify queries that are taking excessive time. Plugin authors do not always index their custom tables. If you find a badly unindexed query from a plugin you depend on, report it as a bug and consider adding the index manually while you wait for a fix.
Stage 6: Full-Page Caching and the Edge Layer
All of the above reduces the cost of generating an uncached response. Full-page caching eliminates PHP and database work entirely for cache-hit requests, because the server returns a pre-built HTML file instead of running WordPress at all.
Full-Page Caching at the Origin
On a LiteSpeed or OpenLiteSpeed server, the LiteSpeed Cache plugin handles full-page caching natively at the server level, which is faster than PHP-based caches because the cached response is served before PHP even starts. Configure it once, test with logged-out sessions (caches typically bypass logged-in users and cart pages), and verify cache hits by checking the X-LiteSpeed-Cache response header for a value of hit.
Edge Caching with Cloudflare
Origin-level caching still requires a request to travel to your server. Edge caching means Cloudflare’s node closest to your visitor returns the cached HTML directly, which reduces the distance to near zero for most of the world.
To cache HTML at Cloudflare’s edge, you need a Cache Rule (previously a Page Rule) that sets the cache level to cache everything for your front-end URLs, combined with an appropriate edge TTL. Exclude admin paths (/wp-admin/*), the login page, and anything that sets cookies indicating a logged-in or cart session.
A cache hit served from Cloudflare’s edge bypasses your origin entirely. The remaining TTFB is the latency from visitor to the nearest Cloudflare data center plus Cloudflare’s own processing time. That number, for most visitors, will be well under 100 ms and often in the 20 to 50 ms range. That is what makes TTFB discussion at the single-digit-tens-of-milliseconds level possible.
One important note: keeping your origin server’s IP address unpublished (not appearing in DNS directly) is important for DDoS resilience when you are behind Cloudflare. If your origin IP is known, attackers can bypass the edge entirely.
Putting It Together: A Working Order
- Measure first. Get baseline TTFB from multiple locations using WebPageTest or PageSpeed Insights.
- Confirm PHP 8.3 and OPcache are active on your server.
- Add Redis persistent object caching.
- Audit and trim plugins and autoloaded options.
- Enable full-page caching at the server level (LiteSpeed Cache on LiteSpeed servers, or a comparable solution elsewhere).
- Route traffic through a CDN with edge caching configured for HTML, not just assets.
- Re-measure. Compare against your baseline from multiple locations.
Takeaway
TTFB is not one problem, it is a pipeline. DNS, TLS, PHP, the database, and raw distance each contribute independently. The compounding effect of fixing each stage is significant: reducing PHP time from 800 ms to 200 ms helps, but putting a cached response on the edge node closest to your visitor means that PHP time is no longer in the critical path for the majority of your traffic at all. Work through the stages methodically, measure at every step, and you will find that single-digit-tens-of-milliseconds TTFB is not a marketing claim. It is a predictable outcome of getting the pipeline right.