How to Fix Slow TTFB (Time to First Byte)

If your website feels sluggish even before a single image loads, the culprit is almost always a slow TTFB. Learning to fix slow TTFB is one of the highest-leverage performance improvements you can make — because every millisecond of server delay pushes back every other resource on the page. Nothing renders until that first byte arrives.

In this guide you will learn exactly what TTFB measures, how to diagnose it accurately, and six concrete fixes — with real configuration examples for nginx, Redis, PHP, and WordPress — that can drop your server response time from over a second to under 400ms.

Not sure how bad your TTFB is? Run a free WebsiteLinter scan — it measures server response time and identifies the root causes dragging down your score.

What Is TTFB and What Counts as Too Slow?

Time to First Byte measures the elapsed time between the moment a browser sends an HTTP request and the moment it receives the very first byte of the response from the server. It is not just "how fast is the server" — TTFB is the sum of several sequential steps that all must complete before any content can transfer:

• DNS lookup: Resolving your domain name to an IP address (typically 10–100ms depending on your DNS provider)
• TCP handshake: Establishing the connection between browser and server (one round trip)
• SSL/TLS negotiation: Completing the TLS handshake for HTTPS connections (one to two additional round trips)
• Server processing time: The time your application needs to generate the response — database queries, PHP execution, template rendering
• Network transit: The time for that first byte to travel back across the wire to the browser

Google's Core Web Vitals thresholds for TTFB (updated in 2023) classify server response as follows:

Rating	TTFB Range	PageSpeed Score Impact
Good	Under 800ms	No penalty
Needs Improvement	800ms – 1,800ms	Moderate penalty
Poor	Over 1,800ms	Significant penalty

Note: the old 200ms benchmark you may have seen in developer tool documentation was a lab-only target for server processing time in isolation — it did not include DNS, TCP, or TLS overhead. The current CWV thresholds of 800ms/1,800ms are the field-data standards that affect your PageSpeed and Search Console scores.

Why does TTFB matter so much? Because it is the single gating event for all other loading. LCP (Largest Contentful Paint), FCP (First Contentful Paint), and every JavaScript and CSS resource all wait behind it. A 1,500ms TTFB alone guarantees a failing LCP score. If you are working to fix your LCP (Largest Contentful Paint), reducing TTFB is the first place to start — it has a 1:1 payoff because LCP cannot begin until the first byte lands.

How to Measure Your TTFB Accurately

Accurate measurement requires eliminating two variables that routinely give misleading readings: browser cache and geographic proximity. Here is how to get clean, reproducible numbers.

Chrome DevTools — Network Waterfall

Open DevTools (F12), go to the Network tab, check Disable cache in the toolbar, then reload the page. Click on the first HTML document request. In the Timing panel on the right, look for the "Waiting (TTFB)" row — that is your server response time stripped of everything but the server-side processing and network latency from your location.

PageSpeed Insights

PageSpeed Insights reports TTFB under the "Server Response Times (TTFB)" diagnostic in the Opportunities section. This uses Lighthouse lab data from Google's servers in a specific location, so it is comparable across runs but does not reflect real-user geography.

WebPageTest.org

WebPageTest is the most reliable option for location-specific testing. Run tests from three different cities — for example, Ashburn VA (US East), London (EU), and Tokyo (Asia-Pacific). This tells you whether your TTFB problem is consistent worldwide (a server-side issue) or only affects distant users (a CDN gap). Always run at least three tests per location and average the results to smooth out network jitter.

Key rule: always measure from a fresh connection with cache disabled. A warm-cache TTFB from your office location looks great but tells you nothing about what a new visitor in another city actually experiences.

Not sure how bad your TTFB is? Run a free WebsiteLinter scan — it measures server response time and identifies the root causes dragging down your score.

Fix 1 — Enable Server-Side Page Caching to Fix Slow TTFB

