How to Fix High TTFB in WordPress (2026 Guide)

Learning how to fix high TTFB in WordPress is one of the highest-impact performance improvements you can make. High TTFB is the WordPress performance problem that hurts most and gets fixed least. It's the one metric that no amount of image compression, JavaScript deferral, or CDN configuration can fully compensate for. If your server takes 1.5 seconds to respond before the browser even starts loading your page, you're starting 1.5 seconds behind on every visitor interaction.

Google calls it "Server response time" in PageSpeed Insights. Core Web Vitals labels it as a contributor to poor LCP. Whatever you call it, a TTFB above 600ms is a problem worth fixing properly.

Quick Answer: High TTFB in WordPress almost always means the server does too much work per request. Fix it by enabling full-page caching (so PHP and MySQL are skipped on most hits), adding a CDN, running PHP 8.3 with OPcache, and moving to NVMe hosting with enough RAM. Aim for a TTFB under 200ms; anything consistently above 600ms is a hosting or caching problem, not your theme.

What is TTFB and why does it matter?

TTFB (Time to First Byte) measures the time from when the browser sends a request to when it receives the first byte of the server's response. It's entirely server-side — the browser is waiting, not loading — so your host sets the floor for how low it can go, which is why a tuned stack like Hostaccent's keeps the baseline down before you optimize anything else.

TTFB benchmarks:

• Under 200ms: Excellent
• 200–600ms: Acceptable
• 600ms–1s: Needs improvement
• Above 1s: Significant problem

Google's threshold for a "good" server response time is under 600ms. Above that, it's flagged in PageSpeed Insights and contributes to a poor LCP score.

TTFB directly affects your Core Web Vitals score, which directly affects your Google search ranking. It also affects bounce rate — users on mobile or slower connections abandon pages that take too long to start loading.

Measure your current TTFB

Before fixing anything, get a baseline:

bashCopy
# Run 5 times and average
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yourdomain.com

Also check using PageSpeed Insights: the "Server response time" card tells you the measured TTFB and whether it's flagged.

Note two things: TTFB on cached pages (logged-out visitor, homepage) and TTFB on uncached pages (logged-in user, unique product pages). Cached pages should be under 200ms. Uncached pages under 600ms.

Fix 1: Enable full-page caching (biggest impact)

If you're not serving cached HTML to anonymous visitors, every page load runs PHP, queries MySQL, and assembles a full HTML response. This takes 300ms–2s+ depending on your server and WordPress complexity.

Full-page cache skips this entirely for logged-out visitors — serving pre-built HTML from disk or memory in under 50ms.

Install WP Rocket, LiteSpeed Cache, or W3 Total Cache. Enable page caching. Then verify it's working:

bashCopy
curl -I https://yourdomain.com | grep -i cache

Look for X-Cache: HIT or X-LiteSpeed-Cache: hit. If you see MISS every time, caching is enabled but not serving. Check your plugin's exclusion settings.

Nginx FastCGI cache (on VPS) is the most aggressive option — serves cache at the Nginx level before PHP runs:

nginxCopy
fastcgi_cache_path /tmp/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

This can bring cached TTFB to 20–80ms.

Fix 2: Enable OPcache

OPcache caches compiled PHP bytecode in memory. WordPress has ~1,000 PHP files. Without OPcache, they recompile on every request. With it, subsequent requests skip compilation entirely.

Check if OPcache is enabled:

bashCopy
php -i | grep "opcache.enable"

Should return opcache.enable => On => On.

Enable in /etc/php/8.3/fpm/php.ini (VPS):

iniCopy
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60

bashCopy
sudo systemctl restart php8.3-fpm

On shared hosting: contact support and ask if OPcache is enabled. Any modern host should have this on by default. If they won't enable it, that's a red flag.

Typical impact: 20–40% reduction in PHP execution time.

Fix 3: Add Redis object caching

WordPress queries the database on every page load for things like site options, menus, and post metadata — even when the data hasn't changed. Redis caches these objects in memory so database queries run once and are then served from memory.

Install and enable Redis (VPS - Ubuntu):

