PageSpeed Insights warns “Reduce initial server response time” — your server is slow to answer, and everything else waits. The slow server response TTFB fix targets Time to First Byte: the milliseconds between a visitor requesting your page and the first byte of the response arriving. Google rates 800 ms or less as good and anything over 1.8 seconds as poor. TTFB is the floor under every other metric — you cannot have a fast LCP behind a slow first byte. This 2026 guide shows you how to cut it down.
TTFB measures server work, not front-end work: DNS lookup, connection setup, and then the server generating the page. On WordPress, an uncached page means PHP executing, hundreds of database queries running, and plugins doing their thing — all before the first byte leaves. That is why full-page caching is the highest-leverage fix: a cached page skips all of that and answers in milliseconds.
What Causes Slow Server Response (High TTFB)
- No page caching: every visit rebuilds the page in PHP — the most common cause on WordPress.
- Slow or overloaded hosting: shared servers with too many accounts, or a plan too small for the traffic.
- Heavy plugins: one bad plugin can add seconds to every uncached response.
- Bloated database: megabytes of autoloaded options, expired transients, and thousands of post revisions.
- No object cache: WordPress hitting the database for the same data on every request.
- Old PHP version: PHP 7.x is dramatically slower than PHP 8.2/8.3.
- Redirect chains and heavy .htaccess: multiple hops and hundreds of rewrite rules before the page even starts.
- Distant server: visitors far from your data centre pay latency on every request.
How to Fix Slow Server Response Time: 8 Steps
Step 1: Measure TTFB properly
Test with a cache-busting parameter (?nocache=1) so you measure the real uncached response, and run it 3–5 times — single runs vary. Use WebPageTest or KeyCDN’s tester for TTFB specifically. Record the baseline; you will compare every fix against it.
Step 2: Enable full-page caching
Install one caching plugin (LiteSpeed Cache if your host runs LiteSpeed, otherwise WP Rocket or similar) and enable page caching with cache preloading. This alone typically drops WordPress TTFB from 1,500–2,500 ms to 200–400 ms. Never stack multiple caching plugins — they conflict.
Step 3: Add a persistent object cache
Enable Redis or Memcached (with the object-cache.php drop-in) if your host offers it. Object caching speeds up the requests that must run PHP — uncached pages, logged-in views, and admin — by keeping database results in memory instead of re-querying.
Step 4: Upgrade PHP
Switch to PHP 8.2 or 8.3 in your hosting control panel. Newer PHP is significantly faster as well as safer — but test on a staging copy first, because old plugins are the usual source of compatibility errors.
Step 5: Audit plugins for slowpokes
Install Query Monitor on a staging copy and check the per-plugin timing: deactivate plugins one by one and measure uncached TTFB. Many sites find one or two plugins responsible for most of the processing time. Replace or remove the offenders.
Step 6: Clean and optimise the database
Remove expired transients, old post revisions, and spam comments; audit wp_options for oversized autoloaded rows left by deleted plugins (anything over ~800 KB total autoload deserves attention). WP-Optimize or Advanced Database Cleaner automates the routine work.
Step 7: Fix redirects and move closer with a CDN
Collapse redirect chains to a single hop (http → https final, no www detour), keep .htaccess lean, and put a CDN (Cloudflare’s free plan works) in front of the site so static assets — and optionally cached HTML — serve from edge locations near your visitors.
Step 8: Upgrade hosting if the ceiling is the server
If caching, PHP, and plugin audits still leave TTFB high, the server itself is the bottleneck — upgrade the plan or move to a better host. Upgrading is cheaper than weeks of optimisation, but only after the software fixes above; a bigger server just runs the same waste faster. For the image half of speed, see our LCP issue fix.
How to Prevent TTFB Regressions
Keep page caching always on with preloading, monitor plugin installs for performance impact, and clean the database on a schedule. Watch resource usage in your hosting panel monthly — creeping CPU or memory usage is an early warning. A periodic check with a free server speed tool catches slowdowns before visitors complain.
Conclusion
Slow TTFB is almost always fixable without changing hosts: full-page caching, object caching, current PHP, lean plugins, and a clean database. Measure before and after each change, fix the biggest bottleneck first, and the first byte — and everything after it — gets faster. For more server-side wins, follow the KamiWeb blog.