PageSpeed Insights has flagged it again: the first request for your page took too long, and the advice is to reduce initial server response time. You have a caching plugin. You may even have paid for a better plan last year. The warning is still there, and the suggestions in the report are short on detail about what to actually do.
The good news is that a slow server response has a fairly small set of causes, and they can be checked in a sensible order. Some cost nothing to fix. Only one of them is “the server is too small”, and it is the last thing to conclude, not the first.
If you want the measurement itself explained, what the waiting time is made of and how it is reported, our post on what time to first byte measures covers it. This post is about bringing that number down.
First, measure it the same way every time
Response time moves around. Before you change anything, get a baseline you can trust.
- Open Chrome’s developer tools, go to the Network tab, tick “Disable cache” and reload the page. Click the first row (the HTML document) and open the Timing tab. “Waiting for server response” is the figure you want.
- Do it three times for each page and note the middle result, not the best one.
- Test three kinds of page: the homepage, an ordinary inner page, and something that cannot be cached, such as a search result or a cart with an item in it.
- Test logged out, in a private window. Logged-in requests usually skip the page cache and will look worse than what visitors get.
Keep these numbers in a note with the date. Every step below should be followed by the same three measurements, so you know which change helped.
Step 1: confirm the page cache is actually serving pages
This is the most common cause by a distance. A caching plugin is installed, but the page you are testing is not being served from the cache. Perhaps the cache was purged a minute ago, perhaps a cookie is making every request look personal, perhaps a setting excludes more than it should.
How to tell:
- Look at the response headers of the HTML document in the Network tab. LiteSpeed servers add a header such as
x-litespeed-cache: hit. Cloudflare addscf-cache-status. Many hosts add their own cache header with “HIT” or “MISS”. - View the page source and scroll to the very bottom. Several caching plugins add a short comment there when the page came from the cache.
- Load the same page twice in a private window. If the second load is not clearly faster than the first, the cache is probably not working for that page.
If you see misses on pages that should be cached, look for the reason before anything else: a plugin setting a cookie for every visitor, a query string added by ad tracking, or exclusions copied from a store setup onto a brochure site. The caching section of the hub covers page caching and plugin choice in detail.
Step 2: find out what WordPress does on an uncached request
Cached pages can be quick while uncached ones crawl. Carts, checkouts, account pages and search will always be built fresh, so their speed depends on how much work WordPress does each time.
Install Query Monitor on a staging copy (or on the live site briefly, while logged in as an administrator) and load a slow page. Look at three panels:
- Queries by component. This shows which plugin or theme ran the most database queries and how long they took in total. One plugin taking far longer than the rest is a strong lead.
- Slow queries. Individual queries that took unusually long, with the plugin that called them. Common offenders are related-posts widgets, filters on large product catalogues and statistics plugins that write to the database on every view.
- HTTP API calls. Every time PHP reached out to another company’s server during this one page view, it is listed here with its duration. Nothing else on the site will show you these.
Step 3: remove outside calls from the page load
An external call is WordPress waiting on somebody else’s server before it can send your page. Typical examples are a plugin checking a licence, a social feed fetching new posts, a currency or shipping rate lookup, or a theme asking its developer’s server for updates. If that other server is slow or down, your page waits with it.
What to do about each one depends on the plugin, but the options are usually the same:
- Turn on the plugin’s own caching option, so the result is stored and reused for a while instead of fetched each time.
- Move the feature to load after the page, through the browser, rather than inside the server’s response.
- Replace the plugin with one that does its outside work in the background.
- Remove features nobody uses. A social feed in the footer that nobody looks at still costs every uncached request.
Step 4: check the PHP version and the object cache
Two server settings make a clear difference to how fast WordPress builds a page, and both are usually in your hosting panel.
PHP version. Current PHP releases run WordPress noticeably faster than old ones. Site Health (Tools, then Site Health, then Info, then Server) shows which version you have. If it is old, plan the move properly, with a test on staging; our guide to moving to a newer PHP version has the checklist.
Object cache. WordPress repeats many of the same database lookups on every request. A persistent object cache keeps the results in memory between requests, which helps most on stores, membership sites and anything with logged-in users. It needs support from the host. Our post on Redis object caching for WordPress explains when it is worth asking for.
Step 5: look for work happening at the same time
Sometimes the page itself is fine but the server is busy with something else when your request arrives. If response time is quick at one moment and slow the next, check for:
- Scheduled tasks such as backups, imports or security scans running during the day.
- Crawlers or bots requesting hundreds of pages in a short time.
- Other staff working in the admin, which is never cached.
- On shared hosting, neighbours on the same server using a lot of resources.
Your hosting panel’s resource graphs, compared against the times you measured, will usually show whether one of these lines up.
Step 6: only now, the hosting resources
If the cache works, Query Monitor shows nothing outrageous, outside calls are gone, PHP is current and the server is not busy with other work, but uncached pages are still slow, then the machine itself may be underpowered for what the site does. At that point the hosting conversation is worth having, with your measurements in hand. Our group guide on what hosting controls in page speed explains how to read the evidence and where an upgrade does and does not help.
What you measured and where to look
| Result | Most likely cause | Step |
|---|---|---|
| Cached and uncached pages both slow, even static files slow | Server overloaded, distance or DNS | 5, then 6 |
| Ordinary pages slow, second load no faster | Page cache not serving | 1 |
| Cached pages quick, cart or search slow | Heavy queries or outside calls | 2 and 3 |
| Slow on every uncached page by a similar amount | Old PHP, no object cache, small server | 4, then 6 |
| Quick most of the time, slow at random | Competing work on the server | 5 |
Mistakes people make when they try to reduce initial server response time
- Testing only the homepage. The homepage is often the most cached page on the site. The slow pages are usually elsewhere.
- Stacking caching plugins. Two page caches, or a caching plugin running over a server-level cache that already does the same job, can conflict, and when they do it is hard to tell which one served the page.
- Changing several things at once. If you switch PHP, add an object cache and remove three plugins in one evening, you will not know which helped, or which broke the contact form.
- Reading a single PageSpeed run. The report’s server timing comes from one request from one location. Your own repeated measurements are a better guide.
- Treating it as the whole story. A fast server response gets the HTML to the browser sooner. If the page is then heavy with images and scripts, visitors still wait. This is one piece of the complete guide to website speed, not all of it.
Frequently asked questions
Why does PageSpeed Insights say my server is slow when my host says it is fine?
Both can be true. The host is usually looking at whether the server is up and within its limits. PageSpeed measures how long one request for your page took, including WordPress building it. A server that is healthy can still be slow to build a page if a plugin runs heavy queries or waits on an outside service.
Will a CDN reduce my server response time?
Only for what the CDN caches. If it caches full HTML pages, visitors near an edge server get those pages without waiting for your origin. If it only caches images and scripts, which is the common setup, the HTML still comes from your hosting and its response time does not change.
Is it safe to run Query Monitor on a live site?
By default its panels appear only for logged-in administrators, so customers never notice it. The plugin itself costs a little extra processing on every request while it is switched on, so many people install it, investigate for a short while and then deactivate it. A staging copy is the more careful place to use it.
My response time is fine on desktop but slow in the mobile test. Why?
Usually the server handles both requests the same way, so the difference tends to come from the test itself. Mobile tests often simulate a slower connection, which stretches the time to receive the first byte. Some sites do serve a separate mobile cache or different content to phones, so if yours does, check that the mobile version is being cached too.
Worked through all six steps and still cannot see where the time goes? A review of server response time is part of the audit in our speed optimisation service. You get the findings as a prioritised list, fixes are applied with your approval, and the re-test at the end is shown side by side with the starting figures.
Next in this series: PHP Workers Explained: Why Busy Sites Start to Queue
