To reduce server response time, cut how long your server takes to build and start sending a page. Turn on server-side page caching, add a CDN, run a current PHP version, and speed up the database. If those are done and it's still slow, the server itself is the limit and a faster host lowers it.
You ran a speed test and got a warning: "Reduce initial server response time." Your pages feel slow before anything appears on screen — the browser sits there waiting, then the design pops in all at once. You may have already shrunk your images and cleaned up scripts, yet the score barely moved. The delay is happening before your content is even sent.
That waiting period is your server response time, and it is one of the most common speed problems for WordPress and other database-driven sites. The good news: it is measurable and fixable, and most of the fixes are things you can turn on yourself. This guide is part of our wider website speed optimization guide, which covers the front-end work; here we focus on the server side.
Before changing anything, measure your TTFB and find where the time goes. A few quick tests point you straight at the cause.
Test 1 — Run a speed test. Enter your URL in PageSpeed Insights, GTmetrix, or WebPageTest. In GTmetrix and WebPageTest, open the Waterfall view and look at the first request; the TTFB or "Waiting" segment is your server response time. PageSpeed Insights reports the same thing under "Reduce initial server response time."
Test 2 — Compare cached and uncached. Load the page once, then reload it. If the first hit is slow but the second is fast, caching is helping some visitors but not the first one. If every load is slow, caching is either off or not working.
Test 3 — Test a plain static file. Upload a simple HTML file (say test.html) to the same server and test its TTFB. A static file skips PHP and the database entirely, so it measures the raw server. If even that file is slow to respond, the bottleneck is the server, not your site's code.
Is it your site or your host? This is the key question for TTFB. First, turn on full-page caching and test again. If a cached page is still slow to respond — or if the plain test.html file from Test 3 is also slow — the server itself is the bottleneck, because a pre-built or static response involves almost no work on your side. That points to slow, overloaded, or distant hosting. But if the cached page is fast and only uncached, dynamic pages are slow, the cause is on your side: no caching, an old PHP version, or heavy database queries you can fix with the steps below.
TTFB (Time to First Byte) is the time from when a browser requests a page to when it receives the first byte of the response. It is made of three parts: the request travel time (how long the request takes to reach the server), the server processing time (how long the server takes to build the page), and the response start (the server beginning to send data back). Server processing is usually the biggest piece you can control.
On a WordPress site with no caching, the server does real work on every single request: PHP runs, queries the database, assembles the HTML, and only then sends the first byte. That is why page caching matters so much — it lets the server hand back a page it already built, skipping most of the processing. Without it, the same page is rebuilt from scratch for every visitor.
Speed tools set clear targets. PageSpeed Insights and Lighthouse flag this as "Reduce initial server response time," and Google generally wants server response under ~600ms, ideally lower; a good target for a cached response is under ~200ms (as of 2026). TTFB also feeds directly into Largest Contentful Paint, the Core Web Vitals metric for how fast your main content appears — a slow first byte delays everything after it. Our Core Web Vitals guide explains how LCP is scored.
A handful of causes produce a slow server response. Match your situation to the cause, then follow the matching step below.
| Likely cause | Tell-tale sign | Where to fix |
|---|---|---|
| No server-side or page caching | Every load is slow; pages are rebuilt each time | Step 1 |
| Server far from your visitors | Fast for you, slow for distant users | Steps 2 and 6 |
| Outdated PHP version | Running an old PHP release in your host panel | Step 3 |
| Slow database queries | Uncached pages slow; large or bloated database | Step 4 |
| Too many plugins / heavy processing | Response climbs as you add plugins | Step 5 |
| Slow or overloaded hosting | Even a cached or static file is slow | Step 7 (better host) |
Work through these in order and re-test your TTFB after each one. Stop when you hit your target — you may not need every step.
Don't spend hours optimizing images and JavaScript to fix a problem that is actually server-side. Image and script tuning improve other speed metrics, but they do almost nothing for TTFB, because TTFB is measured before any of those files are sent. If your speed test flags "Reduce initial server response time," start with caching and the server — not the front end.
The other mistakes we see most often are:
Once your TTFB is where you want it, a few habits keep it there:
As of 2026, Google generally wants server response time under about 600ms, and lower is better. For a cached page, a good target is under about 200ms. If your TTFB is well above 600ms, your speed tool will flag "Reduce initial server response time," and it's worth working through caching, PHP, and hosting to bring it down.
The usual causes are no page caching (so the server rebuilds each page from PHP and the database on every request), an outdated PHP version, slow database queries, too many plugins, a server located far from your visitors, or slow, overloaded hosting. Run a static-file test to tell whether the cause is your site's code or the server itself.
Often, yes. Enabling page caching, adding a CDN, upgrading PHP, cleaning the database, and cutting plugin overhead fix most slow-response problems without a host change. But if all of that is done and a cached or static page is still slow, the server itself is the limit — and then a faster host is usually the only real fix.
Yes, and it is usually the biggest single improvement. Page caching stores a ready-built copy of each page, so the server sends it straight back instead of running PHP and querying the database on every request. That skips most of the processing time, which is normally the largest part of server response time.
TTFB is the first thing that has to happen on every page load, so a slow first byte delays everything after it — including Largest Contentful Paint, the Core Web Vitals metric for how fast your main content appears. Because Core Web Vitals are a ranking signal, a slow server response can indirectly hold back your SEO as well as frustrate visitors.
A CDN reduces the request travel time by answering from a server near the visitor, and if it caches full pages at the edge it can serve them without touching your origin at all. That lowers TTFB for most visitors. For uncached, dynamic requests, though, the response still comes from your origin server, so your host's speed still matters.
PageSpeed Insights reports it as "Reduce initial server response time." GTmetrix and WebPageTest show it directly in their Waterfall view as the TTFB or "Waiting" segment of the first request. Test from more than one location, because response time varies with distance between the visitor and your server.
Server response time, or TTFB, is how long your server takes to start sending a page — and it happens before any of your images or scripts load, which is why front-end tweaks don't fix it. Measure it in PageSpeed Insights or a Waterfall view, then run the static-file test to learn whether it's your site or your host. Turn on page caching, add a CDN, upgrade PHP, clean the database, and trim plugins. If a cached or static page is still slow, the server is the limit and a faster host is the fix. For the rest of your speed work, our website speed optimization guide is the next step.
When a faster host is the real fix. Server response time is largely host-bound. If you've already enabled full-page caching and a CDN, upgraded PHP, and cleaned the database — and your TTFB is still high, or even a plain static HTML file is slow to respond — then the server itself is the bottleneck, and no amount of front-end work will change it. In that specific case, moving to a faster, better-resourced host with server-level caching (for example LiteSpeed) directly lowers TTFB, because the raw response is built and sent faster. Hostinger is one provider worth comparing on that basis; look at its server resources and built-in caching against your traffic. If valid at checkout, new users may be able to apply a code such as SPECIAL15 or SPECIAL10, subject to Hostinger's terms. If caching and PHP fixed your response time, you don't need to switch anything.
Affiliate disclosure: if you sign up through this link we may earn a commission, at no extra cost to you. How this works.
Related: understand what a web server actually does, and if you run a VPS, how to monitor and improve its performance.
The editorial team behind the Bitrich777 Hosting Help Center — practical, tested guides on web hosting, WordPress, servers, DNS, SSL, email, security and migration. Every walkthrough is reproduced on a live host before it is published.
View all guides by the Hosting Team Spotted an error? Tell us
