Server Response Times: The Fix Nobody Mentions
Most people chasing page speed go straight for image compression and caching plugins. Fair enough, those things matter. But there's a step that happens before any of that, one that quietly decides whether your site feels fast or sluggish regardless of everything else you've done. Server response time is where the race is already won or lost, and it's the fix that barely anyone talks about.
On this page
What Server Response Time Actually Is
When a browser requests your page, your server has to think before it responds. That thinking time is called Time to First Byte, or TTFB. It’s the gap between the browser asking for the page and the first byte of data coming back. Google’s own guidance suggests a good TTFB sits under 800 milliseconds, with under 200ms being the target for strong performance.
Everything else, the images loading, the fonts rendering, the layout painting, all of it waits until that first byte arrives. A slow server response delays the entire chain. You can have the leanest HTML in the world and still feel slow to a visitor if the server takes two seconds just to say hello.
The Real Causes Worth Knowing
Shared hosting is the most common culprit. When your site sits on a server alongside hundreds of others, you’re competing for the same resources. Peak traffic on a neighbour’s site can slow yours down without you doing a single thing wrong.
Unoptimised database queries are another big one, especially on WordPress. Every page load can fire dozens of database calls. If the database isn’t indexed properly, or there are bloated tables from years of old post revisions and plugin data, those queries drag. A site that worked fine at launch can grow noticeably slower over two or three years for exactly this reason.
PHP version matters too. Running an old PHP version on WordPress is like driving with the handbrake on. PHP 8.x processes requests meaningfully faster than PHP 7.x, yet plenty of live sites are still running older versions because nobody’s checked.
What People Get Wrong When They Try to Fix It
The most dangerous version of this I’ve seen is when someone is paid to “optimise” a site, installs a caching plugin, compresses a few images, and calls it done. The PageSpeed Insights score goes up. The client is happy. The server response time hasn’t changed at all.
Google does not use PageSpeed Insights scores as a ranking signal. It is a developer tool, a guide to what could be improved, not a metric Google feeds into its algorithm. Chasing that number without fixing the underlying server configuration is cosmetic work. What actually matters is how fast the page loads for a real visitor on a real connection.
There’s also the cache problem. A caching plugin can mask a slow server by serving pre-built pages. But if the server cache isn’t cleared before the client signs off the work, the slow response time hides underneath. The cache expires weeks later and suddenly the site feels sluggish again. We’ve seen this pattern more than once, where a client pays for work, everything looks fine, and then several weeks down the line the real picture emerges.
How to Diagnose It Properly
Start with a proper TTFB measurement using a tool like WebPageTest or GTmetrix, making sure the server cache is completely cleared first. You want the cold-start number, not the cached one. That’s the honest figure.
Then look at a few specific things in order:
- Which PHP version is the server running? Check in your hosting control panel.
- How large are the WordPress database tables? Autoloaded options bloat is a common offender.
- Is the hosting environment shared, VPS, or managed WordPress? Each has a different ceiling.
- Are there heavyweight plugins firing on every request, even pages where they do nothing?
Fix the environment first. Then add caching on top of a fast server, not instead of one.
When Hosting Is the Honest Answer
Sometimes no amount of optimisation fixes a slow TTFB because the hosting plan simply isn’t up to the job. A £3-a-month shared host will have a ceiling. A move to a proper managed WordPress host, or a VPS with object caching like Redis, can drop response times dramatically where nothing else will.
That’s an unglamorous answer, because it costs money. But if the hosting choice is quietly undermining everything else, no plugin in the world covers for it permanently. The work underneath always surfaces eventually.
One Final Check Before You Trust the Numbers
Always test with a cleared cache. Whether you’re reviewing someone else’s work or your own, flush the server cache, flush the CDN cache, and run the speed test cold. That’s the number that tells the truth. Anything else is a best-case reading on a warm server, and real visitors don’t get that version.