A slow website usually comes down to one of five things: your hosting, oversized images, missing caching, a heavy theme, or too many plugins. Before changing anything, check whether the site is slow for visitors or only slow for you. That one step rules out a surprising number of cases.
“Why is my website slow?” is one of those questions that stays vague until you put a number against it. Your site feels sluggish, you are fairly sure it did not used to be so slow, and every article you open hands you a list of nine possible culprits without telling you which one is yours.
So let’s do it the other way round. Work through the checks below in order and you will narrow it down properly.
Is your website slow for everyone, or just you?
This is the step almost every guide skips, and it saves the most wasted effort. A website that feels slow to you is not always slow for the people visiting it.
Check it the way a visitor would. Open the site in a private or incognito window, so you are not logged in and not pulling from your own browser cache. Then try it on mobile data rather than your office wifi. If it loads quickly both times, the problem sits closer to your desk than your server. Usual suspects are a browser extension, a cached older version of the page, a slow local connection, or a VPN routing you the long way round.
If it is only slow when you are logged in, that is normal. Caching plugins deliberately skip the cache for logged-in users, because you need to see live changes rather than a saved copy. The admin experience is therefore slower than the visitor experience by design. If the site drags while you are working in the dashboard but flies in an incognito window, your visitors are fine.
Then measure it properly, from outside your own machine. Run the page through PageSpeed Insights and GTmetrix. Check where GTmetrix is testing from. If it defaults to a server in Vancouver and your customers are in Leeds, the number on screen is not the number they experience.
What actually counts as slow?
“Slow” needs a number attached or you cannot tell whether you have a problem. Google’s Core Web Vitals give you three, measured across real visits:
| Metric | What it measures | Aim for |
|---|---|---|
| Largest Contentful Paint (LCP) | How long your main content takes to appear | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds to a tap or click | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps about while loading | 0.1 or less |
| Time to First Byte (TTFB) | How long your server takes to respond at all | 0.8 seconds or less |
TTFB is the odd one out, because it is a diagnostic measure rather than an official Core Web Vital. It is still the most useful figure on this list for telling you whether your problem is your hosting or your pages, and we come back to it shortly.
Two things about that PageSpeed score. First, the number out of 100 is a rough summary rather than a target, and chasing 100 will cost you more time than it returns. Second, the report shows two different sets of data, and they often disagree. The section at the top is field data, which is what real visitors experienced over the last 28 days. Below it is lab data, a simulated load on a throttled connection. Field data reflects reality and it is the one Google uses. If your site is new or quiet, there may not be enough traffic to show field data at all, in which case lab data is all you have.
Speed is not only a ranking question. It shapes how the whole site feels to use, which is a big part of how design affects user experience.
Why WordPress Websites Slow down in particular
WordPress builds each page on demand, pulling your content out of a database every time somebody visits. That flexibility is a large part of why it runs so much of the web, and it is also why a WordPress website is slow more often than a simple static one. There are more moving parts, so there is more that can drift out of shape.
Three things compound it. Plugins run their own code and their own database queries on every page load. Themes ship with far more functionality than any single site actually uses. And it accumulates quietly, so a site that has been live for three years is usually carrying plugins, revisions and tracking scripts that nobody has looked at since launch.
None of that is an argument against WordPress. It is an argument for checking these things occasionally rather than never.
What is slowing down my website?
Now that you know it really is slow, here is where to look. These are ordered by how often they turn out to be the culprit, not by how technical they are.
1. Your Hosting Can’t Keep Up
Check your TTFB first. If it is comfortably over 0.8 seconds, your server is slow to respond before your page has even started building, and no amount of image compression will fix that.
Cheap shared hosting puts hundreds of sites on the same server and splits the resources between them. When one of your neighbours has a busy afternoon, your site slows down. It is the most common cause we see and the one people are most reluctant to accept, because moving host feels like a big job.
Hosting is an ongoing cost rather than a one-off, and it belongs in what a website really costs rather than being treated as an afterthought.
In the sites we look at, hosting is the culprit more often than everything else combined.
2. Your Images Are Way Too Big
This is the most common fixable cause, and it is almost always a straight upload of whatever came off the camera or the stock library. A 4MB photograph displayed in a 600-pixel-wide space is still a 4MB download.
Keep images under 200KB where you can, and use WebP rather than JPEG or PNG. Squoosh will do this in the browser for free, and most WordPress optimisation plugins will handle it in bulk across a whole library. Check your media library for the biggest offenders first. You will usually find a handful of files doing most of the damage.
3. There’s No Caching in Place
Without caching, WordPress rebuilds every page from the database on every single visit. Caching stores a finished copy and serves that instead, which for most sites is the biggest improvement available.
If you are not sure whether you have it, check your plugin list for a caching plugin and ask your host. Plenty of managed WordPress hosts run caching at server level, in which case adding a plugin on top causes conflicts rather than gains.
Caching also explains a problem you may have run into separately: making a change and not seeing it appear. That is a cached copy still being served, which is handy to know before you assume something has broken.
4. Your Theme or Page Builder is Doing Too Much
Multipurpose themes ship with everything so they can sell to everyone, and you carry the weight of all of it whether you use it or not. Page builders add their own layer of markup on top.
You can sanity-check this by temporarily switching to a default WordPress theme on a staging copy of your site and re-testing. If the page suddenly gets much faster, your theme is a significant part of the problem. It is one of the practical trade-offs between bespoke and templated builds, since a purpose-built site only carries the code it actually uses.
5. Too Many plugins, or One Badly Behaved One
The number matters less than people think. Twenty well-built plugins can be lighter than three heavy ones. What you are looking for is the specific plugin doing damage, not a headcount.
Query Monitor will show you which plugins are running slow database queries and how long each is taking, which turns guesswork into a name. Deactivate the culprit on a staging copy, re-test, and you will know within minutes. Get a feel for how plugins work before you start removing things, because some of them are load-bearing.
6. Your Database Has Years of Clutter
WordPress keeps a revision of every draft, every auto-save, every spam comment and every setting left behind by plugins you removed years ago. On a site that has been running a while this quietly adds up, and every uncached page load has to work through it.
An optimisation plugin will clear revisions, spam and expired transients safely. Take a full backup before running anything that deletes database rows. This is not a step to skip.
7. Third-party Scripts You’ve Forgotten About
Every chat widget, tracking pixel, embedded map, review widget and font script is a request to somebody else’s server, and their speed becomes your speed. These accumulate over years without anyone auditing them.
Look at the waterfall view in GTmetrix and see what is loading from domains that are not yours. It is common to find tags for tools that were trialled once and never removed.
8. You’re Running an Outdated Version of PHP
PHP is the language WordPress is built in, and newer versions are considerably faster. Sites sitting on old versions are leaving straightforward performance on the table, and they are running software that no longer receives security fixes.
Check yours under Tools → Site Health in your WordPress dashboard and compare against the currently supported versions. Most hosts let you change this yourself in the control panel, though you should test on staging first in case an old plugin objects.
9. Your Server is a Long Way from Your Visitors
If your customers are in the UK and your hosting sits in the United States, every request makes a round trip across the Atlantic before anything appears. It is a real cause and one that gets overlooked, particularly on sites set up cheaply or inherited from a previous developer.
Either move to UK-based hosting, or put a CDN in front of the site so your content is served from somewhere closer to the people asking for it.
Website Speed on Mobile vs Desktop
Most people test on the machine in front of them, which is usually a desktop on a decent connection. Your visitors are frequently on a mid-range phone on patchy mobile data. That is a very different experience, and typically it is where most of your traffic comes from.
Mobile devices have less processing power to handle scripts, and mobile networks add latency. PageSpeed Insights scores mobile and desktop separately for exactly this reason, and a strong desktop score sitting next to a poor mobile one is completely normal. If you only ever check one, check mobile.
Here’s When its Worth Bringing in a Specialist
Plenty of this list is DIY. Compressing images, clearing out unused plugins and updating PHP through your host’s control panel are all reasonable jobs to take on yourself, provided you have a backup in place.
Some of it is not, and we would rather be straight with you about which. Migrating hosting, isolating a plugin conflict on a live site, cleaning a database by hand, or diagnosing a problem that survives everything above are jobs where the cost of getting it wrong is the site going down. If you have worked through this list and the site is still slow, the cause is usually something specific to your setup rather than anything on a general checklist. That is the point where a second pair of eyes saves more time than it costs.
Your Questions. Our Answers.
Aim for your main content to appear within 2.5 seconds for most visitors, which is the Core Web Vitals threshold for Largest Contentful Paint. Your server should also respond within 0.8 seconds.
Yes, though less dramatically than often claimed. Core Web Vitals are a ranking signal, but relevance and content quality matter more. Speed has a much larger effect on whether visitors stay and convert once they arrive.
Mobile devices have less processing power and mobile networks add latency, so the same page takes longer to build and deliver. Heavy scripts and large images hurt mobile far more than desktop.
It is less about the number and more about the quality. A handful of poorly built plugins running slow database queries will do more damage than twenty efficient ones. Query Monitor will tell you which of yours is responsible.
Caching plugins deliberately bypass the cache for logged-in users so you always see live changes. This makes the dashboard slower than the visitor experience by design, and it usually means your visitors are unaffected.
