Why Is My WordPress TTFB So Slow?

Time to First Byte measures the delay between a browser requesting a page and the server sending back the first byte of the response. It happens before the browser has rendered a single pixel, which makes it easy to overlook when you are staring at a slow-loading page and blaming images or JavaScript. On WordPress specifically, a high TTFB almost always means the server is spending too long generating the page before it can even start sending it.

This matters beyond the raw feeling of sluggishness. TTFB is one of the inputs Google uses when calculating Largest Contentful Paint, and a slow backend response delays everything downstream: CSS, JavaScript, and images cannot start loading until the HTML that references them has arrived. A site with a 1.8 second TTFB is already behind before the browser has done any rendering work at all.

What TTFB Actually Measures

TTFB is the sum of DNS lookup, connection setup, TLS handshake, and server processing time. For a WordPress site, the first three are largely settled once you have chosen a server location close to your visitors and the server supports HTTP/2 or HTTP/3. The fourth part, server processing time, is where WordPress does its real work: bootstrapping WordPress core, loading every active plugin, running the theme's template logic, and querying the database for the content, menus, and widgets that make up the page.

That processing step is why TTFB is really a proxy for backend health. A shared hosting account with fifty neighbouring sites competing for the same CPU cores will show a TTFB that swings depending on what else is happening on the server at that moment, regardless of how lean your own WordPress install is.

Where WordPress Spends the Time

Every uncached WordPress request runs through the same rough sequence: PHP is invoked, wp-config.php loads, WordPress core initialises, every active plugin runs its bootstrap code, and the theme executes template functions that typically trigger multiple database queries for post content, menus, widgets, and options. A default WordPress install with a handful of plugins can execute 20 to 40 database queries per page load. A bloated install with a page builder and a dozen marketing plugins can run into the hundreds.

PHP execution speed itself varies enormously with configuration. An outdated PHP version, a PHP-FPM pool sized incorrectly for the server's RAM, or a missing OPcache configuration all add real, measurable milliseconds to every single request. None of this is visible from the WordPress admin; it only shows up when you measure server response time directly.

Measuring TTFB Correctly

Browser DevTools shows TTFB under the Network tab as the gap between a request starting and the first byte of the response arriving, but it includes DNS and connection time mixed in with server processing, which makes it noisy for a single measurement. A cleaner way to isolate server processing time is curl from a machine outside the hosting network:

curl -o /dev/null -s -w 'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' https://example.com/

Run it several times and look at time_starttransfer specifically. Anything under 200ms on a cached page is good. 200ms to 600ms on an uncached request is typical for a reasonably tuned WordPress install. Anything consistently above 1 second on a normal page, with no unusual traffic spike, points to a backend problem worth investigating rather than a one-off blip.

Fixing a Slow TTFB

Page caching is the single biggest lever available, because it removes PHP and MySQL from the request entirely for anonymous visitors. Instead of WordPress rebuilding a page from scratch on every hit, a full page cache like the one built into Nginx with fastcgi_cache, or a plugin-based cache such as WP Rocket or LiteSpeed Cache, serves a static HTML file straight from disk or memory. This is the difference between a 900ms uncached response and a 40ms cached one. The full breakdown of how page, object, and browser caching work together is covered in the site's guide to WordPress caching.

For the requests that do have to hit PHP, whether that is a logged-in user, a WooCommerce cart page, or a cache miss, OPcache and correctly sized PHP-FPM pools matter enormously. OPcache stores compiled PHP bytecode in memory so PHP does not recompile every file on every request, and a PHP-FPM pool sized for the server's actual RAM avoids requests queueing up behind pm.max_children limits that are too conservative or too aggressive. The site's guide to tuning PHP-FPM and OPcache for WordPress on a VPS walks through calculating both correctly.

Database query time is the other major contributor once caching is in place, since logged-in and dynamic requests still hit MySQL or MariaDB directly. An object cache, most commonly Redis, stores the results of repeated database queries in memory so WordPress does not re-run the same query on every request. Setting one up is covered in the guide to Redis object caching in WordPress. On top of that, plugin audits matter more than most site owners expect; a single poorly written plugin running an unindexed query on every page load can add hundreds of milliseconds by itself, independent of hosting quality.

Finally, the hosting environment sets the ceiling everything else operates under. Shared hosting with oversold CPU allocation, spinning disks instead of NVMe storage, or PHP versions several releases behind current all inflate TTFB regardless of how well WordPress itself is configured. A technical breakdown of what separates fast WordPress hosting from slow hosting covers server-side factors in more depth, and for a site that has outgrown shared hosting entirely, moving to a VPS removes the noisy-neighbour problem at its root.

Frequently Asked Questions

What is a good TTFB for WordPress?

Under 200ms for a cached page and under 600ms for an uncached one is a reasonable target for a well-configured WordPress install. Google's Core Web Vitals guidance flags TTFB above 600ms as needing improvement and above 1.8 seconds as poor, and those thresholds are a fair benchmark to hold WordPress hosting to as well.

Does a CDN fix TTFB?

A CDN only helps TTFB for content it can serve directly from its edge cache, such as static assets or fully cached HTML pages. For any request that still has to reach the origin server, whether that is a logged-in session or a cache miss, a CDN adds a network hop rather than removing one. It is a complement to server-side fixes, not a substitute for them.

Can too many plugins cause a slow TTFB?

Yes, directly. Every active plugin runs its initialisation code on every uncached request, and plugins that query the database outside of WordPress's built-in caching mechanisms add real time on top of that. Deactivating unused plugins and auditing the remaining ones for database-heavy behaviour is one of the more effective free changes available.