Why A WordPress Site Feels Slow
“The site is slow” is usually two different complaints wearing the same words. Either the server is taking a long time to answer, or the server answers quickly and the page then takes a long time to finish building itself in the browser.
The fix is completely different in each case, so the first job is to tell them apart. Work through the steps below in order and you will know which one you have within a few minutes.
Step 1: Separate A Slow Server From A Slow Page
Open your site in a private browser window and watch what happens. The number that matters is time to first byte, the gap between asking for the page and the first response arriving.
A cached page here should come back very quickly. For a sense of what the machine is capable of, the platform’s own nightly check builds a complete WordPress site from nothing, proves it answers over HTTPS and removes it again, typically in well under a minute. Serving a stored HTML page is a tiny fraction of that work.
If the first byte arrives fast but the page still feels slow, the problem is in the page, not the host. Skip to step 3. Buying a bigger plan will not change it.
If the first byte is genuinely slow, and slow on repeat loads of the same page, go to step 2 first.
Step 2: Check Whether The Page Is Being Cached At All
Some pages are never served from the page cache by design, and that is correct behaviour rather than a fault.
| Page | Cached? |
|---|---|
| Home page, a post, a normal page, seen by a visitor | Yes |
| The same page while you are logged in | No |
| Cart and checkout | No |
| The WordPress dashboard | No |
So test as a visitor, not as yourself. A logged-in editor sees uncached pages all day and will always report the site as slower than a customer experiences it.
If visitor pages are slow too, check your plugin list for a caching plugin. WP Rocket, W3 Total Cache, LiteSpeed Cache and the like duplicate what the platform runs and can stop the platform’s own cache being used. Remove them. See how caching works.
Then clear the cache from the site’s Tools tab and test again, so you know you are measuring the current state of the site. See clear the cache.
Step 3: Work Through The Usual Causes
These are the six causes that account for nearly every slow WordPress site, in the order worth checking.
Unoptimised images. This is first because it is the most common and the easiest to fix. A photograph straight off a phone can be four megabytes and five thousand pixels wide, displayed in a box eight hundred pixels across. Resize images before you upload them, or use an image optimisation plugin, and the page gets dramatically lighter without touching anything else.
Too many plugins. Not the count itself, but what they load. Every plugin that adds a stylesheet or a script adds it to every page, including the pages where it does nothing. Deactivate anything you are not using and delete it. A slider plugin on a site with no slider is pure cost.
A page builder doing heavy work on every load. Builders generate their layout on the fly unless they are caching their own output. Check the builder’s settings for a stored or static CSS option and turn it on. Pages built with dozens of nested containers are slower than pages that are not, and there is no host-side fix for that.
An external script or API the page waits for. A chat widget, an analytics tag, a reviews feed, a font from a third party, a plugin phoning home for a licence check. If the external service is slow, your page waits. Load third-party scripts asynchronously where you can, and remove the ones you do not need. This cause is worth suspecting when the site is fast sometimes and slow at other times for no obvious reason.
A slow database query. Usually a plugin doing something expensive, such as a related-posts feature scanning every post, or a store with a very large order history. The symptom is that uncached pages and the dashboard are slow while cached pages are fine. The object cache absorbs a lot of this, which is why it is this far down the list, but a genuinely bad query will still show.
Visitors far from Singapore. The servers are in Singapore. Cloudflare serves your images, stylesheets and scripts from a location near the visitor, so most of the page weight travels a short distance, but the HTML itself still comes from Singapore. Someone in Europe or the Americas will always see slightly more latency than someone in Asia. It is tens of milliseconds, not seconds, and it is not the reason a page takes four seconds to load.
Step 4: Measure Again After Each Change
Change one thing, then test the same page in a private window again. Changing five things at once tells you nothing about which one helped, and some of them will have made it worse.
If you run a shop, speed up WooCommerce covers the parts specific to stores.
When To Open A Ticket
Open a ticket from the members area if the first byte is slow on a plain cached page, with the caching plugins removed and the cache cleared. Include the exact URL you tested and roughly when you tested it. That is a server-side question and we will look at it.
If the first byte is fast, the work is in the page, and the steps above are the work.
Did this answer it? If not, open a ticket from the members area and someone who runs the platform will pick it up.
Open A Ticket