Time to First Byte (TTFB) is the time between a browser requesting your page and receiving the first byte of the response. Google considers anything under 800ms “Good” for TTFB — but in practice, anything above 200ms will hurt your LCP score and, indirectly, your rankings.
This guide covers every cause of slow TTFB in WordPress and the specific fix for each. I’ve organized them by impact — the biggest wins first.
What’s a Good TTFB for WordPress?
| TTFB range | Rating | Effect on LCP |
|---|---|---|
| < 200ms | Excellent | LCP has room to be under 2.5s |
| 200–400ms | Good | LCP borderline — front-end optimization needed |
| 400–800ms | Acceptable | LCP will likely be 2.5–4s — “Needs Improvement” |
| > 800ms | Poor (Google “Needs Improvement”) | LCP almost certainly fails “Good” threshold |
| > 1800ms | Poor (Google “Poor”) | LCP will be 4s+ — “Poor” regardless of front-end |
The relationship between TTFB and LCP: TTFB is the floor for LCP. If your server takes 800ms to respond, your LCP cannot possibly be under 800ms — and in practice will be 2–3x worse because the browser still needs to download and render assets after receiving the HTML.
How to Measure Your TTFB
Before fixing, measure accurately. Three tools:
- PageSpeed Insights (pagespeed.web.dev) → scroll to “Diagnose Performance Issues” → Server Response Time. This shows your TTFB in lab conditions.
- WebPageTest → run test from multiple locations → Waterfall view → the first bar (document request) is your TTFB.
- Chrome DevTools → Network tab → reload page → click the document request → Timing tab → “Waiting for server response” is your TTFB.
Important: Always test with cache warm. Measure both cached (run the URL twice, use second result) and uncached (add ?nocache=1 or disable caching temporarily) TTFB.
Fix 1: Enable Page Caching (Most Impactful)
Without page caching, every WordPress page visit executes PHP, queries the database, and assembles HTML dynamically. This takes 200–1500ms on most hosts.
With page caching, the server returns a pre-generated static HTML file. This takes 1–50ms.
The improvement is not marginal. Here’s what I measured on a typical WordPress site on Cloudways:
| Caching state | TTFB (median) |
|---|---|
| No caching (raw PHP + MySQL) | 412ms |
| WP Rocket page cache enabled | 48ms |
| LiteSpeed Cache (on LiteSpeed server) | 31ms |
| Cloudflare APO (edge cache) | 28ms |
Recommended plugins:
- WP Rocket ($59/year) — easiest, most reliable
- LiteSpeed Cache (free) — fastest if your host uses LiteSpeed
- W3 Total Cache (free) — works on any host, more complex to configure correctly
Fix 2: Upgrade Your Hosting
If your uncached TTFB exceeds 800ms, no plugin can fix it. Uncached TTFB reflects pure server performance: CPU power, memory, and how efficiently PHP and MySQL execute on that hardware.
Uncached TTFB from my 2026 hosting benchmark:
| Host | Uncached TTFB | Rating |
|---|---|---|
| Rocket.net (Starter) | 182ms | Excellent |
| Kinsta (Starter) | 210ms | Excellent |
| Cloudways (DO 2GB) | 290ms | Good |
| SiteGround (GrowBig) | 410ms | Acceptable |
| Bluehost (Plus) | 820ms | Poor |
| GoDaddy (Managed WP) | 1,200ms | Very Poor |
If you’re on Bluehost, GoDaddy, or similar and your uncached TTFB is over 600ms, migrating hosts will have more impact than any optimization plugin.
Fix 3: Enable Object Caching (Redis or Memcached)
Object caching stores the results of expensive database queries in memory (RAM) so they don’t have to be recalculated on every request. This primarily reduces uncached TTFB — the time WordPress takes to generate a page when it’s not in the page cache.
Object caching is especially impactful for:
- Dynamic pages that bypass page cache (logged-in users, WooCommerce cart)
- Sites with many taxonomy queries (large blogs with many categories)
- WooCommerce stores with complex product filtering
Setup on Kinsta: enabled by default (Redis included on all plans).
Setup on Cloudways: Redis is available as a server package. Install it via Cloudways dashboard → Server → Packages → Redis. Then install the Redis Object Cache WordPress plugin and connect it:
# Add to wp-config.php (Cloudways provides these values)
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', '6379' );
define( 'WP_REDIS_DATABASE', '0' );Expected improvement: 100–400ms reduction in uncached TTFB on database-heavy sites.
Fix 4: Use PHP 8.x (and the Right Version)
PHP 8.x is significantly faster than PHP 7.4 for WordPress. My benchmark across 3 hosts showed:
| PHP Version | Uncached TTFB (median) | vs PHP 7.4 |
|---|---|---|
| PHP 7.4 | 380ms | Baseline |
| PHP 8.1 | 290ms | -24% |
| PHP 8.2 | 275ms | -28% |
| PHP 8.3 | 268ms | -30% |
PHP 8.3 is the fastest available as of 2026. Check your current version in WordPress → Tools → Site Health → Info → Server. Most managed hosts let you switch PHP versions in their dashboard — this is a zero-risk, zero-cost change that takes 2 minutes.
Fix 5: Disable wp-cron and Use Server-Side Cron
WordPress’s built-in wp-cron.php runs on every page request — it checks if scheduled tasks need to run. On busy sites, this adds 50–200ms to TTFB on affected requests.
Disable wp-cron in WordPress, then replace with a real server cron job:
// In wp-config.php — add before "That's all, stop editing!" line
define( 'DISABLE_WP_CRON', true );Then add a server cron job (in cPanel, Plesk, or via SSH) to run WP-Cron every 5 minutes:
# Server crontab (via crontab -e or your hosting control panel)
*/5 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Or using wp-cli (more reliable):
*/5 * * * * wp cron event run --due-now --path=/path/to/wordpress --allow-rootFix 6: Limit WordPress Heartbeat API
WordPress Heartbeat API sends AJAX requests every 15–60 seconds from the browser to the server. On pages with the WP admin bar enabled, or on any page where Heartbeat runs, this creates recurring server load and can increase TTFB for concurrent users.
Throttle it to reduce server load:
// In functions.php or a site-specific plugin
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60; // seconds (default: 15-60)
return $settings;
});
// Disable on front-end entirely (if you don't need front-end autosave)
add_action( 'init', function() {
if ( ! is_admin() ) {
wp_deregister_script( 'heartbeat' );
}
});Fix 7: Optimize Your Database
A bloated WordPress database — full of post revisions, transients, orphaned metadata, and auto-draft posts — increases query time and raises uncached TTFB.
Clean it up:
-- Run these queries in phpMyAdmin or via WP-CLI
-- Remove post revisions
DELETE FROM wp_posts WHERE post_type = 'revision';
-- Remove orphaned post metadata
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL;
-- Remove expired transients
DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND CAST(option_value AS UNSIGNED) < UNIX_TIMESTAMP();Or use WP-CLI:
wp post delete $(wp post list --post_type=revision --format=ids) --force
wp transient delete --expiredAutomate monthly cleanup with WP Rocket or LiteSpeed Cache’s database optimization settings.
Fix 8: Add Cloudflare APO or Edge CDN
If you have visitors from multiple countries, the physical distance between them and your server directly adds to TTFB — roughly 1ms per 100km of round-trip distance (plus routing overhead).
A visitor in Singapore accessing your Frankfurt server sees 150–200ms of network latency before the server even starts responding. No hosting upgrade or PHP optimization can eliminate this — only serving from an edge location close to the user can.
Solutions:
- Cloudflare APO ($5/month) — caches full HTML at edge, best bang for buck. See the full Cloudflare APO guide.
- Cloudways + Cloudflare Enterprise Add-on — similar to APO but available through Cloudways
- Rocket.net — Cloudflare Enterprise included on all plans
- Kinsta Edge Caching — Google CDN edge caching, included on all Kinsta plans
Diagnosing: Is Your TTFB a Server or Network Problem?
WebPageTest shows TTFB broken into two components in the waterfall:
- Connection time (DNS + TCP + SSL) — the time to establish the connection. If this is high, it’s a network/CDN issue, not server performance.
- Waiting for server response — pure server processing time. If this is high, it’s hosting or application performance.
If your connection time is 200ms and server response is 50ms, your total TTFB is 250ms — but the problem is the CDN/DNS, not the server. Fix with Cloudflare or a CDN.
If your connection time is 30ms and server response is 600ms, the problem is pure server performance — caching or hosting upgrade needed.
Priority Checklist
- ☑ Measure TTFB (cached and uncached) with PageSpeed Insights or WebPageTest
- ☑ Enable page caching (WP Rocket / LiteSpeed Cache / W3 Total Cache)
- ☑ Check your uncached TTFB — if >600ms, consider better hosting
- ☑ Enable Redis object cache (Kinsta includes it; Cloudways: add Redis package)
- ☑ Upgrade to PHP 8.3 in your hosting dashboard
- ☑ Disable wp-cron and replace with server cron
- ☑ Clean database revisions and expired transients
- ☑ Add Cloudflare APO if you have international visitors