7 Ways to Improve TTFB on WordPress Without Switching Hosts
TTFB, Time to First Byte, is the gap between a browser requesting your page and receiving the first byte of data back. Most people blame their host the moment it looks slow. Sometimes the host is the problem. More often, it is something fixable on the site itself. These seven steps address the most common causes I see, and none of them require you to move servers or upgrade your plan.
On this page
- 1. Enable Server-Side Caching Properly
- 2. Reduce Database Query Load
- 3. Use a PHP Version That is Not Outdated
- 4. Cut Plugin Overhead on Every Request
- 5. Implement Object Caching Where Possible
- 6. Check for External HTTP Requests Blocking the Page
- 7. Review Your WordPress Hosting Configuration, Not Just the Plan
1. Enable Server-Side Caching Properly
Uncached WordPress pages build themselves from scratch on every request. PHP runs, the database fires queries, and all of that takes time. A caching plugin stores a static version of the page so the server skips most of that work.
The key word is ‘properly’. Installing a caching plugin and leaving everything on default is not the same as configuring it. Make sure full-page caching is actually turned on, that logged-in users are excluded from cache, and that your cache expiry times are set to something sensible, not five minutes.
2. Reduce Database Query Load
A bloated database is one of the most common causes of slow TTFB that nobody spots. Every page load fires a set of database queries. If your database has thousands of post revisions, expired transients, and orphaned metadata sitting in it, those queries take longer than they should.
Running a database optimisation tool clears out the noise. This is not dramatic work, but it does make a real difference on sites that have been running for a few years without any housekeeping. For a deeper look at why this matters, the effect of a bloated database on every page load is worth understanding before you start.
3. Use a PHP Version That is Not Outdated
This one gets missed constantly. WordPress runs on PHP, and older PHP versions are meaningfully slower than current ones. PHP 8.x handles requests faster than PHP 7.4, which is still running on a surprising number of sites.
Check your host’s control panel. Switching PHP versions takes about two minutes. Test your site afterwards to make sure everything still works, but on a well-maintained WordPress install it usually does.
4. Cut Plugin Overhead on Every Request
Plugins add server-side logic that runs on every page load, even pages where the plugin does nothing useful. A contact form plugin that loads its scripts on your homepage is wasting resources. A WooCommerce plugin active on a site with no shop is doing the same.
The fix is not always to delete plugins. Some can be set to load only on specific pages. Others have lightweight alternatives. The point is to audit what fires on every request, not just what appears on screen.
5. Implement Object Caching Where Possible
Full-page caching helps a lot. Object caching goes a layer deeper. It stores the results of database queries in memory so they do not have to run again on the next request. Redis and Memcached are the two most common options.
Not every host supports these out of the box, but many do. If yours does, it is worth setting up, especially on sites with dynamic content like membership areas or WooCommerce shops where full-page caching alone cannot do all the work. If you are comparing hosts partly on this basis, the question of what infrastructure features actually justify their cost comes up more broadly too.
6. Check for External HTTP Requests Blocking the Page
Some plugins make outbound calls to external APIs on every page load. A Google Fonts request, a remote licence check, a third-party analytics ping. If any of those external servers are slow to respond, your TTFB goes up even though nothing on your own server changed.
Tools like Query Monitor show you what external requests fire during a page load and how long each takes. Self-hosting fonts is one simple fix. Disabling remote licence checks where possible is another. These are small things individually, but they add up.
7. Review Your WordPress Hosting Configuration, Not Just the Plan
Switching host is not always the answer, but the configuration on your current host often is. Shared hosting with PHP running as CGI rather than as a module, or without OPcache enabled, will be slower than it needs to be regardless of the plan you pay for.
OPcache stores compiled PHP bytecode in memory so PHP does not recompile scripts on every request. It should be on by default, but it is not always configured with sensible limits. Your host’s support can usually confirm whether it is active and what the current settings look like. It is an unglamorous fix, and it is one of the more effective ones.