How to reduce TTFB in WordPress
To reduce TTFB in WordPress, serve pages from a full-page cache, then speed up the pages that cannot be cached with a persistent object cache, a current PHP version and fewer slow plugins. Measure before and after each change, logged out, so you know which one helped. Google's web.dev guidance treats a time to first byte of 0.8 seconds or less as good.
TTFB is how long the browser waits for the first byte of the HTML. Nothing else on the page can start until it arrives, so a slow TTFB delays Largest Contentful Paint and everything else. The causes are explained on slow server response time; this guide is the order of fixes.
Step by step
1. Measure TTFB properly
Test logged out, because logged-in requests skip most caches. From a terminal:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com/
Run it three or four times and ignore the first. In Chrome, open developer tools, go to Network, reload, click the document request and read Waiting for server response in the Timing tab. Test your homepage, a post, and, on a store, a product page.
2. Compare cached and uncached pages
Add a random query string, such as ?nocache=123, to bypass many page caches, and measure again. If the cached page is fast and the uncached one is slow, your cache is working and the problem is what happens inside WordPress. If both are slow, caching is off or the server itself is far away or overloaded.
3. Turn on full-page caching
Full-page caching serves ready-made HTML without running PHP or database queries. Many hosts include it at the server level; check your hosting panel first, because a caching plugin on top of host caching adds little. Otherwise, install one caching plugin. After enabling it, a cached page should come back in a fraction of the uncached time.
4. Add a persistent object cache
Some pages can never be fully cached: logged-in views, WooCommerce carts and checkout, and anything that varies by cookie. A persistent object cache, usually Redis or Memcached, keeps database query results in memory between requests. Most managed hosts offer one as a switch; you then need the matching drop-in or plugin that the host recommends.
5. Update PHP
Newer PHP versions run WordPress noticeably faster than old ones. Tools → Site Health shows your current version. Switch to the newest version your host supports that your plugins and theme are compatible with, on staging first.
6. Find slow plugins and queries
Install the Query Monitor plugin on staging and load a slow uncached page. It lists the slowest database queries, external HTTP calls made while the page renders, and which plugin caused each. Deactivate suspects one at a time and remeasure. SEO plugins add PHP work on every uncached request too; our SEO plugin benchmark measured how much each one adds.
7. Trim autoloaded options
WordPress loads every autoloaded option on every request. Plugins you removed years ago may have left large ones behind. Check the total with WP-CLI:
wp option list --autoload=on --format=total_bytes
If it runs into megabytes, list the largest options and remove the ones left by plugins you no longer use, after a backup.
8. Put a CDN in front of distant visitors
If your server is in one country and visitors are in another, distance alone adds delay. A CDN that caches full HTML pages at the edge serves them from a location close to each visitor. Caching only images and CSS at the CDN does not help TTFB for the HTML itself.
Check it worked
Rerun the same curl command on the same pages and compare. Field data takes longer: the Core Web Vitals report in Search Console and PageSpeed Insights both use real-user data collected over the previous 28 days, so give them a few weeks. The next step after TTFB is the rest of the page; see improve Core Web Vitals.
When the host is the limit
If a cached page still takes more than a second, or TTFB swings wildly between requests, the server is likely underpowered or overloaded, which is common on cheap shared plans. No plugin fixes that. Moving to a better plan or host is often the single biggest improvement available.
Common questions
What is a good TTFB for WordPress?
Google's web.dev guidance treats 0.8 seconds or less as good. A well-cached WordPress page is usually far below that.
Why is my TTFB slow only when I am logged in?
Logged-in requests usually bypass the page cache, so WordPress builds every page from scratch. Measure logged out to see what visitors and Google get.
Does TTFB affect rankings?
TTFB is not a Core Web Vital itself, but it delays Largest Contentful Paint, which is. A slow server can also slow down how fast Google crawls large sites.