Server Response Time and TTFB: The Page Speed Problem Most Sites Ignore
A client came to us with a site that scored reasonably well on PageSpeed Insights. Images were compressed, JavaScript was deferred, caching was in place. But the site still felt sluggish. Every page took over three seconds to start loading. The culprit was not a bloated plugin or an unoptimised image. It was the server itself, sitting there for nearly two seconds before sending a single byte. That first byte is where page speed either wins or loses, and most site owners never look at it.
On this page
What TTFB Actually Measures
TTFB stands for Time to First Byte. It measures how long your browser waits after sending a request before the server starts responding. Not when the page finishes loading. Not when images appear. Just that very first signal back from the server.
Think of it as the pause before a conversation. You ask a question and you wait. If the wait is 200 milliseconds, the conversation flows. If it is 1.8 seconds, the interaction already feels broken before a single word has been said.
Google’s guidance puts a good TTFB at under 800 milliseconds for the total server response, with the ideal sitting closer to 200ms. Anything above 800ms is flagged as needing improvement in PageSpeed Insights.
Why Most Optimisation Misses This
The usual page speed checklist covers images, render-blocking scripts and font loading. Those all matter. But they only affect what happens after the server responds. If your server response time TTFB is already eating two seconds, you are trying to recover a race you lost at the starting line.
Front-end optimisation is visible and measurable with familiar tools, so it gets the attention. Server response time sits in the infrastructure layer, which feels more technical and less approachable. So it gets skipped. The result is a site with well-compressed images that still loads slowly, and an owner who cannot work out why.
What Causes a Slow Server Response
Several things can push TTFB into the red. Shared hosting is one of the most common. When hundreds of sites share the same server resources, your site competes for CPU and memory on every single request. Traffic spikes on a neighbour’s site slow yours down, even if you never touch your own setup.
Unoptimised databases are another major factor. WordPress sites accumulate post revisions, transient data and orphaned records over time. A database query that should take 10 milliseconds can balloon to 400ms when the tables are bloated. You can see this in action by using Query Monitor, a free WordPress plugin that shows exactly which database queries are running and how long each one takes.
PHP version is also worth checking. Running PHP 7.4 instead of 8.2 can cut execution time significantly. Many hosts still default to older versions unless you manually update from the hosting control panel. It is a five-minute change that often shaves 200 to 400 milliseconds off server response time.
Finally, geographic distance matters. A server based in the United States serving a visitor in the UK adds physical latency on every single request. A content delivery network helps with static assets, but the origin server still handles the initial HTML response. Hosting closer to your primary audience is a straightforward win.
How to Measure Your TTFB Right Now
Open Google Chrome DevTools, go to the Network tab and reload your page. Click on the first HTML document in the waterfall. Under the Timing section, you will see TTFB listed. This gives you the raw server response time for a single request from your current location.
For a broader view, use WebPageTest.org. It lets you test from multiple locations and shows a full waterfall with TTFB broken out clearly. Run the test from a location that matches your core audience. A site hosted in Sydney will show very different TTFB numbers when tested from London versus Melbourne.
If your WordPress site’s TTFB is consistently above 600ms, start with hosting quality and PHP version before touching anything else. Those two changes alone often bring response times under 300ms. For a deeper look at what else might be quietly dragging your site’s performance down, web hosting choices have a longer reach than most people realise.
The Connection to Core Web Vitals
TTFB feeds directly into Largest Contentful Paint, one of Google’s three Core Web Vitals. LCP measures when the main content of a page becomes visible. A slow server response delays everything downstream. Even a perfectly optimised front end cannot hit a good LCP score if the server is slow to start.
Google uses Core Web Vitals as a ranking signal. A poor LCP caused by high TTFB can quietly suppress rankings over time, without any obvious technical error to flag. For a structured approach to finding these kinds of issues before they compound, the technical SEO audit checklist covers the key signals worth addressing first.
Caching at the Server Level
Page caching works by storing a pre-built HTML file on the server so PHP and the database are bypassed entirely on subsequent visits. A cached response can drop TTFB from 800ms to under 50ms for returning visitors and search engine crawlers.
On WordPress, plugins like WP Rocket or LiteSpeed Cache handle this well. However, caching is only effective if the underlying server is configured to serve those files efficiently. A slow server serving cached files is still a slow server, just a slightly less slow one. Fix the infrastructure first, then layer caching on top.