Why is my WordPress site slow? The usual suspects

A slow WordPress site is hardly ever a mystery. It is one of five things: enormous images, a plugin misbehaving, no caching, a theme doing far more than it needs to, or a server with too many other websites on it.

The good news is that you can narrow it down yourself in about twenty minutes, without touching any code and without paying anybody. Work through the checks below and you will at least know which conversation to have next.

First, pin down what “slow” means

“The site’s slow” covers a lot of very different faults. Before anything else, get specific.

• Open the site in a private browsing window so you are logged out and starting fresh. Count the seconds until you can read something.
• Try it again on your phone using mobile data rather than the office wifi. If it is only slow in the office, the problem may be your broadband, not the website.
• Compare a heavy page against a simple one. If your contact page loads instantly and the homepage crawls, the homepage’s contents are the problem, not the hosting.
• Log in and click around the dashboard. A sluggish admin area is a strong hint, because the admin skips the cache entirely and talks straight to PHP and the database.
• Note whether it is always slow or only sometimes. Intermittent points at the server or a scheduled job. Constant points at the site itself.

Write the answers down. They are worth more to whoever fixes this than any score out of a hundred from a testing tool.

Suspect one: the images

This is the most common cause we run into and the easiest to fix. Photos come off a modern phone or camera at several thousand pixels wide and several megabytes each. Dropped straight into a page, the browser downloads all of that and then shrinks it to fit a space the size of a postcard.

To check, right-click an image on your site and open it in its own tab. If the picture that appears is vastly bigger than the one on the page, it is costing you load time for nothing. Ten of those on a homepage is a page nobody on a train will ever see.

Resize images to roughly the size they will be displayed at before uploading them, save them as WebP where you can, and let an optimisation plugin handle the rest. A banner image has no business being four megabytes.

Suspect two: plugins

There is no magic number of plugins. Twenty well-written ones can be lighter than three bad ones. What matters is what each is doing on every page load.

Go to your plugins list and read it properly. Some things worth noticing:

• Anything you do not recognise, or installed once to try and forgot about
• Two plugins doing the same job, which happens a lot with security and SEO tools
• Sliders, galleries, chat widgets and popup builders, which tend to load their own scripts on every page whether that page uses them or not
• Anything last updated years ago, which you can check on its wordpress.org listing

If you suspect one in particular, take a backup, then deactivate plugins one at a time and retest between each. Tedious, but it is how the problem gets found. Deactivating in batches only tells you the culprit is somewhere in the batch.

Suspect three: nothing is being cached

Without caching, WordPress rebuilds your homepage from scratch for every single visitor. It runs the PHP, queries the database, assembles the page, then throws it away and does the identical thing again for the next person.

Caching keeps the finished page and serves that instead. For a brochure site where the content changes weekly, this is often the single biggest improvement available, and the difference is immediately obvious.

Check whether a caching plugin is installed at all, and if one is, whether anybody ever configured it beyond activating it. Half-set-up caching is common. Worth knowing: caching does nothing for logged-in users, for a WooCommerce basket, or for a checkout, so a shop that feels slow while you are logged in may be perfectly quick for customers.

Suspect four: the theme

Themes bought from a marketplace often arrive with everything anybody might ever want bundled in: a page builder, an animation library, several icon sets, three slider engines and a font collection. You use two of those. The visitor downloads all of them.

Demo content is the other trap. Import a demo to get started, never clear it out, and you are left with sample pages and widgets quietly loading assets in the background.

Replacing a theme is not a twenty-minute job, so it is the last thing to try rather than the first. But if you have worked through images, plugins and caching and the page is still heavy, this is usually where the weight is hiding.

Suspect five: the server underneath it

Everything above is your site’s fault. Sometimes it genuinely is not.

Budget shared hosting works by fitting as many websites as possible onto one machine. When your neighbours are quiet you get decent performance. When one of them has a busy day, or gets attacked, or runs a badly written import script, your site slows down and there is nothing on your end to fix.

Two tells point at the server rather than the site. One is a slow admin area on a site that is otherwise fine, since the dashboard depends almost entirely on how fast PHP and the database respond. The other is slowness that comes and goes with no pattern you can trace to anything you did. If the reason you are worrying about this is search rather than visitors, does web hosting affect SEO sets out how much of it Google is actually measuring.

While you are looking, open Tools then Site Health in your dashboard. It will tell you which PHP version you are on, and an old one is both slower and a security problem. It also flags a missing persistent object cache, which matters more the bigger your database gets.

Three suspects that rarely get lined up

• Third-party scripts. Chat widgets, tracking tags, embedded maps and social feeds fetch code from somebody else’s server. Your page waits on their server, and you get no say in how fast it is.
• A bloated database. Years of post revisions, expired transients and leftover tables from plugins deleted long ago all make every query a bit more work.
• Backups running at lunchtime. A backup plugin compressing your entire site in the middle of the working day will drag everything down while it does it. This is one reason we take backups off the server rather than from inside WordPress, and there is more on what separates a real backup from a comforting one in website backups explained.

What to do, in order

Start with the cheap wins. Sort the images out, get caching working properly, then remove plugins you do not use. Most sites feel like a different website by that point.

If it is still slow after all three, and especially if the dashboard is slow too, the hosting is the next place to look. Our managed WordPress hosting sits on UK servers with PHP and caching set up for WordPress rather than for whatever happens to be installed, and if you run a shop the WooCommerce side needs its own thinking about what can and cannot be cached.

Slow WordPress site FAQs

Tell us what the list turned up

Send us the address and what you found working through the checks above. We will look at where the time is actually going and tell you whether it is the site, the server, or both. No charge for the answer, and no sales pitch if it turns out you just need smaller images.