You can reduce TTFB in WordPress by caching full pages, adding a persistent object cache and running current PHP on good hosting. A slow TTFB means your server takes too long to build and send the first byte of each page.
We checked the thresholds and numbers in this guide in October 2026. The sources were Google’s web.dev TTFB guide, the 2024 Web Almanac and the PHP release schedule. Each fix says what it changes on the server side.
Below you will find what TTFB measures and why WordPress gets slow. Then come 10 fixes to work through in order, from hosting and caching to DNS.
Why Does TTFB Matter for WordPress?
TTFB stands for Time to First Byte. It measures the time between a user’s browser sending a request to your server and the moment that server sends back the very first byte of a response. Everything happens before your page even starts loading visually.
TTFB covers several layers of work: redirects, the DNS lookup, the TCP and TLS connection and the server’s processing time. That last part is where WordPress often falls down.
What counts as a good TTFB score?
According to Google’s TTFB guidelines, a good TTFB is 0.8 seconds or less. Scores from 800ms to 1,800ms need improvement, and anything above 1,800ms is poor.
For a cached page on good hosting, a few hundred milliseconds is a realistic target. Treat 800ms as the ceiling and aim well below it.
TTFB is not a Core Web Vitals metric. Google says you do not strictly need a good TTFB if your other metrics pass. A slow TTFB still delays LCP, which makes it hard to ignore.
How TTFB Affects Website Performance
TTFB comes before every other loading metric. A high TTFB adds time to everything that follows it, including the user experience metrics shoppers feel.
According to the 2024 Web Almanac performance chapter, sites with poor LCP spend 2.27 seconds on TTFB alone. That nearly uses up the 2.5-second LCP limit. Image and script fixes cannot win back time the server has already spent.
For WooCommerce stores the cost is higher. Cart, checkout and account pages cannot be served from a full-page cache. Every visit to them waits on the server.
Reasons for Slow WordPress TTFB
Slow WordPress TTFB usually comes from three places. The server itself may be underpowered or shared with busy neighbors. WordPress may also be building every page from scratch with PHP and database queries, and a bloated database or plugin stack makes each build slower.
1. Hosting Factor
On shared hosting your site competes for CPU and memory with many other websites. A sudden traffic spike on another site can slow yours down.
For a site that rarely changes, a static WordPress site removes PHP and database work from every request.
2. WordPress Generates Pages Dynamically
The cause for high TTFB is the time it takes for PHP and database queries to build your webpages. A cached page gets served in milliseconds. An uncached page has to be built again on every request.
Front-end scripts do not affect TTFB. Steps like trying to remove wp-polyfill will not lower it.
3. Uncleaned Database and Heavy Plugins
A WordPress database full of old revisions, expired transients and leftover plugin tables makes queries slower. Every active plugin also adds code that runs on each uncached request. Removing the plugins you do not use cuts that work.
How to Reduce TTFB in WordPress: 10 Proven Ways
To reduce TTFB in WordPress, start with the server: better hosting, full-page caching and a persistent object cache. Then cut the distance and the build time with a CDN, current PHP and a lean database. The last fixes measure server time and trim the transfer itself.
1. Switch to better hosting
If you are on shared hosting and your TTFB stays above 1,000ms, caching and code fixes will not solve the main problem. Move to a VPS, managed WordPress hosting or a quality cloud provider.
GTmetrix gives you a waterfall chart to see exactly how long the initial HTML document takes to start loading. Compare the TTFB before and after a move to see what the new host gives you.
2. Enable full-page caching
With page caching in place, pages are pre-built before a visitor hits the site. All the PHP processing and database lookups required to generate the HTML are done in advance.
When the visitor arrives, the server sends the cached HTML file at once. Building an uncached WordPress page runs PHP and database queries first. A cached page skips all of that work.
Use a caching plugin like WP Rocket. Make sure full-page caching is turned on and not just browser caching. They’re very different things.
3. Add a Persistent Object Cache with Redis
Full-page caching works for logged-out visitors. But your WooCommerce cart pages, checkout, and account pages can’t be full-page cached. That is where object caching helps.
Memcached and Redis are in-memory stores used for WordPress object caching. With one in place, WordPress keeps the results of repeated database queries in RAM. That speeds up dynamic and logged-in pages.
Ask your hosting provider whether Redis or Memcached is available. Many managed WordPress hosts include Redis. Then add the Redis Object Cache plugin to connect WordPress to it. Google’s TTFB guide covers server-side caching in more detail.
4. Use a CDN to reduce geographic delay
A CDN distributes cached copies of your site across global servers. Without a CDN, a request from a visitor far from your server travels the whole distance. With a CDN, a nearby server can answer it from cache.
Cloudflare is the most common choice and has a free plan. It does not cache HTML by default, as its default cache behavior docs state. Add a Cache Rule for your pages and exclude the cart, checkout, account pages and logged-in visitors.
5. Update PHP to a Supported Version
Newer PHP versions build WordPress pages faster and get security fixes. As of October 2026, PHP 8.4 and 8.5 are the branches in active support. PHP 8.2 gets security fixes only until December 31, 2026.
WordPress 7.1 supports PHP 7.4 through 8.5. Check your current version in your hosting control panel and move to 8.4 or 8.5. The official PHP supported versions page shows the end dates for each branch. Read more on whether PHP is still relevant.
Most shared and managed hosts let you switch PHP versions in one click. Test your site after upgrading to catch any errors, especially with older plugins.
6. Clean and Optimize Your WordPress Database
Your database collects junk over time: thousands of post revisions, auto-draft posts, spam comments sitting in the queue, old temporary data, and unused tables left behind by deleted plugins. All of that adds weight to every query WordPress runs.
Installing Query Monitor shows you every database query running on each page load, how long each one takes, and which plugin or theme triggered it. If one plugin is responsible for 30 slow queries on every page, you’ll see it immediately.
7. Measure Server Time with Server-Timing
Server-Timing is a response header that shows where the server spent its time on a request. The Performance Lab plugin from the WordPress performance team adds it, with a wp-total metric for the full WordPress run. In Chrome DevTools, click the HTML document on the Network tab and open its Timing tab.
The Server Timing section lists each metric. If wp-total is close to the whole TTFB, the delay sits inside WordPress. If it is small, look at the network, DNS or the host. Pair it with Query Monitor to find the slow query or hook.
8. Enable GZIP or Brotli Compression
Compression doesn’t directly reduce TTFB, but it does reduce the size of the server response. A smaller response leads to faster transfer time. On many server setups, GZIP is available but not enabled.
On Apache, turn on mod_deflate in your .htaccess file or ask your host. On Nginx, set gzip on in the server configuration. Brotli is a newer compression format, and many CDNs enable it automatically. Our Brotli and GZIP test on WordPress files shows how much each format saves on CSS, JS and HTML.
You can verify whether compression is active using tools like GiftOfSpeed. Look for the “Content-Encoding: gzip” or br header on the initial HTML document.
9. Use HTTP/2 or HTTP/3
If you are still running on HTTP/1.1, you’re leaving performance on the table. HTTP/2 sends many requests over a single connection. HTTP/3 cuts connection setup time, especially on slow mobile networks.
Most hosts turn on HTTP/2 with HTTPS. Check your protocol in the Protocol column of the Network tab of Chrome DevTools. http/1.1 stands for HTTP/1.1, h2 stands for HTTP/2, h3 stands for HTTP/3.
10. Upgrade to a Premium DNS Provider
The DNS lookup is part of TTFB for a visitor’s first request to your domain. A slow DNS provider adds time before the connection even starts. Providers such as Cloudflare DNS, Amazon Route 53 and Bunny DNS run nameservers around the world.
Update the nameservers on your domain registrar to point to your Amazon Route 53-hosted zone and then migrate your DNS records into Route 53. Amazon automatically propagates your DNS globally across its highly redundant Anycast network.
The gain is largest for visitors who live far from your current DNS servers.
When DIY Optimization Isn’t Enough
DIY fixes stop working when the server is misconfigured or a theme or plugin runs far too many queries. If TTFB stays above 1,500ms after caching, better hosting and current PHP, the cause is usually in code or server setup. A developer can trace it with Query Monitor and server logs.
A faster server response also helps you reduce bounce rates. Front-end fixes show their full effect only once the server answers quickly.
If you’ve exhausted the DIY fixes, our WordPress speed optimization services cover server configuration audits, object cache setup, database work and Core Web Vitals fixes.
Conclusion
To reduce TTFB in WordPress, serve cached pages, cut the work each request does and give your server the resources it needs. Full-page caching, better hosting, Redis and PHP 8.4 or 8.5 solve most TTFB problems.
DNS, CDN cache rules, HTTP/2, compression and database cleanup add smaller gains. Use Server-Timing to see whether the time is spent in WordPress or before it.
If TTFB still holds back your Core Web Vitals, our WordPress speed optimization services can find the cause in your server or code.
Frequently Asked Questions (FAQs)
Q1. What is a good TTFB for a WordPress site?
Google calls a TTFB of 800ms or less good. From 800ms to 1,800ms needs improvement, and above 1,800ms is poor. If you are above 800ms, start with full-page caching and better hosting.
Q2. Does TTFB affect SEO?
TTFB is not a Core Web Vitals metric and does not affect rankings directly. It does delay LCP, one of the Core Web Vitals. A poor TTFB that drags down LCP can hurt search visibility.
Q3. Why is my WordPress TTFB slow even with a caching plugin?
Full-page caching may be turned off or skipped for pages with URL parameters, logged-in visitors or personal content. Exclusion rules in the plugin can also bypass the cache. Slow hosting is the other common cause, and caching cannot fix it.
Q4. How do I check what’s causing slow TTFB in WordPress?
Install Query Monitor to see every database query with the plugin or theme behind it. Add Server-Timing with the Performance Lab plugin to see how long WordPress takes. Then test a plain HTML file on your server. If that file is fast and WordPress pages are slow, the issue is in WordPress.
Q5. Can too many plugins cause high TTFB?
Yes. Every active plugin runs code on each uncached page load, and some add database queries or external API calls. One poorly coded plugin can do more harm than ten well-built ones. Use Query Monitor to find the heaviest ones and remove what you do not need.