The single most impactful change for most WordPress sites is enabling full-page caching. Without it, every request triggers a full PHP execution cycle: WordPress bootstraps, queries the database for the post content, runs through the theme template, and assembles the HTML — typically taking 300ms to 1,500ms depending on your hosting. With page caching, the second request for any URL is served from a pre-built HTML file in microseconds, completely bypassing PHP and the database.

WordPress Caching Plugins

• WP Rocket (premium, ~$59/year) — the most complete solution; handles page cache, browser cache headers, database cleanup, and CDN integration from a single dashboard
• WP Super Cache (free) — mature, reliable, generates static HTML files; good for simple sites without e-commerce
• LiteSpeed Cache (free, requires LiteSpeed web server) — server-level caching that is even faster than plugin-based solutions; included by default on Hostinger and some VPS stacks

nginx FastCGI Cache — Direct Server Configuration

If you manage your own VPS with nginx and PHP-FPM, server-level FastCGI caching gives you the best possible performance. Add the following to your nginx configuration:

# In /etc/nginx/nginx.conf or a separate cache config file
fastcgi_cache_path /var/cache/nginx/lws levels=1:2
    keys_zone=WORDPRESS:100m
    inactive=60m
    max_size=1g;

fastcgi_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache $upstream_cache_status;

# In your server block (e.g. /etc/nginx/sites-available/yoursite.conf)
set $skip_cache 0;

# Do NOT cache for logged-in users
if ($http_cookie ~* "wordpress_logged_in") {
    set $skip_cache 1;
}

# Do NOT cache POST requests
if ($request_method = POST) {
    set $skip_cache 1;
}

# Do NOT cache WooCommerce cart/checkout/account pages
if ($request_uri ~* "/cart/|/checkout/|/my-account/") {
    set $skip_cache 1;
}

# Do NOT cache query strings (search results, pagination with params)
if ($query_string) {
    set $skip_cache 1;
}

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;

    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 60m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
}

After reloading nginx, check the X-Cache response header — a value of HIT confirms the cache is serving the response. Your TTFB on cached pages should drop to under 50ms.

Fix 2 — Enable Object Caching with Redis

Page caching handles the most common case, but some pages cannot be fully cached: WooCommerce cart pages, members-only content, and highly personalized views all bypass the full-page cache. For those pages, and to speed up the uncached first-render of any page, object caching with Redis eliminates repeated expensive database queries.

Redis stores the results of WordPress database queries in RAM. The next time WordPress needs the same data — a list of recent posts, user metadata, widget configuration — it reads from memory instead of running a MySQL query. On a typical WordPress site, this alone reduces server processing time by 30–50%.

Installing Redis Object Cache for WordPress

First, ensure Redis is installed on your server:

sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server

Then install the Redis Object Cache plugin (by Till Krüss — free, over 1 million active installs) from the WordPress plugin directory. After activation, add the connection constants to your wp-config.php before the /* That's all, stop editing! */ line:

// Redis Object Cache configuration
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_CACHE', true);

Verify the connection using WP-CLI:

wp redis status

You should see Status: Connected and a hit/miss ratio once traffic starts flowing. After a warm-up period, expect cache hit rates of 70–90% for a typical WordPress blog.

Fix 3 — Upgrade PHP Version and Enable OPcache

This is one of the most frequently overlooked quick wins. PHP version alone has a dramatic impact on WordPress execution speed. PHP 8.2 processes WordPress requests approximately three times faster than PHP 7.4 in real-world benchmarks — and many shared-hosting accounts default to PHP 7.4 or even older versions.

To check your current PHP version, add <?php phpinfo(); ?> to a temporary file in your web root, or run php -v on the command line. Upgrade to PHP 8.2 (or 8.3) via your hosting control panel — most modern hosts (SiteGround, Cloudways, Kinsta, RunCloud) support switching PHP versions with a single click.

OPcache Configuration

OPcache stores compiled PHP bytecode in memory, eliminating the parse and compile step that happens on every request without it. It is included with PHP but often not fully configured. Add or update these settings in your php.ini (or a opcache.ini override file):