bashCopy
sudo apt install redis-server php8.3-redis -y
sudo systemctl enable --now redis-server

Install the Redis Object Cache plugin in WordPress. Click "Enable Object Cache."

Verify it's working:

bashCopy
redis-cli monitor
# Then reload a WordPress page in another terminal
# You should see Redis commands appearing

Typical impact: 40–70% reduction in database queries per page load.

Fix 4: Tune PHP-FPM worker count

PHP-FPM manages the PHP processes that handle requests. Too few workers means requests queue up and wait. When requests wait, TTFB rises for those users.

Check current workers:

bashCopy
sudo systemctl status php8.3-fpm
ps aux | grep php-fpm | wc -l

Tune /etc/php/8.3/fpm/pool.d/www.conf:

iniCopy
pm = dynamic
pm.max_children = 20      # RAM / ~80MB per worker
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

On a 4GB VPS with 2GB allocated to PHP: max_children of 20–25 is reasonable. Don't set it higher than your RAM supports — PHP workers that can't get RAM cause worse problems than a smaller pool.

Fix 5: Optimize MySQL configuration

Default MySQL settings are conservative. Tuning the InnoDB buffer pool (which caches database tables in memory) significantly reduces disk I/O for database reads.

Check current buffer pool:

bashCopy
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Edit /etc/mysql/mysql.conf.d/mysqld.cnf:

iniCopy
innodb_buffer_pool_size = 1G    # For 4GB VPS dedicated to WordPress
innodb_log_file_size = 256M
max_connections = 100

bashCopy
sudo systemctl restart mysql

For shared hosting: you can't tune MySQL configuration. This fix requires VPS.

Fix 6: Upgrade PHP version

PHP 8.3 is meaningfully faster than PHP 7.4. If you're still on PHP 7.x, upgrading alone can cut PHP execution time by 20–40%.

Check your PHP version: WordPress Admin → Tools → Site Health → Info → Server → PHP version

Change in cPanel: Software → Select PHP Version → Choose 8.2 or 8.3.

Always test on staging first. Some older plugins have PHP 8.x compatibility issues. Test key pages and especially checkout/forms after upgrading.

Fix 7: Investigate the problem with Query Monitor

If none of the above fixes bring TTFB under 600ms, install Query Monitor plugin. It shows:

• Every database query per page load
• Which plugin or theme generated each query
• Queries above 100ms flagged in red
• Total query count and total query time

A page with 200+ queries or a single query taking 500ms points directly to the fix needed.

Fix 8: Accept that the server is the bottleneck

If you've done all of the above and TTFB is still above 800ms on cached pages, the server hardware or network is the constraint. This happens on:

• Overloaded shared hosting where other accounts consume resources
• Undersized VPS with too little RAM causing swap usage
• Geographically distant server (your users are in Europe, your server is in California)

These are not fixable with WordPress configuration. They require:

• Moving to VPS (from shared hosting)
• Upgrading VPS plan (RAM, CPU)
• Choosing a server location closer to your audience

TTFB targets to aim for

| Page type | Target TTFB | How to achieve | |-----------|------------|----------------| | Cached (logged-out) | Under 200ms | Nginx FastCGI cache or WP Rocket | | Uncached (logged-in) | Under 600ms | OPcache + Redis + tuned PHP-FPM | | WooCommerce checkout | Under 800ms | All of above + MySQL tuning |

If you're hitting these targets, your server response time isn't your performance problem — look at images, JavaScript, and fonts instead.

Consistently high TTFB despite caching and optimization? That's a hosting problem, not a WordPress problem. HostAccent VPS with NVMe storage, PHP 8.3, and Redis gives you the server-side baseline that makes these targets achievable.

Related guides from HostAccent

• WordPress Site Slow: Complete Diagnosis and Fix Guide (2026)
• Core Web Vitals Failing? Your Hosting Might Be the Problem
• Nginx + PHP-FPM Performance Tuning on Linux VPS
• WordPress Speed Optimization: Hosting-Layer Fixes
• Best VPS for WordPress in 2026: Specs That Actually Matter