How to Reduce Server Response Time (TTFB)
Everything else on the page waits for the first byte. How to find out why yours is slow, and what actually brings it down.
Short answer
TTFB is the time between a browser requesting a page and receiving the first byte of the response. Google's web.dev guidance treats 0.8 seconds or less as good. To reduce it on WordPress, serve cached HTML with page caching, cut redirects, use a current PHP version, fix slow database queries and plugins, and choose hosting near your audience.
To reduce server response time — measured as Time to First Byte, or TTFB — you need to find which part of the request is slow and fix that part. For most WordPress sites the biggest win is serving cached HTML so the server does not rebuild the page for every visitor. After that come fewer redirects, a current PHP version, leaner plugins and database queries, and hosting close to your audience.
TTFB is not one of the Core Web Vitals, but it sits underneath them. The browser cannot start rendering anything until the first byte arrives, so a slow TTFB uses up time that Largest Contentful Paint needs for everything else.
What does TTFB actually measure?
TTFB covers everything between the browser asking for the page and the first byte of the response arriving:
| Stage | What happens | Typical cause of delay |
|---|---|---|
| Redirects | The browser is sent from one URL to another | http to https to www chains; old URLs |
| DNS lookup | The domain name is turned into an IP address | Slow DNS provider |
| Connection and TLS | The browser connects securely to the server | Distance to the server; old TLS setup |
| Server processing | The server builds the page and starts sending it | Uncached pages, slow PHP, heavy queries, overloaded hosting |
On a typical small business WordPress site, server processing is the biggest part when a page is not cached, and network distance is the biggest part when it is.
What is a good TTFB?
Google's web.dev guidance on TTFB suggests most sites should aim for 0.8 seconds or less, and treats anything over 1.8 seconds as poor. Like the Core Web Vitals, it is judged at the 75th percentile of real visits.
| Rating | TTFB |
|---|---|
| Good | 0.8s or less |
| Needs improvement | 0.8s – 1.8s |
| Poor | Over 1.8s |
These are guidelines rather than a ranking threshold. A site with a middling TTFB can still pass Core Web Vitals if the rest of the page is efficient. But a poor TTFB makes a good LCP very hard to reach, especially on mobile.
How do you measure server response time?
Use more than one source, because each answers a different question.
- PageSpeed Insights field data. The top section shows TTFB from real Chrome users, where the site has enough traffic. That tells you whether visitors actually experience a problem. PageSpeed Insights explained covers how to read it.
- Chrome DevTools, Network tab. Open the page, click the main document request and look at the timing breakdown. "Waiting for server response" is the server processing part.
- Test cached and uncached separately. Load a page logged out (usually cached), then a page that cannot be cached — a search results page, or the same page with a random query string if your cache ignores those. The difference shows how much work the server does when the cache misses.
- Test from a location near your audience. A test run from another continent includes network time your UK visitors never see.
Say a UK site shows 0.3 seconds when cached and 2.1 seconds uncached. The server is fine at delivering files; it is slow at building pages. That points to PHP, plugins, the database or under-powered hosting — not to the network.
The fixes, roughly in order of value
1. Serve cached HTML
Page caching stores the finished HTML and sends it without running PHP or touching the database. On an uncached WordPress site it is the single largest reduction in TTFB available. Check whether your host already caches at server level before adding a plugin, so you do not end up with two caches fighting. WordPress caching explained covers the layers and how they interact.
Then check the cache is actually being hit. Look at the response headers for a cache status indicator, and confirm that tracking parameters from ads and emails are not causing a cache miss on every visit.
2. Remove redirect chains
Each redirect adds a full round trip before the real request even starts. Make sure links, the canonical URL and ad destinations all point to the final https address, and that http to https and non-www to www happen in a single hop, not two.
3. Run a current PHP version
Newer PHP versions generally execute WordPress faster than old ones, and old versions stop receiving security fixes. WordPress recommends PHP 8.3 or newer on its requirements page. Test the upgrade on staging first, because outdated plugins can fail on newer versions.
4. Find the slow plugins and queries
For pages that cannot be cached — logged-in views, carts, search, account areas — server processing time is everything. The free Query Monitor plugin shows, per page, which database queries ran, how long they took, and which plugin or theme triggered them. Common culprits:
- plugins running heavy queries on every page, even where their feature is not used
- related-posts plugins that calculate matches on every request
- page builders loading large amounts of data per page
- calls to external services (currency rates, social counts, stock feeds) made while the page is being built
- an oversized table of autoloaded options, loaded on every single request
Replacing or reconfiguring one bad plugin often does more than any hosting upgrade.
5. Add object caching for dynamic pages
An object cache such as Redis keeps the results of repeated database queries in memory. It helps most on pages that page caching cannot cover, which makes it particularly valuable for shops and membership sites. It needs support from the host.
6. Keep the database tidy
Thousands of post revisions, expired transients, old plugin tables and spam comments slow queries down gradually. Clean them on a schedule, after a backup, and remove tables left behind by plugins you no longer use.
7. Stop WP-Cron running on page loads
By default, WordPress checks for scheduled tasks when visitors load pages. On a busy site, or one with many scheduled jobs, that can add delay to real visits. Disabling the built-in trigger and running cron from a real server scheduler is a standard fix — ask your host.
8. Put the server near your audience
If your customers are in the UK, a server in London or nearby Europe keeps the connection stage short. A CDN can serve static files and, with the right setup, cached HTML from nearer still — do small business websites need a CDN? covers when that is worth doing.
9. Upgrade the hosting — last, not first
If cached TTFB is fine but uncached TTFB stays slow after the steps above, or the site slows at busy times, the hosting is the limit. Choosing web hosting for a UK small business covers what to look for. Upgrading first, before finding the waste, often just buys a faster way to run the same inefficient code.
What not to bother with
- Chasing single-digit millisecond gains on a cached page that is already well under the good threshold.
- Swapping DNS providers when DNS is a tiny fraction of the total.
- Adding a second caching plugin to "boost" the first.
Where TTFB fits
TTFB is the first link in the chain that Core Web Vitals measure. Fix it, then move on to what happens after the first byte: images, render-blocking CSS and JavaScript. If your WordPress site is slow and you are not sure which kind of slow it is, start there.
If you would like the diagnosis done for you, server-side performance is part of the WordPress development service for builds and rebuilds, and monthly speed checks are part of the website maintenance service. The WordPress speed optimisation showcase sets out the diagnostic order.
Worked examples
Related services
Related reading
Website Performance
Core Web Vitals Explained for Business Website Owners
Three metrics, in plain English — what each one measures, what breaks it, and which number Google actually uses.
Website Performance
WordPress Caching Explained
Four layers, each solving a different problem. What each does and where they conflict.
Website Performance
How to Improve Largest Contentful Paint (LCP)
Identify the element being measured first. Almost everything else is guesswork until you have.
Website Performance
Do Small Business Websites Need a CDN?
A CDN is cheap, often free, and sometimes pointless. How to tell whether yours would make a difference.