Time to First Byte (TTFB) is the time from when a browser sends a request to when it receives the first byte of your server's response. Google recommends under 800ms; the real target for competitive performance is under 200ms. TTFB is the foundational metric, nothing else can load before the HTML starts arriving, so a high TTFB drags down every other performance measurement including Largest Contentful Paint.
TTFB captures everything that happens on the server side before the first byte of response arrives at the browser. That includes DNS resolution, TCP connection setup, TLS handshake, and then your server's processing time: PHP bootstrap, WordPress core loading, plugin initialization, database queries, template rendering, and response assembly.
For a cached page on LiteSpeed with LSCache active, TTFB can be under 30ms, the server returns a pre-built HTML file before PHP even loads. For an uncached dynamic page on a shared server with 30 active plugins, TTFB can exceed 2 seconds. The gap is enormous and the cause is the same in both cases: how much work the server does before sending the first byte.
You can measure TTFB precisely in Chrome DevTools (Network tab, hover over any request and look at the TTFB row in the timing breakdown) or in PageSpeed Insights under "Reduce initial server response time."
Server-side page caching eliminates PHP execution for cached pages entirely. When LiteSpeed Cache is active and a page has been cached, the web server returns the stored HTML file without invoking PHP, the WordPress bootstrap, or the database. TTFB drops from several hundred milliseconds to under 50ms.
This is the largest single improvement available for most WordPress sites, and it's not close. All other TTFB optimizations are refinements on a baseline that caching sets in seconds. If you're not caching and your TTFB is 800ms, enabling LiteSpeed Cache will very likely drop it to under 50ms before you change anything else.
If your host doesn't run LiteSpeed, WP Super Cache and WP Rocket both generate static HTML files that Apache can serve with minimal PHP involvement. The result isn't quite as fast as true server-level caching (PHP still loads briefly to check whether the cache is valid) but produces a significant improvement over uncached dynamic generation.
Not every request can be served from cache. Logged-in users bypass the page cache. WooCommerce cart and checkout pages are excluded from caching because they're session-specific. Search results and filtered product listings often can't be cached either. For these requests, PHP execution time is the primary TTFB driver.
The factors that determine PHP execution time for uncached WordPress pages:
Number of active plugins. Every active plugin's main file is loaded on every request. A plugin that registers three shortcodes you never use still adds PHP overhead on every page. Audit your plugin list and remove anything that isn't actively contributing to a page. The difference between 10 active plugins and 35 active plugins is measurable in TTFB on every uncached request.
PHP version. PHP 8.x is meaningfully faster than PHP 7.4 for WordPress workloads, roughly 20–30% faster on typical WordPress request processing. If you're still running PHP 7.4 because you haven't tested plugin compatibility with 8.x, that's worth doing. Most maintained plugins have been compatible with PHP 8.1 for years.
OPcache configuration. PHP OPcache stores compiled bytecode in memory so PHP skips the compilation step on subsequent requests. It's enabled by default on modern PHP installations. Verify it's active and that opcache.memory_consumption is set high enough for your codebase (128MB is appropriate for most WordPress sites with typical plugin sets).
Slow database queries are a common TTFB bottleneck on larger or older sites. WordPress's database abstraction layer runs queries synchronously, the page generation process pauses while waiting for each query to return. A page with 15 queries averaging 30ms each spends 450ms just waiting for the database, before PHP does any other processing.
Install the Query Monitor plugin and load a representative page. The Database Queries panel shows every query executed, its execution time in milliseconds, and which plugin or theme triggered it. Look for:
For queries that are slow due to missing indexes, you may need to add them manually via phpMyAdmin or wp-config-based database access. For excessive query counts from a specific plugin, contact the plugin author or find a replacement that queries more efficiently.
Redis stores the results of database queries in memory so they don't hit the database on subsequent requests within the cache lifetime. For dynamic pages that can't be fully page-cached, logged-in users, WooCommerce sessions, member content, Redis is the most effective tool for reducing database-driven TTFB.
Once the Redis Object Cache plugin is connected to a Redis instance, WordPress automatically uses it for all object cache reads and writes. The first request for a given data set hits the database; subsequent requests read from Redis memory. On sites with heavy database activity, Redis can reduce database query time by 60–80% for cached data sets, which translates directly to lower TTFB on dynamic pages.
TTFB as measured by browser tools includes DNS resolution time and TCP/TLS handshake time, these happen before your server processes anything. If your DNS TTL is set very low (under 300 seconds), visitors may be doing fresh DNS lookups frequently, adding 20–100ms before the request even reaches your server. Set your DNS TTL to 3600 seconds (1 hour) for production sites.
TLS handshake time depends on your SSL configuration. HTTP/2 requires TLS, but a site running HTTP/2 with TLS 1.3 has a shorter handshake than one running HTTP/1.1 with TLS 1.2. Verify your server supports TLS 1.3 and that your SSL certificate is using ECDSA rather than RSA for faster handshakes.
Beyond optimization, TTFB has a floor set by your hosting infrastructure. Shared servers with overcommitted CPU and RAM, no server-level caching, and throttled PHP execution have a structural disadvantage that no amount of code optimization overcomes. If your TTFB is consistently above 500ms after enabling caching and addressing obvious query issues, the hosting tier is the limiting factor.
Migrating to a LiteSpeed host with dedicated resources and LSCache is often the single most impactful change available, more impactful than any combination of plugin and code optimizations on inferior infrastructure.
HostBible WordPress hosting runs LiteSpeed with LSCache active. Cached pages respond before PHP executes, that's the foundation every other optimisation builds on.
View Hosting Plans