How to Reduce TTFB in WordPress

If your WordPress site feels slow before anything even appears on screen, the culprit is almost always TTFB — Time to First Byte. It’s the delay between a visitor’s browser asking for your page and the server sending back the very first byte of it. Everything else — images, fonts, layout — can only start after that first byte lands. So when you want to reduce TTFB in WordPress, you’re attacking the single biggest chunk of “dead time” in the whole page load.

The good news: TTFB is one of the most fixable metrics in WordPress. It’s driven by a short list of causes, and most of them come down to caching and hosting. This guide walks through what actually moves the needle, in rough priority order, and how to verify each change.

What is TTFB and what counts as “good”?

TTFB measures three things stacked together: the network round trip to your server, the time your server spends generating the HTML, and the time to send the first byte back. On a typical uncached WordPress request, PHP has to boot, load your theme and plugins, run dozens of database queries, and assemble the page — every single time. That server-processing chunk is where most WordPress TTFB problems live.

As a rough benchmark, aim for a TTFB under 200ms for cached pages and under 600ms at the very worst. Google flags anything over 800ms as a problem in its field data. If your PageSpeed or GTmetrix report shows a “Reduce initial server response time” warning, that’s TTFB talking. (If you’re unsure which tool to believe, our guide on GTmetrix vs PageSpeed Insights explains what each one actually measures.)

The biggest lever: full-page caching

The fastest way to reduce TTFB in WordPress is to stop generating the page on every request. A full-page cache saves the finished HTML the first time a page is built, then serves that saved copy to the next visitor — skipping PHP, the theme, and the database almost entirely.

There are three places you can cache, and the best setups use more than one:

• Disk / server cache — the finished HTML is stored on your server and served before WordPress even fully boots. This alone can drop TTFB from several hundred milliseconds to a few dozen.
• Edge cache — the HTML is stored on a CDN’s servers around the world, so a visitor in Sydney is answered from Sydney instead of from your host in Ohio. This kills the network-latency portion of TTFB for distant visitors.
• Object cache — caches the results of repeated database queries in memory (usually Redis) so dynamic pages that can’t be fully cached still build faster.

A disk cache is where you start, because it gives the biggest single win with the least risk. Speed of Light serves its disk cache through an advanced-cache.php drop-in that runs before WordPress loads — which is exactly where you want the shortest possible path to that first byte. If you’re comparing options, our roundup of the best WordPress caching plugins in 2026 breaks down how the major players handle this layer.

Add edge caching for global visitors

Even a perfectly cached page still has to travel across the internet. If your server is in the US and half your audience is in Europe or Asia, that round trip can add 100–300ms of pure network delay to TTFB that no amount of server tuning will fix.

The answer is edge caching: putting the full HTML page on a CDN so it’s served from a location near each visitor. The catch is that most “CDN” setups only cache static assets (images, CSS, JS), not the HTML itself — so TTFB doesn’t improve. You specifically want full-page edge caching.

You can do this for free. Speed of Light configures full-page HTML caching on Cloudflare’s free plan using modern Cache Rules — no paid Cloudflare APO, no Page Rules to hand-configure. We wrote a dedicated walkthrough on full-page caching on Cloudflare’s free plan if you want to set it up yourself, and a broader look at whether your WordPress site even needs a CDN.

Speed up dynamic requests with an object cache

Some pages can’t be fully cached — a logged-in dashboard, a WooCommerce cart, an AJAX endpoint. For those, WordPress still has to run queries. A Redis object cache stores the results of expensive, repeated database queries in memory, so the second time WordPress needs the same data it reads it from RAM instead of re-querying MySQL. On query-heavy sites this can meaningfully cut server-processing time and, with it, TTFB.

Object caching is one of the least-installed WordPress optimizations because it usually requires a separate plugin plus a Redis server. If you want to understand the mechanism, see what a Redis object cache is in WordPress, and for how the three cache types differ, page cache vs object cache vs CDN. Speed of Light ships a native Redis object-cache drop-in with a GUI and value compression built into the same license, so you don’t need a second plugin to run it.

Your hosting sets the floor