; OPcache configuration for WordPress on PHP 8.2
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.fast_shutdown=1

; JIT compilation — PHP 8.1+ only (significant boost for CPU-heavy workloads)
opcache.jit=1255
opcache.jit_buffer_size=100M

After updating, restart PHP-FPM (sudo systemctl restart php8.2-fpm). The memory_consumption=256 setting allocates 256MB of shared memory for the bytecode cache — if you have many plugins, this is not excessive. The JIT settings (opcache.jit=1255) enable the just-in-time compiler introduced in PHP 8.0, which provides additional speed for computation-heavy code.

Fix 4 — Upgrade Your Hosting Environment

Sometimes no amount of caching configuration can overcome a fundamentally underpowered hosting environment. Shared hosting places your WordPress site alongside hundreds or thousands of other websites on the same physical server. When a neighbor's site experiences a traffic spike, your CPU and RAM allocation shrinks — your TTFB spikes unpredictably and there is nothing you can configure to prevent it.

Hosting Environment Comparison

Hosting Type	Typical TTFB	Monthly Cost	Control
Shared (GoDaddy, Bluehost)	800ms – 2,000ms+	$3–$15	Minimal
VPS (DigitalOcean, Vultr, Linode)	150ms – 400ms	$6–$24	Full root access
Managed WordPress (Kinsta, WP Engine)	100ms – 300ms	$30–$100	Managed stack
Managed WordPress (Cloudways)	120ms – 350ms	$11–$80	Semi-managed

The migration path that minimizes downtime risk: Shared → VPS → Managed WordPress. A $6/month DigitalOcean or Vultr droplet running Ubuntu with nginx + PHP-FPM + Redis (configured following the steps above) will consistently outperform $15/month shared hosting. Managed WordPress hosts like Kinsta and WP Engine include server-level caching, Redis, PHP 8.2, and a CDN by default — the optimization work is done for you.

If you run a business site where downtime or slow loads directly affect revenue (an e-commerce store, a law firm's contact page, a restaurant's online ordering), the $30–$50/month jump to managed WordPress pays for itself in a single new customer lead.

For a deeper look at how your current server configuration affects other performance metrics, see our guide on running a complete website SEO audit — TTFB is one of several server-side factors that affect both speed and rankings.

Fix 5 — Add a CDN and Optimize DNS to Fix Slow TTFB

Even a perfectly optimized server cannot overcome physics: a user in Sydney querying your server in Dallas will always experience higher latency than a user in Dallas. A Content Delivery Network (CDN) solves this by caching your content at edge nodes distributed worldwide, so Sydney visitors receive a response from a node in Sydney or Singapore instead of making a round trip to North America.

Cloudflare CDN Setup

Cloudflare is the most popular option for WordPress sites because its free tier includes global edge caching, DDoS protection, automatic SSL management, and a network of 300+ data centers. By default, Cloudflare caches static assets (images, CSS, JS) but passes HTML requests through to your origin server. To cache HTML at the edge as well:

1. Log into Cloudflare dashboard → select your domain
2. Go to Caching → Configuration
3. Set Caching Level to "Standard"
4. Enable Always Online (serves cached content if origin is down)
5. On paid plans, enable Cache Reserve for persistent edge caching that survives Cloudflare's cache purges

For WordPress specifically, install the official Cloudflare plugin or WP Rocket's Cloudflare add-on to automatically purge the CDN cache when you publish new posts or update pages.

DNS Provider Performance

DNS lookup time is often forgotten, but it is part of TTFB. GoDaddy DNS averages 60ms+ for lookups; Cloudflare's 1.1.1.1 DNS averages around 12ms globally. Simply switching your nameservers to Cloudflare can save 40–80ms off every uncached first connection — without any other changes to your server.

Fix 6 — Optimize Your WordPress Database

