Why Is My WordPress Site So Slow? A Working Diagnostic Guide
A client rang us about her booking form. It was taking nine seconds to load, and her analytics showed roughly a third of visitors were leaving before the page even finished rendering. Her developer hadn’t replied in five days. Her question — which is probably the same one that brought you here — was simply: where do I even start?
If your WordPress site is slow, the frustrating truth is that “slow” isn’t a diagnosis. It’s a symptom with at least eight common causes, and the right fix depends entirely on which one is biting you. A bloated theme needs a different answer to oversold hosting, which needs a different answer to a 4MB hero image that should have been 150KB.
This post is a working diagnostic. By the end of it you’ll know the most likely cause of your particular slowness, how to confirm it with real measurements rather than guesswork, and — honestly — whether it’s something you can fix yourself or whether you need someone to look at it.
The 60-Second Answer
The short answer, before the long one: nearly every slow WordPress site we look at is being dragged down by one of three things — the hosting it sits on, something WordPress itself is doing (a plugin or a heavy theme), or the weight of the page itself (oversized images, too many third-party scripts). Usually two of those are contributing and one is the chief culprit.
If you’ve only got a minute, run your URL through Google’s PageSpeed Insights and look at the TTFB number — that’s how long your server takes to start responding. A high one points one way, a low one points another. The rest of this guide tells you which. If your site is actively down or unresponsive rather than just slow, the site running slow fix page is the faster route — come back here once it’s up again.
Take a Baseline First
Before you change anything, get the numbers. “It feels slow” isn’t a diagnosis — and worse, it sends you chasing the wrong thing.
Two free tools do the job. PageSpeed Insights is Google’s own; it gives you a score plus the metrics Google uses to judge your site in search. GTmetrix adds a waterfall view — exactly what’s loading, in what order, and what’s holding things up. Run both on the page that feels slowest, three or four times each; single readings can vary by a couple of seconds.
Four numbers matter for our purposes:
- TTFB (Time to First Byte) — how long the server takes to start responding. Under 600ms is healthy. Over 1 second means the server is the problem.
- LCP (Largest Contentful Paint) — how long until the biggest visible element finishes loading. Under 2.5 seconds is the target.
- Total page weight — anything over 2MB is heavy; over 5MB is a problem you can probably see with your eyes.
- Number of requests — a clean page makes 40–60. Sites making 150+ are usually being eaten by third-party scripts.
Here’s what an audit looks like on a real site, before and after the speed work:
Real PageSpeed Insights audit, before and after speed optimisation work on a WordPress site.
Those four numbers will point at almost every cause covered below.
The 8 Most Common Causes (Ranked by Frequency)
Ranked from most common to least, based on what actually shows up when we look at slow sites. If you only read the top three, you’ve read the three most likely answers.
Cause 1 — Cheap or Oversold Shared Hosting
This is the cause nobody wants to hear, because the fix usually means spending more money or switching providers — sometimes both. But it’s the single most common reason WordPress sites are slow.
Cheap shared hosting — the £3–7/month plans from the big-name budget providers — works by stacking hundreds of sites onto one server. Your performance depends on what everyone else’s site is doing. When the server’s busy (which, on oversold hosts, is most of the time), your TTFB climbs to two, three, sometimes four seconds before WordPress has even started building the page.
How to spot it: run PageSpeed Insights on three different pages of your site — the homepage, a content page and the contact page. If your TTFB is consistently over a second across all of them, the server is the bottleneck, not WordPress. No amount of plugin pruning will fix it.
What to do: two routes. The cheaper one is upgrading within your existing host to a higher tier — moving from a £4/mo shared plan to a £15–25/mo “WordPress-optimised” plan with the same provider. Sometimes that helps; sometimes it doesn’t, depending on whether the higher tier is genuinely different infrastructure or the same servers under a nicer label.
The more reliable route is moving to a host whose entire business is running WordPress sites well: Kinsta, WP Engine, SiteGround’s higher tiers, Cloudways. Expect £20–40/month rather than £4. The TTFB difference is usually night and day.
Cause 2 — Too Many Plugins (Or One Bad One)
The internet will tell you that you have too many plugins. The internet is mostly wrong about this. We’ve seen 45-plugin sites that fly and 12-plugin sites that crawl. The number isn’t the issue — it’s almost always one or two plugins doing something they shouldn’t.
A common offender: a social-sharing plugin that loads its full JavaScript bundle, plus icon fonts, plus tracking scripts, on every page of your site — including pages where the share buttons don’t appear. Another: a contact form plugin that loads its assets sitewide rather than just on the contact page. These aren’t badly intentioned plugins; they’re lazily built, and one of them can add a full second to your load time on its own.
How to find the culprit: install Query Monitor (free). It shows you which plugins are using the most database queries and the most PHP time on each page load. Run it on the slowest pages first. The plugin that lights up red is your suspect.
What to do: sometimes you can swap the plugin for a lighter alternative — a static share-buttons solution instead of a JavaScript one, for instance. Sometimes the plugin is essential and the answer is configuring it better, disabling its assets on pages where they aren’t needed. And sometimes the answer is removing it entirely and asking whether the feature was worth the cost in the first place.
Cause 3 — A Bloated Theme or Page Builder
Open the PageSpeed waterfall for your homepage. If you’re seeing 15+ CSS files, half a dozen JavaScript bundles and a total page weight north of 3MB on a fairly simple page, you’re probably looking at theme bloat.
Heavy themes and page builders — Avada, Divi and certain Elementor configurations are the usual suspects — solve a real problem (letting non-developers build complex pages without writing code) by loading a lot of infrastructure just in case you use it. A simple text-and-image page on a Divi site can load the same CSS and JavaScript needed for a parallax animated portfolio elsewhere on the site. You pay the performance cost whether you use the features or not.
How to spot it: in GTmetrix, look at the breakdown by content type. If CSS and JavaScript together account for more than half your page weight on a content-light page, the theme is doing too much. As a reference point, run the same test on a brand-new WordPress install with a default theme — the difference is usually startling.
What to do: the realistic fix isn’t “switch theme.” Re-theming a live site is a project, not a tweak, and rarely justified by speed alone. The practical answer is conditional asset loading: tools like Asset CleanUp or Perfmatters let you disable specific theme and plugin assets on pages that don’t need them. It’s a fiddly job, but it’s the difference between rebuilding the site and fixing it.
Cause 4 — Massive Unoptimised Images
A 4MB hero image is roughly twenty times too large for what it’s doing. An optimised version — same visual quality at the size most browsers actually display it — should weigh 100 to 200KB. Across a page with five or six images, that difference adds up to a load time that’s two or three seconds shorter, for no compromise the visitor can see.
This is the most DIY-friendly cause on the list, and the fastest to fix. In GTmetrix’s waterfall, sort by file size; anything over 500KB that isn’t a video should be investigated. PageSpeed Insights also flags “properly size images” and “serve images in next-gen formats” directly — those warnings are this cause.
Squoosh (free, made by Google) compresses images one at a time before upload. For images already on the site, ShortPixel, Smush or EWWW will batch-optimise the lot, including converting to WebP — a newer format roughly 25–35% smaller than JPEG at the same quality. Lazy loading has been built into WordPress core since version 5.5; it’s on automatically for images that have width and height attributes set. If yours don’t, the lazy loading silently isn’t firing — adding dimensions in the media library fixes it.
Cause 5 — No Caching, Or Caching Done Wrong
Caching isn’t one thing. It’s three or four things, only one of which most sites have configured properly.
Page caching stores a finished HTML version of each page so WordPress doesn’t rebuild it on every visit. It’s the biggest single performance win — and it’s what most caching plugins do.
Object caching stores database query results in memory. It needs server-level support (Redis or Memcached) and not every host offers it.
Browser caching tells the visitor’s browser to keep static files locally for next time. Usually handled at server level.
How to spot it: if PageSpeed Insights flags “serve static assets with an efficient cache policy,” browser caching needs work. If your TTFB is high on every page even with a caching plugin installed, page caching isn’t actually running.
What to do: WP Rocket, LiteSpeed Cache or W3 Total Cache will handle page and browser caching. One catch: many managed hosts (Kinsta, WP Engine, SiteGround) now do page caching at the server level, and a plugin on top can conflict — usually making things slower, not faster. Check what your host does before installing anything.
Cause 6 — A Bloated Database
If the front of your site loads fine but /wp-admin drags — saving a post takes ten seconds, the dashboard hesitates, the plugins page crawls — your database is probably the problem.
Three things bloat WordPress databases over time. Post revisions: every save keeps a copy, and a page edited fifty times has fifty revisions sitting in the database. Expired transients: temporary cached data that should have been cleaned up but wasn’t. Autoloaded options: settings that load on every page request, often left behind by plugins you uninstalled years ago.
None of this is catastrophic on its own. But on a five-year-old site, the database can be ten times the size it needs to be — and every admin action is wading through all of it.
How to spot it: the admin-slow-but-front-end-fine pattern is the clearest signal. You can also check your wp_options table for autoloaded data over 1MB — that’s where it starts to hurt.
What to do: WP-Optimize (free) is the standard tool. It cleans revisions, transients and orphaned options in one pass. One non-negotiable caveat: back up the database before you run it. Cleanup is reversible if you have a backup, and not reversible if you don’t.
Cause 7 — External Scripts and Third-Party Services
Open your browser’s developer tools (F12 in most browsers), go to the Network tab and reload your homepage. Look at the Domain column. Count the different domains your single page is calling.
Under ten is fine. Twenty or more and every one of those connections is adding milliseconds to your load time — and some are adding seconds.
The offenders are well-intentioned: Google Analytics, Tag Manager, a chat widget (Intercom, Drift, Tawk.to), social embeds, a retargeting pixel, a heatmap tool, a cookie banner. Each one was added for a reason. Each one runs JavaScript on every page load. Intercom and similar full-feature chat widgets are the worst — those can add 1–2 seconds on their own.
How to audit honestly: for each script, ask whether anyone is actually using its output. The heatmap tool you installed in 2023 — when did you last look at it? The chat widget meant to capture leads — how many did it actually capture last month?
What to do: remove what isn’t earning its keep. For the scripts you must keep, use Google Tag Manager to lazy-load them where possible (firing after the rest of the page has rendered, rather than during it). The gain from cutting three or four unused trackers is usually larger than people expect.
Cause 8 — Outdated PHP or WordPress Core
Most non-technical site owners are afraid of updates breaking the site. The irony is that not updating is what eventually breaks it: plugins, theme, PHP version and WordPress core drift out of sync with each other, and sudden compatibility failures follow.
PHP 8.4 is the current production target for WordPress. If your site is on 8.1 or older — all end-of-life as of 2025, receiving no security patches — you’re not just leaving performance on the table, you’re running unpatched server software. Updating the PHP version alone, without changing anything else, is one of the lowest-effort, highest-impact moves you can make on a slow site.
The legitimate worry is that updating live can break the site. The answer is staging: a copy of the site where you test the update first. Most decent hosts include a one-click staging tool. If yours doesn’t, that’s a separate problem worth solving — and one routine WordPress maintenance is built around.
The Diagnostic Decision Tree
The logic, in case the chart isn’t to hand:
Start with where the slowness lives. If only /wp-admin is sluggish and the front-end loads fine for visitors, you’re almost certainly looking at Cause 2 (a misbehaving plugin) or Cause 6 (database bloat). The asymmetry is the giveaway — visitors hit cached pages, admins hit the live database.
If the slowness is everywhere, run PageSpeed Insights and read the TTFB. TTFB over a second tells you the server is the bottleneck before WordPress has even started rendering — that’s Cause 1 (hosting) or Cause 8 (outdated PHP slowing the server’s processing). TTFB under a second with total load time still over three seconds tells you the server is fine; the page itself is heavy. That points at Cause 3 (theme), Cause 4 (images), Cause 5 (caching) or Cause 7 (external scripts).
Two honest caveats the chart simplifies away. First, most slow sites have two or three causes stacked. The tree gives you the dominant one to start with, not the only one. Second, the front-end-vs-admin split isn’t perfectly clean — a badly-written plugin can degrade both at once. If the chart points one way and your gut points another, trust the measurements over the chart.
DIY or Call a Developer?
Now you’ve got a likely culprit (or two). The next question is whether it’s something you can handle yourself or whether it needs a developer.
| Cause | Realistic DIY? |
|---|---|
| 1 — Bad hosting | DIY decision (which host); professional execution if migrating |
| 2 — Plugins | DIY identification; sometimes DIY fix |
| 3 — Theme or page builder | Usually needs expertise |
| 4 — Images | Very DIY-friendly |
| 5 — Caching | DIY with care; can break things |
| 6 — Database | DIY with backup; can break things |
| 7 — External scripts | DIY auditing; team decision on what to keep |
| 8 — PHP or WordPress core | DIY if confident with staging; risky otherwise |
The matrix oversimplifies in both directions. Cause 4 (images) is marked very DIY-friendly, and the optimisation work genuinely is — but if you batch-process the wrong folder, you can flatten the resolution on every image on the site in one click, and the only way back is from a backup. Cause 3 (theme) is marked needs-expertise, and re-theming is — but spotting the problem in GTmetrix takes about ninety seconds with the steps in Cause 3. Identification is often DIY even when the fix isn’t.
What the table can’t show is that almost every slow site has more than one of these working against it at once. Fixing the worst one rarely solves it entirely; you trim a second off the load time and the next layer becomes the bottleneck. Working through the causes in order, measuring at each step, is the only reliable approach.
That’s what a proper speed optimisation audit covers — finding every cause on the site, ranking them by impact, and working through them measurably rather than fixing one and hoping.
The WordPress Speed Audit Checklist
If you’d rather work through the diagnostic on your own site than read about it in the abstract, the one-page checklist below is the same list our developers work through when auditing a slow site. Same questions, same order, structured so you can fill it in as you go.
The same checklist our developers run on every slow site. One page, no fluff — download it free and work through your site in under an hour.
Download free checklist →No email gate. No “tell us about your business” form. Click the link, get the file. If it’s useful, great; if it’s not, you’ve lost about three seconds.
Where to Go From Here
Most slow WordPress sites aren’t slow for one reason. They’re slow for two or three, layered on top of each other, and the only way to know which ones are biting you specifically is to measure, narrow down and work through them in order. That’s the job — whoever ends up doing it.
Two reasonable paths from here:
- Tackle it yourself. Start with the checklist above. Run PageSpeed Insights on three different pages, note your TTFB, work through the matrix above. You’ll get further than you might expect.
- Have us do it. If the diagnostic is something you’d rather hand off, our speed optimisation service runs the full audit, finds every contributing cause, and works through them measurably with before/after numbers on each. The end of the post is the start of the work.
If ongoing maintenance is also on your mind, our guide to what a WordPress care plan actually is covers the routine work that stops most of these causes accumulating in the first place.
Slow sites are fixable. Most of the time, they’re more fixable than the owner thinks.
Frequently Asked Questions
Sudden slowdowns usually trace to something that changed recently — a plugin or theme update, a host moving you to different infrastructure, or a PHP version upgrade that an older plugin can’t keep up with. Gradual slowdowns are different: those tend to be database bloat (post revisions, expired transients and orphaned options building up over years) or accumulated drift between WordPress core, PHP version, plugins and theme. If the slowness arrived overnight, look at the last 48 hours of changes first.
Two free tools cover it. PageSpeed Insights (pagespeed.web.dev) gives you Google’s view, including the TTFB and LCP metrics that point at specific causes. GTmetrix (gtmetrix.com) adds a waterfall view showing exactly what’s loading, in what order, and what’s holding things up. Run both on the page that feels slowest, three or four times each — single readings can vary by a couple of seconds. Four numbers matter: TTFB under 600ms, LCP under 2.5 seconds, total page weight under 2MB and request count under 60.
Almost never the number, almost always one bad one. WordPress sites running 45 well-built plugins can be quick; sites running 12 can crawl, because one plugin among the 12 is doing something it shouldn’t — loading its full JavaScript bundle on every page, querying the database unnecessarily on every request, or running background tasks that should be queued. Install Query Monitor (free) to see which plugins are using the most database queries and PHP time. The one that lights up red is the suspect, not the rest.
Yes, and it’s the single most common cause of slow WordPress sites. Budget shared hosting (£3–7/month plans) stacks hundreds of sites onto one server, so your performance depends on what every other site on that server is doing. The clearest signal is TTFB — if it’s consistently over a second on multiple pages of your site, the server is the bottleneck, not WordPress. Moving to a managed WordPress host (£20–40/month) or a higher tier with your existing provider typically halves TTFB and often more than that.