Caching hides a slow server; it doesn’t fix one. When a page does have to be generated — the first uncached hit, or any dynamic request — hosting determines how fast that happens. Without ranking specific providers, these are the levers that matter:

• PHP version — run PHP 8.1 or newer. Each modern release is meaningfully faster, and the jump from PHP 7.x can cut server time noticeably for free.
• Server stack — LiteSpeed and well-tuned NGINX setups generally serve WordPress faster than default Apache. Managed WordPress hosts usually pre-tune this.
• Managed vs cheap shared — on oversold shared hosting, your TTFB spikes whenever a neighbor gets busy. Consistent low TTFB usually means paying for real, isolated resources.
• Server location — pick a data center near most of your visitors, and let edge caching cover the rest.

If you’re evaluating a move, what makes WordPress hosting fast in 2026 covers this in depth.

Trim the work WordPress has to do

Two more things quietly inflate the server-processing part of TTFB:

A bloated database. Over time, post revisions, expired transients, spam, and orphaned metadata pile up and slow down every query. A regular cleanup keeps queries fast — see how to clean up and optimize the WordPress database.

Too many heavy plugins. Every active plugin adds code that runs on page generation. A single poorly-written plugin firing slow queries on init can dominate your TTFB. If you’re chasing a mysterious slowdown, why is my WordPress site slow walks through diagnosing the usual suspects.

How the popular tools compare on the caching layers that fix TTFB

Not every optimization plugin can address every layer of TTFB. Here’s an honest, feature-presence comparison of who does what (trademarks belong to their owners):

The pattern worth noticing: a built-in object cache is rare — only LiteSpeed Cache, W3 Total Cache, and Speed of Light include one. Most others need a separate plugin and, often, a metered add-on for edge or images. For a deeper head-to-head, see WP Rocket vs LiteSpeed vs FlyingPress and our list of the best WP Rocket alternatives.

Where Speed of Light fits

TTFB is really a caching-plus-hosting problem, and the awkward part is that fixing it “properly” usually means stitching together a page-cache plugin, a separate object-cache plugin, a CDN subscription, and maybe an image add-on. Speed of Light was built to collapse that into one license: disk full-page caching, free-plan Cloudflare edge caching, and a native Redis object cache — the three layers that actually reduce TTFB — plus image optimization, CSS/JS handling, and Smart Configuration that sets sane defaults for you. It’s WooCommerce-safe and caches anonymous traffic only, so carts and logins behave.

Whatever tool you choose, the priority order is the same: get a disk cache serving your HTML, add full-page edge caching for distant visitors, layer in an object cache for dynamic requests, and make sure your host and PHP version aren’t holding the floor down. Once TTFB is under control, the rest of your Core Web Vitals — especially LCP — get dramatically easier to pass.

Frequently asked questions

What is a good TTFB for WordPress?

Aim for under 200ms on cached pages and under 600ms in the worst case. Google treats field-data TTFB above 800ms as poor. A properly configured full-page cache should land most pages well under 200ms.

Does a caching plugin actually reduce TTFB?

Yes — this is the single biggest lever. A full-page cache serves saved HTML instead of regenerating the page with PHP and the database on every request, which removes most of the server-processing time that makes up TTFB.

Will a CDN reduce my TTFB?

Only if it caches the full HTML page at the edge. A CDN that only serves static assets (images, CSS, JS) won’t improve TTFB, because the HTML still comes from your origin server. You need full-page edge caching, which Speed of Light configures on Cloudflare’s free plan.

Is a slow TTFB a hosting problem or a plugin problem?

Often both. Hosting sets the floor for how fast an uncached page can be generated (PHP version, server stack, resources), while a caching plugin removes most of that work for repeat visitors. Fix caching first, then check hosting and heavy plugins if TTFB is still high.

Can I reduce TTFB without changing hosts?

Usually, yes. Enabling full-page disk caching, adding free-plan edge caching, updating to PHP 8.1+, and cleaning your database will fix TTFB on most sites without a migration. Switch hosts only if your uncached and dynamic requests are still slow after that.

Speed of Light bundles disk, edge, and object caching in one license — the three layers that fix TTFB — with a 14-day money-back guarantee.