What are the most common reasons a WordPress site is so slow?
These are the causes I find most often. Each one comes with the check that confirms it, because working out which one is eating the time comes before any fix I'd suggest.
- i.
No page cache, or one that's skipped
I time the HTML logged out, through the cache and with it bypassed. If both are equally slow, nothing's serving that page from cache. The fix is one working page cache, not another cache plugin on top.
- ii.
Hosting that can't keep up
A clean install with a default theme on the same plan is the test. If that's slow to respond too, the hosting's the limit, and no plugin tuning will get past it.
- iii.
An old PHP version
WordPress recommends a host that supports PHP 8.3 or greater. Site Health warns when a site runs an outdated version and notes that newer ones are built with performance in mind. I test the upgrade on a staging copy first, since old plugins can break.
- iv.
Heavy plugins, not just many
Query Monitor groups slow database queries and outside HTTP requests by the plugin that ran them. What a plugin runs matters more than the plugin count, so I remove or replace the one it names.
- v.
A theme or page builder loading everything everywhere
Builders and themes that load their CSS and scripts on every page, used or not, hold back the first paint. I unload what a page doesn't use and defer what the first screen doesn't need. My guide to SEO in Elementor covers the builder speed settings I change; my Elementor SEO fixes cover the rest.
- vi.
A main image that starts late
A hero set as a CSS background, lazy loaded, or inserted by a slider script is found late by the browser, so it downloads late. It's usually a bigger delay than the download itself.
- vii.
Images far bigger than their slot
A camera-sized photo shown in a phone-sized space still downloads in full. Right-sized images from
srcset, compression and a modern format like WebP or AVIF fix it. - viii.
Third-party scripts and embeds
Chat widgets, tag managers, video embeds and ad scripts share the main thread with your page, and they're often why the first tap feels stuck. I keep the ones earning their cost and load the rest later.
- ix.
No CDN, or a CDN that can't cache
web.dev recommends a CDN for getting files geographically close to visitors. It also notes that unique URL parameters, like analytics tags, can stop a CDN serving from cache, so I check it's actually caching, not just switched on.
- x.
A bloated database
Since WordPress 6.6, Site Health flags autoloaded options over 800 KB. Rows left behind by old plugins get read on every request, admin screens included, which is why the dashboard often shows it first.
Which of these matters also depends on the metric that's failing. A late hero image is an LCP problem, a jumping layout is CLS and a tap that doesn't respond is INP, and each gets its own diagnosis rather than a general tidy-up.
Why is my WordPress site so slow: the server, the front end or the admin?
Every cause above lives in one of three layers, and I find the layer first. A page can sit on a blank tab before the server sends a single byte. It can arrive quickly and then keep pulling in scripts and images for seconds. Or it can load fine for visitors while the dashboard crawls for whoever's editing. This is my first-look shortcut.
| The symptom | Which layer | First thing I open |
|---|---|---|
| Every page waits before anything shows, even a plain one | Server response | Query Monitor on an uncached page, and the HTML document's timing in the DevTools Network tab |
| The page starts quickly, then images and scripts keep arriving | Front end | The DevTools waterfall with a throttled phone profile |
| Visitors are fine, but saving a post or opening the dashboard drags | Admin and database | Query Monitor inside wp-admin, autoloaded options and admin-ajax requests |
| Only some pages are slow, like the cart, search or account pages | Pages the cache can't serve | Whether those URLs skip the page cache, then Query Monitor on them |
Search Console sits over all three. Its Core Web Vitals report grades real visits, so it tells me whether visitors actually feel the problem, and on which group of URLs, before I spend an hour on a page nobody's slow on.
How I diagnose a slow WordPress site, in order
The order matters more than the tools. Each step either rules a layer out or points harder at it.
- Step 01
Start with what real visitors get
The Core Web Vitals report in Search Console and the field data in PageSpeed Insights both come from the Chrome User Experience Report, which records real visits over a trailing 28 days. If that looks healthy and the complaint is the dashboard, I go straight to the admin. Without enough traffic for field data, I lean on lab tests and say so.
- Step 02
Time the HTML on its own
I time the HTML document, not the whole page, once with the page cache bypassed and once through it. If the uncached number is slow, the problem's on the server, and nothing in the browser will rescue it.
- Step 03
Ask WordPress where the time went
Query Monitor lists every database query, flags slow and duplicate ones, and groups them by the plugin or theme that ran them. It also times outside HTTP requests, so a plugin calling a remote server on every page load shows up here.
- Step 04
Read the waterfall on a throttled phone
In the DevTools Network panel, with the browser cache off and a mobile throttling profile on, I look at what the browser waits for before it paints: a stylesheet, a font file, a slider script, or the main image starting late.
- Step 05
Find the LCP element and split its time
The Largest Contentful Paint element is usually the hero image or the main heading. Its load time splits into four parts, and the biggest part tells me whether the fix is on the server, in how the image is found, in its file size or in what's blocking the paint.
- Step 06
Check the admin on its own
Logged in, I run Query Monitor on the slow admin screens and read Site Health for autoloaded options.
- Step 07
Write it down before changing anything
A short note: the layer, the evidence, the first change and the URLs I'll time again. Then one change at a time, so the next measurement says what actually worked.
Time your pages logged out, in a private window. A lot of cache setups skip logged-in users, so an owner checking their own site while signed in can be looking at the uncached version every time.
Rather have me do this? One person, whole job.
Book a call on UpworkWhat does a slow server response look like?
It looks like nothing. The tab stays blank, and the waterfall shows one long bar for the HTML document before any stylesheet, font or image has started. Everything else waits for that first response, because the browser can't request files it hasn't been told about yet.
The time before that first byte is Time to First Byte. web.dev puts a good TTFB at 0.8 seconds or less and a poor one above 1.8 seconds. It isn't one of the Core Web Vitals, but it's the first of the four parts of Largest Contentful Paint, and web.dev's LCP guide says a high TTFB can make a 2.5 second LCP challenging, or even impossible. It names the usual reasons: redirects, visitors far from the server, poor networks, and cached content that can't be used because of query parameters.
On WordPress, a slow uncached response means PHP and the database are doing too much before they can answer. Query Monitor usually names the culprit: a query that runs far more often than it should, a plugin making an outside request on every page, or a theme building a huge menu from scratch on each load.
A page cache hides this from most visitors, but a cart, a search result or a logged-in page still pays the full cost every time.
Why is the WordPress admin slow when the site isn't?
Because the page cache that makes the front end quick doesn't apply to wp-admin. Every dashboard screen is built fresh by PHP for a logged-in user, so whatever the cache hides from visitors lands on whoever's editing.
Autoloaded options are the first thing I check. WordPress loads every option marked autoload in one query on every request, so a few oversized rows left behind by old plugins get read constantly. Since WordPress 6.6, Site Health flags a critical issue when autoloaded options pass 800 KB, and a new or updated option over 150 KB isn't autoloaded unless the code saving it asks for that.
The Heartbeat API is the second. It's WordPress's built-in polling, and it calls admin-ajax on an interval of 15 to 120 seconds. Several editor tabs open at once, on hosting with few PHP workers, and those calls start queueing behind each other and behind any visitor request the cache can't serve.
The third is plugins doing work on admin page loads: license checks, update checks and dashboard widgets that fetch news from elsewhere. Query Monitor's HTTP requests panel lists each one with the time it took.
If you'd rather one person worked out which layer is slow and then fixed it, that's the speed work I do, remotely, with timings on the same URLs before and after. You can see how a job runs on the process page.
Book a call on UpworkWhy doesn't installing another cache plugin fix it?
Because a page cache fixes one thing: it stops PHP rebuilding the same page for every anonymous visitor. If the time's going into a late hero image, a render-blocking stylesheet or a chat widget, the cached HTML just arrives sooner and the page still waits on the same files.
Stacking them can make things worse. Two plugins minifying the same files, or two page caches on top of a host's own server cache, can clash, and then the fix is taking one away. So I check what caching already exists, including the host's, before I add anything.
The same goes for other checklist fixes. An image plugin helps when images are the problem, a CDN helps when distance is, and neither touches a slow database query. I work alone and remotely, so the person who measures it is the person who fixes it, and there's more on that on the about page.