Every WordPress site accumulates database bloat over time: hundreds of post revisions for every edited page, expired transients left by plugins, orphaned metadata, and months of spam comments queued in the trash. A cluttered database means slower WP_Query execution on every uncached request, and slower queries directly translate to higher server processing time and worse TTFB.

Clean Up with WP-CLI

The fastest way to clean a WordPress database is via WP-CLI on the command line. Run these commands on your server (or via SSH):

# Delete all posts in the trash (any post type)
wp post delete $(wp post list --post_status=trash --post_type=any --format=ids) --force

# Delete all expired transients (plugin-generated temporary cache entries)
wp transient delete --expired

# Optimize all database tables (reclaims space after deletions, rebuilds indexes)
wp db optimize

# Count remaining post revisions before deleting (audit first)
wp post list --post_type=revision --format=count

# Delete ALL post revisions (careful: this is irreversible)
wp post delete $(wp post list --post_type=revision --format=ids) --force

After running these commands, a large WordPress site can see its database shrink from several hundred megabytes to under 50MB, with corresponding reductions in query time.

Limit Future Revisions

Prevent the database from bloating again by capping the number of saved revisions. Add this to your wp-config.php:

// Keep a maximum of 5 revisions per post (set to false to disable entirely)
define('WP_POST_REVISIONS', 5);

For ongoing automated maintenance, WP Rocket and WP-Optimize both include scheduled database cleanup tasks. Set a weekly cleanup and you will never deal with revision bloat again.

For a broader look at how to systematically audit all technical performance factors, the automated website audit guide walks through the full checklist that WebsiteLinter runs on every scan.

Measure Your TTFB Improvement

After implementing any of these fixes, resist the temptation to run a single PageSpeed test and call it done. TTFB measurement is noisy — a single data point can vary by 200–300ms due to network conditions. Use this measurement protocol instead:

1. Benchmark before each change — take three WebPageTest readings from the same location before and after each fix, applied individually. This tells you which changes actually moved the needle for your specific setup.
2. Measure from multiple locations — run WebPageTest from at least two cities (one near your server, one distant). A CDN fix shows improvement in the distant location; a server-side caching fix improves both.
3. Target: TTFB under 800ms for PageSpeed green, ideally under 400ms for a competitive score.
4. Monitor Core Web Vitals in Search Console — after publishing improvements, it typically takes 28 days for Google's field data to reflect the changes. Watch for LCP improvements to follow your TTFB reduction — they are directly correlated.

A realistic improvement path for a typical WordPress site on shared hosting:

Step	Change Applied	Expected TTFB
Baseline	Shared hosting, no caching	1,200–2,000ms
After Step 1	Page caching plugin enabled	400–800ms
After Step 2	Redis object caching added	250–500ms
After Step 3	PHP 8.2 + OPcache tuned	200–400ms
After Step 4	VPS migration	100–300ms
After Step 5	CDN + edge caching	50–150ms cached

Each fix compounds on the previous one. You do not need to implement all six — start with caching (the biggest single gain) and measure before adding complexity.

Find every performance issue automatically. Run your free WebsiteLinter scan now → Get a complete Core Web Vitals, TTFB, SEO, and security report — no account required.

Summary: Fix Slow TTFB Step by Step

Time to First Byte is the foundation of web performance. A fast TTFB does not guarantee a fast site — but a slow TTFB guarantees a slow one. The six fixes in this guide address every layer of the stack:

1. Page caching — bypass PHP and the database entirely for cached URLs
2. Redis object caching — eliminate repeated DB queries for uncached and dynamic pages
3. PHP 8.2 + OPcache — execute PHP 3x faster with compiled bytecode caching
4. Hosting upgrade — get dedicated CPU/RAM that does not fluctuate with neighbor traffic
5. CDN + fast DNS — serve cached content from edge nodes near your visitors worldwide
6. Database optimization — clean up revision bloat and expired transients that slow every query

Start with step 1. Measure. Move to step 2. Each change compounds, and you will likely hit your target TTFB before needing all six.

By Jake Lindsey, Lindsey Web Solutions, LLC