Reduce WordPress TTFB: Server Caching, Redis/Memcached, DB Cleanup, and CDN
A slow TTFB (Time to First Byte) on WordPress is almost always a server problem, not a theme or front-end plugin problem - which means no amount of image or JavaScript optimization will fix it. Here’s the fix pipeline in the order we apply it during our audits.
Why WordPress Is Especially Exposed to Slow TTFB
WordPress generates every page dynamically from PHP and MySQL queries, on every visit, unless a caching mechanism intercepts the request before it reaches that full pipeline. A standard WordPress site with no active caching therefore runs dozens of database queries on every page load - a load that quickly becomes the main bottleneck as traffic or accumulated content grows.
Step 1: Enable Server-Side Page Caching
Page caching stores a fully generated HTML version of a page and serves it directly for subsequent requests, without going back through PHP or the database. This is, by far, the highest-impact lever for the least amount of effort.
- On standard shared hosting, a page-caching plugin (at the server level if the host allows it, otherwise at the application level) remains the first step.
- On more advanced hosting, native server-side caching (FastCGI cache with Nginx, for example) eliminates the PHP round-trip entirely for already-cached pages, producing the largest measurable TTFB gain.
Step 2: Add an Object Cache with Redis or Memcached
Page caching alone isn’t enough for pages that can’t be cached as-is - e-commerce carts, per-user personalized content, search results. An object cache (Redis or Memcached) intercepts repetitive database queries at a deeper level, independent of full-page caching.
Concretely, an object cache stores the results of expensive, frequent queries in memory (menu metadata, WordPress options, plugin queries) to avoid recomputing them on every load, even on pages that differ from visitor to visitor.
Step 3: Clean Up the Database
Over the years, a WordPress database accumulates post revisions, expired transient entries, leftover data from uninstalled-but-never-cleaned plugins, and tables that grow massive without proper indexes. Every query - even a cached one - gets slower as these tables grow unnecessarily.
- Purge post revisions beyond a reasonable number to keep.
- Clean up expired transients, which silently accumulate with certain plugins.
- Check indexes on the most heavily queried tables (
wp_postmeta,wp_options) if the site has several years of history.
Step 4: Add a CDN, Especially for a North Africa Audience
A CDN (Content Delivery Network) replicates static content (images, CSS, JavaScript) across geographically distributed servers, so each visitor downloads those resources from a point of presence near them rather than from the origin server, potentially thousands of kilometers away.
For a site hosted in Europe targeting an audience in Algeria, Morocco, or Tunisia, that distance adds unavoidable network latency before the server even begins processing the request. A CDN with points of presence near North Africa directly reduces that perceived latency, in addition to - not instead of - server and object caching, which speed up generating the response itself.
Measuring the Result
After each step, it’s essential to re-measure TTFB via a direct request rather than relying on subjective impression alone - some optimizations have an immediate measurable impact, others much more marginal depending on the site’s starting configuration.
Measure your WordPress site’s real TTFB →
Our tool measures TTFB via a direct request to your server, independent of third-party API quotas or added latency.
Need a Full Implementation?
Correctly configuring Redis, FastCGI server caching, and a CDN suited to a North African audience requires dedicated hosting expertise. It’s one of the areas we cover in our technical SEO services.
Published by the Runkexpert Engineering Team. Last updated July 15, 2026.